Re-Implement X-ApiKey so that it doesn't rely on transport encryption

[hvr]

#534 Implemented the X-ApiKey feature which I didn't pay attention to until it was already implemented

In 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).

However, 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.

I'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.

I'm prepared to implement this myself, because I care too much about this being done properly.

[hvr]

@agrafix Do you want to implement this yourself, or shall I implement it?

[agrafix]

@hvr Sounds reasonable. At the time I was not aware that transport encryption was a problem on hackage. I'd be happy to implement it, but I have 1 1/2 very busy weeks ahead. I could implement it afterwards if that would be still okay as timeframe.

Apart from that: Why don't we also attack the transport encryption problem? What's missing to make that happen? I would like to help to make get this going! (Is there already an issue for this?)

[dcoutts]

Note that we're also changing things so you can't use this auth method over plain http, though we're fighting with some issues with the CDN to make that work properly.

[dcoutts]

@hvr is this really a big issue if we prevent people using it over http and only allow it over https?

[agrafix]

I think the problem is that https is currently not end-to-end, meaning that the connection between hackage and fastly is not encrypted, and fastly has to be "trusted"

[hvr]

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'd still continue to exist albeit smaller. For one, we'd have to trust the CDN nodes which by design are MITMs 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.

[hvr]

I hope to get to pick this one up soon again (probably during the GSOC time).