Use https from NGINX to the origin by default about eotk HOT 3 CLOSED

I had a nightmare of a time attempting to rewrite a secure cookie, so if there's a simple way of doing it I wouldn't mind hearing it.

Eventually I settled on a setup whereby my CMS is configured not to set the Secure flag. The CMS is then fronted by an Nginx instance using my EOTK-generated config for the (non-HTTPS) onion, and by another Nginx instance acting as a SSL terminator to provide clearnet HTTPS.

I'm sure my method of getting Nginx to rewrite the cookie would make competent sysadmins cry, but I ended up doing the following on the SSL terminator:

proxy_cookie_path / "/; secure";

I suppose you could call this an "injection" since I'm effectively modifying the cookie's path to contain a closing semicolon and then just injecting secure after it.

It works, but if there's a way of doing it the other way so that the CMS is handling setting secure cookies, and EOTK is stripping them of the 'secure' flag as they move past, that would probably be much cleaner.

from eotk.

@ajhaydock @FiloSottile - I think the low-hanging fruit here will be to offer an option which will trap port 80 accesses within the onion-rewriter NGINX, and 301/MovedPermanently them over to the corresponding HTTPS URI. Thereby nothing will ever travel in cleartext across the net.

How do you feel about that?

Aside: I have previously tried the related problem of consistently upgrading http://foo.onion to https://foo.com in order to fake the "Onion Transport Is As Good As SSL" thing - and bypassing SSL certificates - and all my attempts so far have bombed-out, in complex ways.

I had a discussion with @FiloSottile about this in Amsterdam - specifically that anonymous/ephemeral Onion sites will be locked-out of HTTPS and thus locked-out of modern browser functionality like WebRTC because ".onion" is not (edit: inherently) marked as a secure Origin.

I think we politely disagree in that I don't believe a browser-side fix will be adequate.

This challenge (treat HTTP over Onion as "secure") was something we considered at Facebook when it wasn't clear we'd be issued a SSL certificate, and the consensus of engineering opinion was that (a) launching-onion-without-SSL was a dealbreaker, not least because (b) refactoring the Facebook CMS/codebase to support "secure" equivalency of a scheme (HTTPS) and a top-level-domain (.onion) was not viable.

In the wider world, too much code does strcmp($scheme, "https") in disparate server codebases (Wordpress?) for it to be economically viable to ALSO fix all popular Tor Browsers to treat onions as secure origins where HTTP can be considered equivalent to HTTPS.

Simply: there will be too many kludges at both ends.

So in the future we will have to hold the CABForum community to their current position that:

https://www.bleepingcomputer.com/news/security/14-766-lets-encrypt-ssl-certificates-issued-to-paypal-phishing-sites/

"CAs are not in a good position to act as content police, we don't have the information we'd need and our validation processes do not assert anything about website content safety," Ash told Bleeping. "If we did try to act as content police any actions we could take would be ineffective. Revocation is too slow and broken. We strongly recommend that people use products like Google Safe Browsing and Microsoft Smartscreen for phishing and malware protection as those products are much more effective than we could ever be in trying to protect people."

...so that once Prop224 lands we may pursue straightforward DV SSL Onions from LetsEncrypt, although that still leaves an undesirable whip-hand over ephemeral or anonymous HTTPS communication.

Hence, @FiloSottile, my crazy ideas about rooting self-signed ".onion" certificates as secure on, and only upon, the Onion/TLD that serves the content. :-)

from eotk.

Implemented and tested.

from eotk.