search

alecmuffett / eotk

Enterprise Onion Toolkit
GNU General Public License v3.0
775 stars 103 forks source link

HTTP onion for HTTPS site #21

Open dogsbody opened 7 years ago

dogsbody commented 7 years ago

I'm pretty sure that this setup is not included in the current configuration options?

The reason is that we are having real trouble getting onion SSL certs for non corporate entities. We will continue to fight obtain them but in the mean time it would be great to have a working solution which would setup an HTTP onion address as a proxy for an HTTPS website.

I will be attempting to submit a pull-request with this code but won't get to it this week so wanted to post it up as an issue in case anyone else fancied doing it :-)

alecmuffett commented 7 years ago

I have tried this, and I think @ajhaydock did similar.

It was a nightmare and after wading around in it for an entire afternoon, I decided to shelve it until I could do more research on the edge cases, ESPECIALLY secure cookies. It struck me as a bad idea to introduce vulnerabilities into a site in pursuit of onionifying it.

But I am willing to give it another go, if someone wants to act as a sounding board for ideas.

alexhaydock commented 7 years ago

Yes, this is how I set up the CryptoParty Newcastle onion, though I ended up having to cheat slightly, after spending a similarly long afternoon trying to puzzle it out.

I wasn't able to find any method of mangling a cookie with Nginx to remove the secure flag, so I ended up configuring the Discourse forum backend not to use HTTPS (causing it to not add the flag).

Then I could point an EOTK instance at it to create the onion, and another Nginx instance at it, to provide standard clearnet HTTPS. On the Nginx instance providing clearnet HTTPS, I re-added the secure flag with:

proxy_cookie_path / "/; secure";

This works for me since the machines are on the same VMware vSwitch so there's no chance of the unencrypted EOTK -> Backend connection being intercepted. Clearly this wouldn't work for what Dogsbody is doing though, since I'm guessing your method is to host the onion service using your own equipment outside of the site's main infrastructure and point it at the existing HTTPS clearnet domain?

I can see about having a look into this since I've got some free time in the coming days. I find it hard to believe that there would be no other way of performing custom cookie rewriting actions with Nginx, so I'll see what I can dig up.

Either way, even with an HTTP-only backend, there was some rewriting that needed doing to the EOTK config before I could host the HTTP-only onion, so there's room to add some options to allow for that in the event that the user wants to point EOTK at an unencrypted server. I suspect it would be a good idea to accompany that with some form of large warning though, noting that it shouldn't be done unless the machines are on the same LAN at least.

alecmuffett commented 6 years ago

Leaving this open to prevent duplication.

micah commented 4 years ago

Now that tor browser turns off secure cookies when accessing an onion site (https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/21537) maybe this issue wouldn't be a problem now?

alecmuffett commented 4 years ago

OMG, they did this? This is very bad.

micah commented 4 years ago

Sorry my comment was a bit wrong, coming from a few years ago archive of my brain... this isn't how it was implemented. Instead .onions just work with secure cookies by not only checking for "https" but ".onion" as well. In other words, treating cookies set with the secure flag by .onion domains as secure as well.

Not that it turns off secure cookies.