(tl;dr: We'd like more information about how onion services are deployed, and whether we should re-think about the current assumption that connections with all onion services are secure. Do you send HTTP (unencrypted/unauthenticated) traffic between the onion service and a remote web server?)
Hello everyone,
Recently we received a question and concern regarding how Tor Browser interacts with web sites over HTTP. Over the last few years, Tor Browser has increasingly trusted HTTP connections with a .onion address (HTTP+.onion) due to the inherent security properties of onion services.
The security assumptions Tor Browser makes about these connections is based on another critical assumption: connections between the onion service and the destination web server are "secure" [0]. This assumption is correct when an onion service is run beside the web server and connections between the two components are over localhost/loopback/etc. However, onion services can connect to a remote web server instead, and when the connection between those hosts/components is not secure then Tor Browser's security assumption about the overall connection is wrong. Let's call this latter configuration an "onion tunnel" (for lack of a better term right now).
We are now aware some web sites are deploying onion tunnels where the connection between the onion service and the web server is not secure. As a result, we are considering reverting [1] a change of behavior in Tor Browser where "secure cookies" may leak in plaintext under some circumstances in an onion tunnel deployment.
Tor Browser treats connections with onion services as secure in other ways, as well. We'd like more information about how onion services are deployed, and whether we should re-think about the current assumption that all .onion connections are secure.
Do you know of deployments where HTTP (unencrypted/unauthenticated) traffic is sent between the onion service and a remote web server?
(Please email me privately if you feel more confortable with that.)
Thanks, Matt
[0] In this context, let's say "secure" means a connection that provides unidirectional authenticity, and bidirectional integrity and confidentiality. TLS is the typical example, but onion services provide these properties, too.
[1] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40033
Hi there,
On 21. Jul 2020, at 00:44, Matthew Finkel sysrqb@torproject.org wrote:
(tl;dr: We'd like more information about how onion services are deployed, and whether we should re-think about the current assumption that connections with all onion services are secure. Do you send HTTP (unencrypted/unauthenticated) traffic between the onion service and a remote web server?)
I operate multiple such onion services, two see public use and some don't. I will ignore the private ones here.
The two public ones are addresses for my university's ftp mirror, https://ftp.fau.de and they are fauftpffbmvh3p4h.onion (v2) and ftpfaudev4triw2vxiwzf4334e3mynz7osqgtozhbc77fixncqzbyoyd.onion (v3).
I set up the v2 onion many years ago after playing around with vanity URLs briefly mostly as a joke, but people really liked it and then I also found a use for it for some tor-only linux systems. That's why I also set up a v3 onion a few months ago when light-heartedly pressured to do so by the operators of the web site. They have put the following disclaimer on their site:
This server can also be reached as a (V3) service on the Tor network: http://ftpfaudev4triw2vxiwzf4334e3mynz7osqgtozhbc77fixncqzbyoyd.onion/.
However, please note that this service is not run by the FTP admins directly on this server, but by someone from the computer-science-department in the same building. That mostly means that your traffic will be travelling unencrypted through the machine doing the proxying and some routers in the building, so you need to trust not only us but also at least this guy. HTTPS is not available for this service (mostly because currently only very expensive EV-certificates could be used for onion-services, there is no 'letsencrypt'-equivalent available). The RRZE FTP Admins cannot influence the running of this service in any way, we do not know how stable it is, we cannot debug it, and so on.
The university is absolutely not ready to run tor on their mirroring system, so I either do it this way or I have no convenient way of updating my tor-only systems. People using this service have to check signatures of anything they download, as I could have tampered with it or the operators of the three switches between the hidden service and the website.
If there were some sensible way to have https which terminates at their end while they don't have to operate a hidden service, I am pretty sure we could work something out and I would obviously go for it.
Cheers Sebastian
On Tue, Jul 21, 2020 at 01:47:40AM +0200, Sebastian Hahn wrote:
If there were some sensible way to have https which terminates at their end while they don't have to operate a hidden service, I am pretty sure we could work something out and I would obviously go for it.
For our research group's university-run web server (https://crysp.uwaterloo.ca/), I do a "split onion/https" setup where the machine running the onion service (http://uwcryspionvholmkfxoqt2xns5mvnct34ytacugxtqpqrnka2oqm6kqd.onion/) has a localhost-listening proxy, which can be a pretty lightweight custom thing, or a very simple Apache (for example) configuration:
SslProxyEngine On ProxyPass / https://crysp.uwaterloo.ca/
So then it's onion from the client to the onion service, HTTP to the localhost proxy, and HTTPS from the proxy to the remote (but in the same building) server. If there's something amiss with the HTTPS connection to the remote server, presumably Apache will complain and not send, e.g., secure cookies. That's admittedly up to Apache, and not the client, but it's better than the "last mile" being plain HTTP. And for bonus points, the people who run the real backend webserver don't have to do anything special at all.
I wonder if a "lightweight custom proxy" that just fetches pages from one specific host over https might get bundled with tor for easy onion service setup?
On Tue, Jul 21, 2020 at 01:47:40AM +0200, Sebastian Hahn wrote:
Hi there,
Thanks Sebastian.
I set up the v2 onion many years ago after playing around with vanity URLs briefly mostly as a joke, but people really liked it and then I also found a use for it for some tor-only linux systems. That's why I also set up a v3 onion a few months ago when light-heartedly pressured to do so by the operators of the web site. They have put the following disclaimer on their site:
This server can also be reached as a (V3) service on the Tor network: http://ftpfaudev4triw2vxiwzf4334e3mynz7osqgtozhbc77fixncqzbyoyd.onion/.
However, please note that this service is not run by the FTP admins directly on this server, but by someone from the computer-science-department in the same building. That mostly means that your traffic will be travelling unencrypted through the machine doing the proxying and some routers in the building, so you need to trust not only us but also at least this guy. HTTPS is not available for this service (mostly because currently only very expensive EV-certificates could be used for onion-services, there is no 'letsencrypt'-equivalent available). The RRZE FTP Admins cannot influence the running of this service in any way, we do not know how stable it is, we cannot debug it, and so on.
The university is absolutely not ready to run tor on their mirroring system, so I either do it this way or I have no convenient way of updating my tor-only systems. People using this service have to check signatures of anything they download, as I could have tampered with it or the operators of the three switches between the hidden service and the website.
This disclaimer is very good. Thanks for describing this deployment.
If onion services like this can't be secured (using something like Ian's suggestion), then I wonder how Tor Browser can learn that a connection should not be considered secure. One thought is that we could add another torrc option (HiddenServiceInsecureExtension 0|1) and tor puts that information into the onion service descriptor (and Tor Browser could query this over the control port).
Along the same line, this is relevant when the onion service is operated by a third-party (and the connection is not end-to-end secure). I don't know how (or if) Tor Browser should learn about that trust-relationship and change its behavior. This configuration is similar to a CDN providing TLS termination, as long as the website operator (or the client) trust the third-party onion service operator.
If there were some sensible way to have https which terminates at their end while they don't have to operate a hidden service, I am pretty sure we could work something out and I would obviously go for it.
I like Ian's example, if that is an option. I see that nginx supports something similar, too. I can imagine a hacky socat solution, too (but a reverse proxy is less of a ducktape-and-chewing-gum design).
Matthew Finkel:
On Tue, Jul 21, 2020 at 01:47:40AM +0200, Sebastian Hahn wrote:
Hi there,
Thanks Sebastian.
I set up the v2 onion many years ago after playing around with vanity URLs briefly mostly as a joke, but people really liked it and then I also found a use for it for some tor-only linux systems. That's why I also set up a v3 onion a few months ago when light-heartedly pressured to do so by the operators of the web site. They have put the following disclaimer on their site:
This server can also be reached as a (V3) service on the Tor network: http://ftpfaudev4triw2vxiwzf4334e3mynz7osqgtozhbc77fixncqzbyoyd.onion/.
However, please note that this service is not run by the FTP admins directly on this server, but by someone from the computer-science-department in the same building. That mostly means that your traffic will be travelling unencrypted through the machine doing the proxying and some routers in the building, so you need to trust not only us but also at least this guy. HTTPS is not available for this service (mostly because currently only very expensive EV-certificates could be used for onion-services, there is no 'letsencrypt'-equivalent available). The RRZE FTP Admins cannot influence the running of this service in any way, we do not know how stable it is, we cannot debug it, and so on.
The university is absolutely not ready to run tor on their mirroring system, so I either do it this way or I have no convenient way of updating my tor-only systems. People using this service have to check signatures of anything they download, as I could have tampered with it or the operators of the three switches between the hidden service and the website.
This disclaimer is very good. Thanks for describing this deployment.
If onion services like this can't be secured (using something like Ian's suggestion), then I wonder how Tor Browser can learn that a connection should not be considered secure. One thought is that we could add another torrc option (HiddenServiceInsecureExtension 0|1) and tor puts that information into the onion service descriptor (and Tor Browser could query this over the control port).
Along the same line, this is relevant when the onion service is operated by a third-party (and the connection is not end-to-end secure). I don't know how (or if) Tor Browser should learn about that trust-relationship and change its behavior. This configuration is similar to a CDN providing TLS termination, as long as the website operator (or the client) trust the third-party onion service operator.
Exactly. At the end it boils down to trust that the server side operator does not mess up things. I don't think there is anything a browser can do about that which is reflected in ways the specifications are written. If you take the secure context specification[1], as it is relevant here, then you see the secure context does _not_ depend on how the server-side setup looks like in detail (e.g. whether there are ways that the traffic travels over plain HTTP after TLS got terminated).
Georg
On 21. Jul 2020, at 05:58, Matthew Finkel sysrqb@torproject.org wrote: On Tue, Jul 21, 2020 at 01:47:40AM +0200, Sebastian Hahn wrote:
If there were some sensible way to have https which terminates at their end while they don't have to operate a hidden service, I am pretty sure we could work something out and I would obviously go for it.
I like Ian's example, if that is an option. I see that nginx supports something similar, too. I can imagine a hacky socat solution, too (but a reverse proxy is less of a ducktape-and-chewing-gum design).
I also like Ian's suggestion, but it is not a fix. There's no end to end https between browser and webserver, users still need to trust me to not modify traffic. It only gets rid of the transport issue (which I don't worry about too much in this instance, tbh).
Cheers Sebastian
On Tue, Jul 21, 2020 at 07:52:41PM +0200, Sebastian Hahn wrote:
On 21. Jul 2020, at 05:58, Matthew Finkel sysrqb@torproject.org wrote: On Tue, Jul 21, 2020 at 01:47:40AM +0200, Sebastian Hahn wrote:
If there were some sensible way to have https which terminates at their end while they don't have to operate a hidden service, I am pretty sure we could work something out and I would obviously go for it.
I like Ian's example, if that is an option. I see that nginx supports something similar, too. I can imagine a hacky socat solution, too (but a reverse proxy is less of a ducktape-and-chewing-gum design).
I also like Ian's suggestion, but it is not a fix. There's no end to end https between browser and webserver, users still need to trust me to not modify traffic. It only gets rid of the transport issue (which I don't worry about too much in this instance, tbh).
Yes, the "onion service-in-the-middle" design requires that someone trust the onion service operator (either the client or the website administrator).
In the future, maybe the website can use a SOOC [0] (TLS certificate) with a binding for your onion service. If not, then solving this problem will be difficult without the admin deploying their own onion service and/or using a DV cert containing the .onion address.
[0] https://github.com/alecmuffett/onion-dv-certificate-proposal/blob/master/tex...
tor-project@lists.torproject.org
-
Georg Koppen -
Ian Goldberg -
Matthew Finkel -
Sebastian Hahn