Allow end-to-end request encryption using SNI in Translation Mode

[DonnchaC]

The current Tor2Web model entrusts Tor2Web operators with access to the content of users requests. As a result publicly hosted Tor2Web instance are at risk of coercive or other types of threats which could allow an attacker to access the traffic of user requests.

Ideally it would be possible for connections to be end-to-end encrypted from the user's browser until termination on the hidden service server. With the broad deployment of SNI SSL headers this should now be possible for hidden services being provided in Translation Mode.

When Tor2Web receives a new SSL connection, it should determine if the SNI header corresponds to a translated hidden service. Any matching SSL connections should be transparently forwarded to the backend hidden service which had a listener for the SSL connection.

To enable this type of feature:

• The hidden service should register a public domain name and purchase an SSL certifcate for that domain.
• The hidden service operator adds their SSL key and cert to their hidden service web server.
• The operator finds a Tor2Web service provider who is willing to act as a translator for their service and registers their front domain:onion address pair.
• The operator points the domain DNS to a server provided by the Tor2Web operator. DANE or similar key pinning techniques may provided better SSL cert authentication in future.

This type of public domain->onion translation could be provided by public service providers for free or a fee with lower trust requirements. It would allow anonymous service operators to allow public access to their services while maintaining user privacy and removing Tor2Web operators as a potential passive threat.

GlobalLeaks operators could benefit from the increased accessibility without the potential risks of running clearnet infrastructure themselves.

I'd like to try help with this feature in the near future if I can find the time. I'd be interested in hearing any feedback on this idea.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/25476459-allow-end-to-end-request-encryption-using-sni-in-translation-mode?utm_campaign=plugin&utm_content=tracker%2F318575&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F318575&utm_medium=issues&utm_source=github).

[DonnchaC]

I've written a proof-of-concept tool in Twisted which implements this type of SSL proxying at https://gist.github.com/DonnchaC/4a89bf7c52500a1d7e7b. It's my first time writing Twisted so please excuse the code quality :)

I have a demo proxy server running on 188.166.53.117:443 which will forward requests for https://oniontip.com to its hidden service running on https://ha2zlm2uo6hnhdha.onion. Setting '188.166.53.117 oniontip.com' in your /etc/hosts should allow you to test it. I'll only be keeping the proxy running for a few days.

See some of you at Camp!

[evilaliv3]

well done @DonnchaC

the PoC looks really good and the idea is so interesting. i'm wondering what are the benefits for the user and what is the use case.

here are my questions:

1. ok the HiddenService can force to be accessed only this way by the tor2web proxy, but a proxy is a proxy and can do whatever it wants inside hiding details of what it alters or what it sniffs so that i'm not getting the point of what is the added value guarantees for the end user.

2. in order to properly make the HTTP connections work, tor2web need to alter headers/cookies/urls due to the fact that the browser and the hidden service are both not aware of this change. what we can do i starting thinking if it is possible to make at least the HS aware of this (and so the hidden service can fix something while serving it) but what about what the browser side?

sadly i won't be at the CCC but you should for sure get in touch with @fpietrosanti @hellais and @vecna and take care of empower yourself with the benefits of our embassy like the italian grappa!

[DonnchaC]

This feature would allow users to access a hidden service via a clearnet domain chosen by the hidden service.

For example I run the hidden service myblogah4i29js0.onion. I would like the (large amount of) people who don't use Tor to still be able to access my website with privacy. I register the domain myblog.com and acquire an SSL certificate for it, via the LetsEncrypt CA for example.

I start a SSL server on my onion at myblogah4i29js0.onion:443 with this SSL certificate. I then point my domain myblog.com at one or more Tor2Web servers. This domain pointing could be done by running a custom nameserver which will DNS round robin between Tor2Web instances.

As a user I request https://myblog.com in a browser. My connection will then be directed to a Tor2Web node. The Tor2Web node reads the SSL SNI header and forwards the SSL encrypted connection to the hidden service without access to any of the content.

The Tor2Web just sees the SSL connection without access to any of the content, or with out the SSL key to decrypt the content. The hidden service which is running the web server will need to do an domain rewriting at the web server end.

[fpietrosanti]

Ok, i got the idea and i like it, but there is a scalability problem, because the tor2web node operator must configure "explicitly" on his node the domain:onion mapping that can bring: A) additional liability for t2w node operator B) would make tor2web non-stateless (today t2w has no local-db to operate as a public gateway

We could fix it by introducing the need for the Tor hs site to configure a DNS entry like torhs.myblog.com where tor2web can lookup the domain:torhs mapping with a TXT record.

That way the public tor2web network will be able to internet expose autonomously (without any explicit cooperation by tor2web node operators) many https://myblog.com sites.

That seems a quite interesting new way to use tor2web in a much more accessibile way.

Btw we shall consider the additional problems related to keeping tor2web nodes online without an abuse reporting mechanism that's visible on enduser sites.

I may consider that the website being exposed shall be embed into an "iframe" to expose the disclaimer/abuse reporting form from within the bottom/header of the website visible in the browser.

Sent from mobile

[fpietrosanti]

An additional way to use that feature, is the one highlighted by Alec on Twitter https://twitter.com/AlecMuffett/status/658445796619264002 .

Basically we could have an additional operating method that, if the SNI's target domain is the Tor2web base-domain, and the "host part" validate the TorHS format, then we shall forward this request as an HTTPS-requests

[virgil]

Technically speaking, this is a lovely idea.

There is a concern that if you enable this only for specific .onion sites, you lose your common carrier protection in the USA. Unclear what happens in other jurisdictions. Simply to say that if someone does this, she is acting with less legal protections than in the current tor2web setup. I personally would add a big warning in the README though. This option is definitely giving someone a loaded gun with which to shoot herself.

However, if someone wants to live dangerously, I suppose that is her choice.

[DonnchaC]

So after lots of delays there is now a basic but functional implementation to the SNI proxy in Go. It's being developed at https://github.com/DonnchaC/oniongateway. Are any of the existing Tor2Web operators willing to deploy this for testing?

[fpietrosanti]

Encrypted SNI is coming https://blog.cloudflare.com/esni/

[drzraf]

A bit orthogonal to Tor2web (but may be of interest to Globaleaks): Overview at zero-config options (from client PoV) for e2e WITH destination obfuscation.. it's not about hidden-services but about client posting a document without revealing this upload's destination to a wire eavesdropper.

1. Using a browser configuration (right-most)
2. At its direct left is basically a purely theoretical JS-native HTTPS proxy implementation. This tls.js could be forge).
3. Middle columns: Using coming-soon(?) standards (once browser vendors implement/enable them by default). (encrypt.to proved client-side encryption practicable with today's browsers)

I miss a Javascript API allowing requests to flow using a specific proxy configuration for the lifetime of this webpage: This page requests your authorization to proxify requests via https://foobar.com. Accept/reject?. Would be so much simpler! /edit : https://developer.mozilla.org/en-US/docs/Web/HTTP/Proxy_servers_and_tunneling/Proxy_Auto-Configuration_(PAC)_file