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

[Juuso Lapinlampi]

On Sun, Oct 09, 2016 at 11:37:12AM +0200, Hanno Böck 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.

Just letting you know about CSP upgrade-insecure-requests.

It doesn't solve the issue you're pointing out, but redirects clients
from HTTP to HTTPS. Hitting a HTTPS page will also force HTTPS in the
future with HSTS.

In other words, I think this is what Richard wanted, with ability to
browse the Savannah repositories over HTTP too. No programming required?

    $ curl -I http://mirror.se.partyvan.eu/
    HTTP/1.1 200 OK
    [...]
    Content-Security-Policy: upgrade-insecure-requests

    $ curl -I http://mirror.se.partyvan.eu/ -H "Upgrade-Insecure-Requests: 1"
    HTTP/1.1 307 Temporary Redirect
    [...]
    Location: https://mirror.se.partyvan.eu/
    Vary: Upgrade-Insecure-Requests

    $ curl -I https://mirror.se.partyvan.eu/
    HTTP/1.1 200 OK
    [...]
    Strict-Transport-Security: max-age=15768000; includeSubDomains; preload
    Content-Security-Policy: block-all-mixed-content; default-src 'self'
    Public-Key-Pins: pin-sha256=[...]

With block-all-mixed-content, clients supporting it will refuse to
create HTTP requests on that site if HTTP links appear. There are CSP
variations which upgrade HTTP requests to HTTPS.

This way, both HTTP and HTTPS are supported simultaneously. I know at
least Chromium sends the "Upgrade-Insecure-Requests: 1" header with
every page request.

Mind you, the more common 301 redirects (forced HTTP -> HTTPS) are still
vulnerable to stripping too. The HTTP status is cached, but still viable
to MITM on first connection or after cache expiry.

I still don't like the idea of having login pages (or login session
cookies) reachable over HTTP.