On Tue, Apr 28, 2015 at 5:32 PM Herbert Valerio Riedel
On 2015-04-28 at 15:50:26 +0200, Michael Snoyman wrote:
[...]
PS: We shouldn't forget that there's also an existing deployed cabal-install user-base we can't get rid off so easily, which may still leak unencrypted basic-auth credentials for the years to come. Just saying...
I agree on that front. I think that Hackage should turn away all uploads that aren't TLS-secured, and should make that change ASAP.
Well, even if you do that, you can only reject the upload-request *after* the http client has already leaked the basic-auth credentials over a non-secured http channel... :-/
So the only thing this measure would buy us IMHO is that CLI users would get an incentive to upgrade their cabal-install tooling (if they use e.g. `cabal upload`), but it wouldn't protect against accidentally falling back to an older cabal-install version picked up by accident (and then again compromising the credentials). I.e. this measure on its own wouldn't remove the unsecured basic-auth eavesdropping attack-window completely, only make it smaller.
Cheers, hvr
Your analysis is accurate. There are some interesting approaches we could take to further mitigate things. For example: newer versions of cabal-install could automatically set an incorrect username/password in the ~/.cabal/config file, and create a new set of fields (ssl-username/ssl-password?) that it would recognize. A more radical approach would be to have Hackage simply turn off port 80. But that's probably too extreme; having a 301 redirect from HTTP to HTTPS is really necessary for a good user experience, and even that redirect would still expose the password vulnerability window. Michael