On Tue, Apr 28, 2015 at 5:32 PM Herbert Valerio Riedel <hvrie...@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
_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
