On Tue, Apr 28, 2015 at 5:32 PM Herbert Valerio Riedel <hvriedel@gmail.com> wrote:

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