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.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev