[savannah-help-public] address@hidden: Re: [Repo-criteria-discuss] Savannah and HTTPS]

[Richard Stallman]

Some people are arguing that we should turn off HTTP on Savannah,
so it should support ONLY HTTPS.  I included some of what
they said.

That seems like a radical demand, and I am skeptical.  What do you
think about the issue?  Should we actually make Savannah reject HTTP
connections outright?


From: Mike Gerwitz <address@hidden>
To: Richard Stallman <address@hidden>
Cc: Hanno Böck <address@hidden>,
  address@hidden,  address@hidden
Subject: Re: [Repo-criteria-discuss] Savannah and HTTPS
In-Reply-To: <address@hidden> (Richard Stallman's message
        of "Mon, 10 Oct 2016 05:01:05 -0400")
Date: Mon, 10 Oct 2016 21:30:39 -0400
Message-ID: <address@hidden>
Content-Type: multipart/signed; boundary="=-=-=";
        micalg=pgp-sha512; protocol="application/pgp-signature"


[1:text/plain Hide]

On Mon, Oct 10, 2016 at 05:01:05 -0400, Richard Stallman wrote:
> 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.

It depends on what you are trying to mitigate.

In the Savannah case, it's important to protect both the user's login
data and their session itself.  When the user is logged in, it's
important to protect against MitM attacks that could be used to hijack
their session or trick them into doing things that they might not want
to do.

More broadly: MitM attacks are always a concern and cannot be mitigated
with plain HTTP.  If the integrity of the data are important---e.g. the
information the user reads and the files that they download---then HTTPS
is important.  There is nothing preventing employers, networks, ISPs, or
states from censoring or modifying content.  Comcast was caught
injecting JavaScript into users' webpages to notify them of copyright
violations.[0] This same method is used by malware to inject
ads.  Wikipedia implements HTTPS in part to ensure the integrity of
their articles.[1]  If I'm visiting a site over Tor, a malicious exit
node could modify and sniff non-HTTPS pages.

There is also the issue of privacy.  With HTTPS, an adversary monitoring
a network (Eve) would know that Alice is looking at Wikipedia, but not
what Alice is looking at.  With plain HTTP, Eve knows exactly what
articles Alice is reading.  This can be potentially life-threatening in
some countries where reading certain articles is a crime.  For others,
it might simply be embarrassing.  If I'm concerned about a health
condition that I want to look up at work, I don't want my employer
knowing I'm looking at it.

It's usually not the case that I can't trust the website itself---it's
everything _else_ that can go wrong.  It's unfortunate that the first
thought in my mind the entire time I'm online (Web or otherwise) is
mitigating various adversaries, but that's the reality.


[0]: https://news.ycombinator.com/item?id=10592775
[1]: https://blog.wikimedia.org/2015/06/12/securing-wikimedia-sites-with-https/

-- 
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: 2217 5B02 E626 BC98 D7C0  C2E5 F22B B815 8EE3 0EAB
https://mikegerwitz.com

[2:application/pgp-signature Show Save:signature.asc (818B)]



------- Start of forwarded message -------
From: Mike Gerwitz <address@hidden>
To: Richard Stallman <address@hidden>
Cc: address@hidden,  address@hidden,  address@hidden,  address@hidden
Subject: Re: [Repo-criteria-discuss] Savannah and HTTPS
In-Reply-To: <address@hidden> (Richard Stallman's message
        of "Mon, 10 Oct 2016 05:00:52 -0400")
Date: Mon, 10 Oct 2016 22:08:23 -0400
Message-ID: <address@hidden>
Content-Type: multipart/signed; boundary="=-=-=";
        micalg=pgp-sha512; protocol="application/pgp-signature"


[1:text/plain Hide]

On Mon, Oct 10, 2016 at 05:00:52 -0400, Richard Stallman wrote:
>   > Richard: unless there's a compelling reason not to, I think the
>   > sysadmins or Savannah hackers (whomever has the ablity) should just add
>   > a webserver rule to redirect all requests on port 80 to 443.
>
> Would this, by itself, fix the immediate problem?

Not completely, for the reason below.

>   >   For
>   > example, if the login form was loaded over HTTPS, but accidentally posts
>   > to an HTTP link,
>
> Please spell out that scenario more clearly; I do not follow you.

Let's assume that the Savannah webserver is configured to redirect all
HTTP requests to HTTPS, as suggested above.

A hypothetical situation (this isn't the case today):

  0. Alice visits https://savannah.gnu.org/account/login.php.
  
  1. Alice is presented with a login form.  This connection is secure.
  
  2. Since Alice is already using HTTPS, the login form would
     normally post its data over HTTPS.  But due to a (hypothetical)
     configuration issue or bug on Savannah, the form is instead
     instructed to post to http://savannah.gnu.org, without HTTPS.
  
  3. The request is made plaintext over HTTP, containing Alice's
     username and password.  Eve, an eavesdropper, observes the data.
  
  4. The Savannah webserver receives the request, sees that it's HTTP,
     and instructs the browser to redirect to HTTPS.
  
  5. The web browser re-submits the request to https://savannah.gnu.org,
     and Alice is none the wiser.  The login succeeds as expected.

Alice observed a secure connection the entire time, but Eve was still
able to harvest her password.[*]

Let's pretend that the above wasn't possible, and Eve doesn't have
Alice's username and password.  She's not out of luck yet.  Savannah
knows that Alice is logged in because of a session cookie stored in the
browser.  This cookie is sent to Savannah encrypted, because Alice is
using HTTPS.

If there is a single link on Savannah misconfigured to point to the HTTP
website, that cookie will be sent in plain text.  If Alice returns to
Savannah at a later time---still logged in---by typing
`savannah.gnu.org' in her browser, her request will first be served over
HTTP.  The cookie will be sent in plain text to the server before she is
redirected.

Eve can take that cookie and send it to the server herself---she will
have assumed the identity of Alice.  If I'm Alice, then Eve is now a
superuser, and can do with Savannah as she pleases.  Fortunately, I
mitigate that with the HTTPS Everywhere addon.

There are other concerns, but this is what HTTP Strict Transport
Security (HSTS) aims to prevent---it tells the web browser, via an HTTP
header, that it should _never_ request a page over HTTP, even if
explicitly instructed to by the webpage.[0]  Eve will have to find
another way.

The solution to the problem is:

  - Redirect all requests to HTTPS; _and_
  - Use the HSTS header.

Further (this is more technical; you needn't read it):

The cookie hijack attack is possible because the cookies on Savannah are
not served with a flag that tells the browser to _never_ serve the
cookie over HTTP.

  - HSTS will mitigate the issue in newer browsers, but the HTTPS-only
    cookie flag should also be set.
  - The option on the login page to "stay in secure (https) mode after
    login" should be removed---of course you'd want that.


[0]: https://en.wikipedia.org/wiki/HSTS

[*]: As a real-world example: I was logging into nature.com at work,
which uses HTTP.  One of my coworkers---who handles the systems that
monitor logs for threats---notified me that my password was plaintext in
the logs.  Fortunately, he is a good guy.  And fortunately, my Nature
account wasn't sensitive, and used a password unique to that website;
if my password were shared, accounts on other websites would effectively
be compromised.

- -- 
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: 2217 5B02 E626 BC98 D7C0  C2E5 F22B B815 8EE3 0EAB
https://mikegerwitz.com

[2:application/pgp-signature Show Save:signature.asc (818B)]
------- End of forwarded message -------

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.