<div dir="ltr"><br><br><div class="gmail_quote">On Tue, Apr 28, 2015 at 5:32 PM Herbert Valerio Riedel <<a href="mailto:hvriedel@gmail.com">hvriedel@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2015-04-28 at 15:50:26 +0200, Michael Snoyman wrote:<br>
<br>
[...]<br>
<br>
>> PS: We shouldn't forget that there's also an existing deployed<br>
>>     cabal-install user-base we can't get rid off so easily, which may<br>
>>     still leak unencrypted basic-auth credentials for the years to<br>
>>     come. Just saying...<br>
<br>
> I agree on that front. I think that Hackage should turn away all uploads<br>
> that aren't TLS-secured, and should make that change ASAP.<br>
<br>
Well, even if you do that, you can only reject the upload-request<br>
*after* the http client has already leaked the basic-auth credentials<br>
over a non-secured http channel... :-/<br>
<br>
So the only thing this measure would buy us IMHO is that CLI users would<br>
get an incentive to upgrade their cabal-install tooling (if they use<br>
e.g. `cabal upload`), but it wouldn't protect against accidentally<br>
falling back to an older cabal-install version picked up by accident<br>
(and then again compromising the credentials). I.e. this measure on its<br>
own wouldn't remove the unsecured basic-auth eavesdropping attack-window<br>
completely, only make it smaller.<br>
<br>
Cheers,<br>
  hvr<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Michael </div></div></div>