{"action":"created","issue":{"url":"https://api.github.com/repos/haskell/hackage-server/issues/541","repository_url":"https://api.github.com/repos/haskell/hackage-server","labels_url":"https://api.github.com/repos/haskell/hackage-server/issues/541/labels{/name}","comments_url":"https://api.github.com/repos/haskell/hackage-server/issues/541/comments","events_url":"https://api.github.com/repos/haskell/hackage-server/issues/541/events","html_url":"https://github.com/haskell/hackage-server/issues/541","id":176820663,"number":541,"title":"Re-Implement X-ApiKey so that it doesn't rely on transport encryption","user":{"login":"hvr","id":285533,"avatar_url":"https://avatars.githubusercontent.com/u/285533?v=3","gravatar_id":"","url":"https://api.github.com/users/hvr","html_url":"https://github.com/hvr","followers_url":"https://api.github.com/users/hvr/followers","following_url":"https://api.github.com/users/hvr/following{/other_user}","gists_url":"https://api.github.com/users/hvr/gists{/gist_id}","starred_url":"https://api.github.com/users/hvr/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/hvr/subscriptions","organizations_url":"https://api.github.com/users/hvr/orgs","repos_url":"https://api.github.com/users/hvr/repos","events_url":"https://api.github.com/users/hvr/events{/privacy}","received_events_url":"https://api.github.com/users/hvr/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/haskell/hackage-server/labels/bug","name":"bug","color":"fc2929"},{"url":"https://api.github.com/repos/haskell/hackage-server/labels/High%20Priority","name":"High Priority","color":"fbca04"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":6,"created_at":"2016-09-14T05:47:47Z","updated_at":"2016-09-15T19:48:38Z","closed_at":null,"body":"#534 Implemented the X-ApiKey feature which I didn't pay attention to until it was already implemented\r\n\r\nIn principle it's a useful feature to have, but its current implementation is insecure as it leaks the credentials and is therefore even weaker than our default http-digest-auth based scheme (which isn't state of the art either, being MD5 based and with some minor other flaws, but it's better than nothing).\r\n\r\nHowever, `X-ApiKey` can be fixed by using the same technique that e.g. AWS uses for its Authorization headers (a MAC-based scheme); Even the older AWS v2 scheme would be an improvement, although I'd rather go for the AWS v4 scheme.\r\n\r\nI'm marking this high priority besides for the obvious security issue, because once implemented, every client using the old insecure X-ApiKey scheme will be broken, hence it's critical to fix this before we have too many users.\r\n\r\nI'm prepared to implement this myself, because I care too much about this being done properly."},"comment":{"url":"https://api.github.com/repos/haskell/hackage-server/issues/comments/247432858","html_url":"https://github.com/haskell/hackage-server/issues/541#issuecomment-247432858","issue_url":"https://api.github.com/repos/haskell/hackage-server/issues/541","id":247432858,"user":{"login":"hvr","id":285533,"avatar_url":"https://avatars.githubusercontent.com/u/285533?v=3","gravatar_id":"","url":"https://api.github.com/users/hvr","html_url":"https://github.com/hvr","followers_url":"https://api.github.com/users/hvr/followers","following_url":"https://api.github.com/users/hvr/following{/other_user}","gists_url":"https://api.github.com/users/hvr/gists{/gist_id}","starred_url":"https://api.github.com/users/hvr/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/hvr/subscriptions","organizations_url":"https://api.github.com/users/hvr/orgs","repos_url":"https://api.github.com/users/hvr/repos","events_url":"https://api.github.com/users/hvr/events{/privacy}","received_events_url":"https://api.github.com/users/hvr/received_events","type":"User","site_admin":false},"created_at":"2016-09-15T19:48:38Z","updated_at":"2016-09-15T19:48:38Z","body":"I'd point out that even if the connection between hackage and fastly was encrypted, we would have just reduced the attack surface, but it's still exist albeit smaller. For one, we'd have to trust the CDN nodes which by design are MITM and can tamper with the unencrypted connection. That whole setup is rather fragile from a security POV imho. And we simply should consider the TLS layer nothing more than an obfuscation layer. We simply cannot rely on it to provide authenticity or privacy with a 3rd party CDN in front.\r\n\r\n"}}
{"actor":{"display_login":"hvr"}}