[HTTPS-Everywhere] HTTPS Everywhere 0.3.0.development.1

[Chris Palmer]

> No.  sslstrip can easily be extended to remove
> Strict-Transport-Security headers from responses that it forwards to the
> client (if it does not do so already).


As I understand it, sslstrip will succeed in keeping a user of an HSTS-enabled site downgraded only if the user is connecting to the site, via the sslstrip-pwned network, for the first time in the site's HSTS policy window. HSTS is like SSH in that way: Connect unsafely once, stay safe ever after within the window. If you're pwned the first time, well, too bad.

Although imperfect, that is a huge improvement over the status quo. (Surely you'll agree that SSH is Pretty Good, right?)

> Also, I can't say I trust github's ssl given their latest "SSL Prevention Phase" blog post: https://github.com/blog/743-sidejack-prevention-phase-3-ssl-proxied-assets
> It's not actually ssl, as they put it, "The /src/ attribute is rewritten to proxy through our normal asset servers so it **appears** to come from a secure source." All this does is fix the warning.

They fixed the warning by fixing the problem. Your connections to GitHub servers are protected; inside their network, they might use unprotected communications. Again, a huge improvement over the status quo.

It seems like they are proxying *within their internal network*: the unsafe links are probably between servers on the same subnet (e.g. assets1.github.com is 207.97.227.244, while github.com is 207.97.227.239).

Chances are pretty low that attackers controlling that subnet (which is probably also a single, physically-private Ethernet segment in a locked rack) are in your threat model, because you probably couldn't defeat them anyway. (Examples: maniacs who have physically tampered with Github's rack in the datacenter; datacenter ops people; Github engineers.)

GitHub acted fast to apply an imperfect fix; applied a better fix a week or so later, and buttoned up the last gaps a week or so after that. All along, they were posting about it on their blog. In my (painful and extensive) experience that is (a) objectively awesome; (b) as good as it ever gets; and (c) much better than most of the top 100 sites on the internet. (Compare GitHub's reaction with Live Mail's, Facebook's and Twitter's, for example. GitHub is doing as well as Gmail --- awesome.)

Praise and thank GitHub for their quick achievements, don't bag on them from a position of misunderstanding.


-- 
Chris Palmer
Technology Director, Electronic Frontier Foundation