Proposal: End-to-end encrypted onion services for non-Tor clients
Hello all, I have been thinking about ideas to make Tor hidden services more available and secure for non-Tor users. Inline I've included a draft proposal which describes an end-to-end encrypted Tor2Web-like system. I'm really interested in hearing any suggestions, comments or criticism about this proposal. In particular I'd like to know if the trust requirements for the entry proxies and resolvers seem reasonable? Does this proposal make sense and is it something worth implementing? Thank you to David Stainton and Leif Ryge for your feedback on this proposal. Kind Regards, Donncha --- Filename: xxx-encrypted-onion-services-for-non-tor-clients.txt Title: End-to-end encrypted onion services for non-Tor clients Author: Donncha Ó Cearbhaill Created: 22-Aug-2015 Status: Draft 1. Overview: This proposal describes a system to allow non-Tor users to securely access location-hidden services via a domain name chosen by the hidden service operator. 2. Motivation: Tor hidden services have typically been used to provide anonymity to both services and clients. There are however use cases where a publisher or content provider requires anonymity but their users do not. The publishers typically would like their content to be available securely and to the widest possible audience. Tor2Web currently allows non-Tor users to access hidden services but it has a number of limitations. Tor2Web deployments are limited due to requirement to entrust Tor2Web service providers with users location information and the content of their requests. The onion subdomain based addressing in Tor2Web poses a usability issue and can be unwieldy for users without providing any self-authenticating properties. Tor2Web can be configured with a custom domain for an individual hidden service but this requires manual configuration and additional infrastructure. Ideally non-Tor users should be able to access location-hidden services under a standard domain name with end-to-end encryption from the client's browser to the hidden service web server. The system should be decentralized and it should not require the hidden service operator to run any clearnet systems. 3. Proposal: At a high level this proposal specifies a system of TCP entry proxies which transparently proxy the TLS connections of non-Tor clients to a hidden service. A client who requests a domain name such as https://myblog.com should get connected to a hidden service endpoint which has a valid SSL certificate for myblog.com. 3.1. Hidden Service configuration A hidden service operator obtains a public domain name and a corresponding CA signed SSL certificate. The operator configures the hidden service web server with the SSL certificate for the external domain. The domain name is pointed at an authoritative nameserver provider. The operator should also set a TXT DNS record containing the onion address of their hidden service. 3.2. Entry Proxy Modern web browsers send a Server Name Indication (SNI) field in the initial ClientHello of the TLS handshake. The entry proxy reads this field to determine the clients destination domain. The proxy performs a DNS lookup at that domain for a TXT record which specifies the corresponding onion address for the provided domain. The TLS entry proxy connects to the onion service via a Tor2Web-type circuit and then begins transparently proxying TLS traffic between the clients browser and the destination onion service. 3.3. Resolving Nameserver The key component of this system is a DNS name server which can direct clients to an online entry proxy via a round-robin type system. In a basic solution the onion service operator could manually specify one or more entry proxies in the A records for their domain on their existing authoritative DNS provider. In practice entry proxy churn would result in changing set of entry proxies. The nameserver will need regularly update its set of online entry proxies an remove proxies which are malfunctioning, malicious or otherwise unusable. The resolver may run a scanner to check its known proxies or load a list from an external service. Additionally the resolver should detect if an entry proxy blacklists a domain for which it is responsible and avoid routing clients to that entry proxy. It is expected that independent service providers will run their own domain->onion resolving nameserver in diverse jurisdictions as free or paid services. 4. Implementation: The entry proxy component could be implemented as part of the current Tor relay code base. Integration directly within Tor would allow use of the existing network consensus and bandwidth measurement systems to be used to discover available entry proxies. It would also allow for malicious entry proxies to be blacklisted. Alternatively the entry proxy could be implemented in the existing Tor2Web software or as a standalone software package. Implementing outside of Tor would be faster and it would avoid the risk of losing Tor relay capacity as a result of legal threats to the entry proxies. The resolving nameserver is the most complicated component of this system. The component will eventually require a DNS server, a management interface, and a set of network monitoring tools. 5. Security and resiliency implications: 5.1. Availability Attacks: Adversaries can attack the availability of a publicly-proxied hidden service at a number of levels: * Censorship or shutdown of entry proxy: Attacks on individual entry proxies are mitigated by performing DNS based round-robin between many online entry proxies. The Resolver system should be able to quickly remove entry proxies which misbehave or which go offline. * Censorship or seizure of the hidden service public domain: DNS based blocks are widely deployed for censorship and may be difficult to avoid. Domain registrars can also be forced to suspend domain names. Service operators should considering running their service under a TLD which is less vulnerable to these type of coercive threats. * Takedown of a nameserver provider: Multiple resolving nameservers can be configure for each forwarded domain. Using nameservers maintained by different providers can provide resilience to attacks against a single nameserver provider. 5.2. Security Attacks: Entry proxies and exit relays have a similar ability to monitor and interfere with client traffic. This is greater risk of targeted interference from entry proxies as they can also determine the client's network location. * Man-in-the-middle HTTP connections: Entry proxies have the ability to man-in-the-middle HTTP connections. Service operators should send HSTS header to force clients to automatically use TLS for all future connections. * TLS man-in-the-middle with CA-signed certificate Some commercial CA cert providers allow for domain ownership to be validated by providing a file over HTTP at the domain. A malicious entry proxy could successfully obtain a CA-signed certificate from one of these certificate authorities. Service operators can minimize their exposure to this type of attack by using HPKP headers to limit the set of valid certificate authorities for their domain.
On Mon, 14 Sep 2015 16:12:23 +0000 Donncha O'Cearbhaill <donncha@donncha.is> wrote:
I have been thinking about ideas to make Tor hidden services more available and secure for non-Tor users. Inline I've included a draft proposal which describes an end-to-end encrypted Tor2Web-like system.
I'm really interested in hearing any suggestions, comments or criticism about this proposal. In particular I'd like to know if the trust requirements for the entry proxies and resolvers seem reasonable? Does this proposal make sense and is it something worth implementing?
I don't understand the use case for this, given the design presented. If the HS operator is willing to register a domain, run a public name server, and pay for a CA cert, why host the actual content on a Tor HS? It should be emphasized that the user has absolutely zero anonymity under this scheme, in that anyone tapping the link between the user and the proxy can see what domain the user is trying to view. Anyone with the capability to inject RSTs can censor on a per-site basis as well. Regards, -- Yawning Angel
Yawning Angel:
On Mon, 14 Sep 2015 16:12:23 +0000 Donncha O'Cearbhaill <donncha@donncha.is> wrote:
I have been thinking about ideas to make Tor hidden services more available and secure for non-Tor users. Inline I've included a draft proposal which describes an end-to-end encrypted Tor2Web-like system.
I'm really interested in hearing any suggestions, comments or criticism about this proposal. In particular I'd like to know if the trust requirements for the entry proxies and resolvers seem reasonable? Does this proposal make sense and is it something worth implementing?
I don't understand the use case for this, given the design presented.
If the HS operator is willing to register a domain, run a public name server, and pay for a CA cert, why host the actual content on a Tor HS?
I think that a hidden service operator should be able run this anonymously. It's possible to purchase domains names anonymously and soon it will (hopefully) be possible to obtain a CA cert for free from the LetsEncrypt CA. The public name server would typically not be run by the hidden service operator but by an independent third-party provider.
It should be emphasized that the user has absolutely zero anonymity under this scheme, in that anyone tapping the link between the user and the proxy can see what domain the user is trying to view. Anyone with the capability to inject RSTs can censor on a per-site basis as well.
Your right, the complete lack of user anonymity is a major trade-off and should be emphasised strongly in this scheme. I see this proposal as simply an extension and enhancement of Tor2Web. It makes the same anonymity tradeoffs but provides end-to-end encryption and allows the hidden service operator to use their own domain name. Tor2Web is by necessity very centralised. They need to share their wildcard CA cert amongst all participating Tor2Web nodes. The limited number of nodes also puts the service at constant risk of outages. This proposal would allow a more decentralised system while adding improving usability and confidentiality for the user. Regards, Donncha
Hi, do you know about https://github.com/mzeltner/tor2tcp-sample and https://poum.niij.org/ ? Sincerely, Malte
Hello, coming from several years of working on Tor2web project, i think that the Donncha concept in leveraging TLS/SNI header together with direct integration within Tor, would be of great benefit to bridge "The Internet" with the "Deep Web" at TCP level. Regarding anonymity of a A Tor Onion Service operator while registering a Domain and Certificate: a) Today it's possible to acquire a domain+certificate bundle anonymously today using pre-paid gift debit/credit card available in most countries in the world. b) Today it's possible to acquire a free .tk domain along with free dns c) With the upcoming Lets Encrypt based on ACME protocol, it will be even easier and immediate to have free-automatic x509v3 certificate for use with TLS. So it will be basically possible by the end of the year to have a full anonymous service of Domain + Certificate + Hosting (TorHS). With such an improvement of Tor2web mode, implemented within Tor software code, making it easier to be implemented with a configuration line, it would be a quite strong approach. I think that a Tor Relay that do provide such a service, shall have a specific descriptor in the consensus. That way it would be possible: 1) to have volounteers to run custom NS that for "thetorrelaythatdoestor2webservice.org" can resolve to the list of all the Tor Relay IP. 2) to have the myblog.com owner to map his site to a CNAME of thetorrelaythatdoestor2webservice.org It's worth discussing it, willing to bring beer to a conversation at about it at upcoming Tor Dev Meeting! ;) -naif On 9/14/15 6:12 PM, Donncha O'Cearbhaill wrote:
Hello all,
I have been thinking about ideas to make Tor hidden services more available and secure for non-Tor users. Inline I've included a draft proposal which describes an end-to-end encrypted Tor2Web-like system.
I'm really interested in hearing any suggestions, comments or criticism about this proposal. In particular I'd like to know if the trust requirements for the entry proxies and resolvers seem reasonable? Does this proposal make sense and is it something worth implementing?
Thank you to David Stainton and Leif Ryge for your feedback on this proposal.
Kind Regards, Donncha
---
Filename: xxx-encrypted-onion-services-for-non-tor-clients.txt Title: End-to-end encrypted onion services for non-Tor clients Author: Donncha Ó Cearbhaill Created: 22-Aug-2015 Status: Draft
1. Overview:
This proposal describes a system to allow non-Tor users to securely access location-hidden services via a domain name chosen by the hidden service operator.
2. Motivation:
Tor hidden services have typically been used to provide anonymity to both services and clients. There are however use cases where a publisher or content provider requires anonymity but their users do not. The publishers typically would like their content to be available securely and to the widest possible audience.
Tor2Web currently allows non-Tor users to access hidden services but it has a number of limitations. Tor2Web deployments are limited due to requirement to entrust Tor2Web service providers with users location information and the content of their requests.
The onion subdomain based addressing in Tor2Web poses a usability issue and can be unwieldy for users without providing any self-authenticating properties. Tor2Web can be configured with a custom domain for an individual hidden service but this requires manual configuration and additional infrastructure.
Ideally non-Tor users should be able to access location-hidden services under a standard domain name with end-to-end encryption from the client's browser to the hidden service web server. The system should be decentralized and it should not require the hidden service operator to run any clearnet systems.
3. Proposal:
At a high level this proposal specifies a system of TCP entry proxies which transparently proxy the TLS connections of non-Tor clients to a hidden service. A client who requests a domain name such as https://myblog.com should get connected to a hidden service endpoint which has a valid SSL certificate for myblog.com.
3.1. Hidden Service configuration
A hidden service operator obtains a public domain name and a corresponding CA signed SSL certificate. The operator configures the hidden service web server with the SSL certificate for the external domain.
The domain name is pointed at an authoritative nameserver provider. The operator should also set a TXT DNS record containing the onion address of their hidden service.
3.2. Entry Proxy
Modern web browsers send a Server Name Indication (SNI) field in the initial ClientHello of the TLS handshake. The entry proxy reads this field to determine the clients destination domain. The proxy performs a DNS lookup at that domain for a TXT record which specifies the corresponding onion address for the provided domain.
The TLS entry proxy connects to the onion service via a Tor2Web-type circuit and then begins transparently proxying TLS traffic between the clients browser and the destination onion service.
3.3. Resolving Nameserver
The key component of this system is a DNS name server which can direct clients to an online entry proxy via a round-robin type system. In a basic solution the onion service operator could manually specify one or more entry proxies in the A records for their domain on their existing authoritative DNS provider.
In practice entry proxy churn would result in changing set of entry proxies. The nameserver will need regularly update its set of online entry proxies an remove proxies which are malfunctioning, malicious or otherwise unusable.
The resolver may run a scanner to check its known proxies or load a list from an external service. Additionally the resolver should detect if an entry proxy blacklists a domain for which it is responsible and avoid routing clients to that entry proxy.
It is expected that independent service providers will run their own domain->onion resolving nameserver in diverse jurisdictions as free or paid services.
4. Implementation:
The entry proxy component could be implemented as part of the current Tor relay code base. Integration directly within Tor would allow use of the existing network consensus and bandwidth measurement systems to be used to discover available entry proxies. It would also allow for malicious entry proxies to be blacklisted.
Alternatively the entry proxy could be implemented in the existing Tor2Web software or as a standalone software package. Implementing outside of Tor would be faster and it would avoid the risk of losing Tor relay capacity as a result of legal threats to the entry proxies.
The resolving nameserver is the most complicated component of this system. The component will eventually require a DNS server, a management interface, and a set of network monitoring tools.
5. Security and resiliency implications:
5.1. Availability Attacks:
Adversaries can attack the availability of a publicly-proxied hidden service at a number of levels:
* Censorship or shutdown of entry proxy:
Attacks on individual entry proxies are mitigated by performing DNS based round-robin between many online entry proxies. The Resolver system should be able to quickly remove entry proxies which misbehave or which go offline.
* Censorship or seizure of the hidden service public domain:
DNS based blocks are widely deployed for censorship and may be difficult to avoid. Domain registrars can also be forced to suspend domain names. Service operators should considering running their service under a TLD which is less vulnerable to these type of coercive threats.
* Takedown of a nameserver provider:
Multiple resolving nameservers can be configure for each forwarded domain. Using nameservers maintained by different providers can provide resilience to attacks against a single nameserver provider.
5.2. Security Attacks:
Entry proxies and exit relays have a similar ability to monitor and interfere with client traffic. This is greater risk of targeted interference from entry proxies as they can also determine the client's network location.
* Man-in-the-middle HTTP connections:
Entry proxies have the ability to man-in-the-middle HTTP connections. Service operators should send HSTS header to force clients to automatically use TLS for all future connections.
* TLS man-in-the-middle with CA-signed certificate
Some commercial CA cert providers allow for domain ownership to be validated by providing a file over HTTP at the domain. A malicious entry proxy could successfully obtain a CA-signed certificate from one of these certificate authorities.
Service operators can minimize their exposure to this type of attack by using HPKP headers to limit the set of valid certificate authorities for their domain.
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - https://globaleaks.org - https://tor2web.org - https://ahmia.fi
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, I like the idea of having a secure way for the non Tor users to browse hidden service content. Given the design presented, someone who wants to do it will need to rely on third parties: domain name registers, DNS providers, hosting providers, commercial CA SSL providers, etc. All these are 'centralized systems', they can be tied to a real world identity / company / address, follow the traces of the payments made for these services as well as, most important, hijack the services, issue subpoenas to the providers, gag orders, censor the services, take over the services, monitor them, you name it. These are exactly for what we have Tor hidden services, to avoid all these threats and redefine "trust" in a better, user-oriented way. While I do like the idea of this proposal and consider it important to make the content available in onionland to non Tor users, I think we should have this as a third party maintained separate software, properly documented and with the risks clearly highlighted. I don't like the idea of implementing the entry proxy as part of the Tor relay codebase. By reading your proposal I can understand that Tor doesn't need to be modified in any way to support it. Separate third party documentation and maybe a lightweight entry proxy software would do just fine and simplify things very much. The proposal is applicable with Tor right now, we don't need to modify it, if an operator can get clearnet domain + commercial CA signed SSL cert + DNS hosting + server hosting (for the entry proxy). It's no easy task, and the requirement list is not short, plus you have to do all these for each and every hidden service you have, as opposite to configuring a tor2web server which would work in proxying content from any hidden service. On 9/14/2015 7:12 PM, Donncha O'Cearbhaill wrote:
Hello all,
I have been thinking about ideas to make Tor hidden services more available and secure for non-Tor users. Inline I've included a draft proposal which describes an end-to-end encrypted Tor2Web-like system.
I'm really interested in hearing any suggestions, comments or criticism about this proposal. In particular I'd like to know if the trust requirements for the entry proxies and resolvers seem reasonable? Does this proposal make sense and is it something worth implementing?
Thank you to David Stainton and Leif Ryge for your feedback on this proposal.
Kind Regards, Donncha
---
Filename: xxx-encrypted-onion-services-for-non-tor-clients.txt Title: End-to-end encrypted onion services for non-Tor clients Author: Donncha Ó Cearbhaill Created: 22-Aug-2015 Status: Draft
1. Overview:
This proposal describes a system to allow non-Tor users to securely access location-hidden services via a domain name chosen by the hidden service operator.
2. Motivation:
Tor hidden services have typically been used to provide anonymity to both services and clients. There are however use cases where a publisher or content provider requires anonymity but their users do not. The publishers typically would like their content to be available securely and to the widest possible audience.
Tor2Web currently allows non-Tor users to access hidden services but it has a number of limitations. Tor2Web deployments are limited due to requirement to entrust Tor2Web service providers with users location information and the content of their requests.
The onion subdomain based addressing in Tor2Web poses a usability issue and can be unwieldy for users without providing any self-authenticating properties. Tor2Web can be configured with a custom domain for an individual hidden service but this requires manual configuration and additional infrastructure.
Ideally non-Tor users should be able to access location-hidden services under a standard domain name with end-to-end encryption from the client's browser to the hidden service web server. The system should be decentralized and it should not require the hidden service operator to run any clearnet systems.
3. Proposal:
At a high level this proposal specifies a system of TCP entry proxies which transparently proxy the TLS connections of non-Tor clients to a hidden service. A client who requests a domain name such as https://myblog.com should get connected to a hidden service endpoint which has a valid SSL certificate for myblog.com.
3.1. Hidden Service configuration
A hidden service operator obtains a public domain name and a corresponding CA signed SSL certificate. The operator configures the hidden service web server with the SSL certificate for the external domain.
The domain name is pointed at an authoritative nameserver provider. The operator should also set a TXT DNS record containing the onion address of their hidden service.
3.2. Entry Proxy
Modern web browsers send a Server Name Indication (SNI) field in the initial ClientHello of the TLS handshake. The entry proxy reads this field to determine the clients destination domain. The proxy performs a DNS lookup at that domain for a TXT record which specifies the corresponding onion address for the provided domain.
The TLS entry proxy connects to the onion service via a Tor2Web-type circuit and then begins transparently proxying TLS traffic between the clients browser and the destination onion service.
3.3. Resolving Nameserver
The key component of this system is a DNS name server which can direct clients to an online entry proxy via a round-robin type system. In a basic solution the onion service operator could manually specify one or more entry proxies in the A records for their domain on their existing authoritative DNS provider.
In practice entry proxy churn would result in changing set of entry proxies. The nameserver will need regularly update its set of online entry proxies an remove proxies which are malfunctioning, malicious or otherwise unusable.
The resolver may run a scanner to check its known proxies or load a list from an external service. Additionally the resolver should detect if an entry proxy blacklists a domain for which it is responsible and avoid routing clients to that entry proxy.
It is expected that independent service providers will run their own domain->onion resolving nameserver in diverse jurisdictions as free or paid services.
4. Implementation:
The entry proxy component could be implemented as part of the current Tor relay code base. Integration directly within Tor would allow use of the existing network consensus and bandwidth measurement systems to be used to discover available entry proxies. It would also allow for malicious entry proxies to be blacklisted.
Alternatively the entry proxy could be implemented in the existing Tor2Web software or as a standalone software package. Implementing outside of Tor would be faster and it would avoid the risk of losing Tor relay capacity as a result of legal threats to the entry proxies.
The resolving nameserver is the most complicated component of this system. The component will eventually require a DNS server, a management interface, and a set of network monitoring tools.
5. Security and resiliency implications:
5.1. Availability Attacks:
Adversaries can attack the availability of a publicly-proxied hidden service at a number of levels:
* Censorship or shutdown of entry proxy:
Attacks on individual entry proxies are mitigated by performing DNS based round-robin between many online entry proxies. The Resolver system should be able to quickly remove entry proxies which misbehave or which go offline.
* Censorship or seizure of the hidden service public domain:
DNS based blocks are widely deployed for censorship and may be difficult to avoid. Domain registrars can also be forced to suspend domain names. Service operators should considering running their service under a TLD which is less vulnerable to these type of coercive threats.
* Takedown of a nameserver provider:
Multiple resolving nameservers can be configure for each forwarded domain. Using nameservers maintained by different providers can provide resilience to attacks against a single nameserver provider.
5.2. Security Attacks:
Entry proxies and exit relays have a similar ability to monitor and interfere with client traffic. This is greater risk of targeted interference from entry proxies as they can also determine the client's network location.
* Man-in-the-middle HTTP connections:
Entry proxies have the ability to man-in-the-middle HTTP connections. Service operators should send HSTS header to force clients to automatically use TLS for all future connections.
* TLS man-in-the-middle with CA-signed certificate
Some commercial CA cert providers allow for domain ownership to be validated by providing a file over HTTP at the domain. A malicious entry proxy could successfully obtain a CA-signed certificate from one of these certificate authorities.
Service operators can minimize their exposure to this type of attack by using HPKP headers to limit the set of valid certificate authorities for their domain.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBCAAGBQJV+w0OAAoJEIN/pSyBJlsREtEIALb+D8hAXEhymxdKOHdElsoY X6fJoYsrsp0CaK7hj+ki0OaVp6g7hYm6/JrJhE2jaAlruztjOG6xxmrDvH4oFoYI VsSyzSmN/ohGrQsdKH7nRtT3/9fkeXSRh3EyvLAhGQvfsdtGWn1HgBX8BEuhKOYw Ku9+k2GFMfoZvbx5S/ymAqDm8E7kgdLtHu8AwleuGcz7Q5CM4pE48JK4j887V+xZ i4C4uxnPo/Ox2tGmS/4ieSP9QEUdImvi59kgQ8ZOWlBpaRwulJhOuqc46rETQEp9 4njl3zORo027vWcVhiofurr9UIQ25MU5LEpQCf3jEAh+EY8Pey6VVQoQbVoVXAE= =jQJ0 -----END PGP SIGNATURE-----
participants (5)
-
Donncha O'Cearbhaill -
Fabio Pietrosanti (naif) - lists -
malte＠wk3.org -
s7r -
Yawning Angel