Opened 4 years ago

Last modified 3 years ago

#17069 new enhancement

Use false SNI fields, DNS requests for all outgoing connections to cdn-hosted websites

Reported by: elypter Owned by: tbb-team
Priority: Low Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

if all https requests for sites known to use a specific cdn would be sent to only one domain and use the host header to connect to the real target website, an attacker would only be able to know the cdn but not the actual website the user is accessing.

Child Tickets

Change History (10)

comment:1 Changed 4 years ago by nickm

Milestone: Tor: very long term

comment:2 Changed 4 years ago by isis

Priority: majorminor

This is currently infeasible due to being way too expensive.

comment:3 in reply to:  2 ; Changed 4 years ago by elypter

Replying to isis:

This is currently infeasible due to being way too expensive.

if you mean expensive in terms of work then maybe. some core components have to be modiefied and lists have to be maintained for at least but no servers are required. thats only a client thing.

comment:4 in reply to:  3 ; Changed 4 years ago by isis

Replying to elypter:

Replying to isis:

This is currently infeasible due to being way too expensive.

if you mean expensive in terms of work then maybe. some core components have to be modiefied and lists have to be maintained for at least but no servers are required. thats only a client thing.

I meant quite literally in terms of money.

comment:5 in reply to:  4 Changed 4 years ago by elypter

Replying to isis:

I meant quite literally in terms of money.

oh those are quite expensive. for who execpt tor is that an intelligent buisnes choice. a normal vps costs 3% of that.
if it is that expnsive user should be informed to use other pts when possible or set up own appengine accounts like goagent did.

comment:6 Changed 3 years ago by nickm

Component: Core Tor/TorApplications/Tor Browser
Milestone: Tor: very long term
Owner: set to tbb-team
Severity: Normal
Summary: use domain fronting for all outgoing connections to cdn hosted websitesUse false SNI fields, DNS requests for all outgoing connections to cdn-hosted websites

Hang on, does this need to be an expense we bear? What if we only did this for cases where we are already connecting to some site on a CDN? That is, what if somehow had TorBrowser able to notice that it was going to connect to some CDN-hosted domain, and instead of putting that domain in the SNI field of the TLS handshake, it used a generic one instead? If that worked, it wouldn't bring any additional cost to Tor.

comment:7 Changed 3 years ago by nickm

(We can't do this in Tor itself, since it needs to happen at the level of the TLS implementation. Tor can't rewrite an application's ClientHello message, or the TLS handshake would fail.)

comment:8 Changed 3 years ago by dcf

nickm is right, that elypter's suggestion wouldn't be expensive the way meek is. It's not related to bridge blocking; rather it's about surveillance by the exit node.

The idea of having a local database of which web site is on which CDN, and dynamically fronting through some other site on the same CDN as you browse, has some academic papers and a prototype implementation.

I don't think this proposal is really related to Tor, but if someone wants to try it, it might be possible to integrate the cachebrowser-firefox extension with Tor Browser.

comment:9 Changed 3 years ago by tom

The hard part is tor's SOCKs Optimistic Data (or at least I think that's the name for the pat that's the problem.)

If we opened a circuit to a DNS name, and got passed back the IP address, and then constructed the ClientHello and sent it down the circuit - we could hardcode CloudFlare and Akamai's IP spaces and just omit a SNI when talking to them. This might/would probably work, we'd have to test. I know they strongly prefer having clients send SNIs, but I don't know if it's absolutely required.

But since we send the ClientHello down the circuit before we've resolved the name, we have to detect the use of a CDN based off the DNS name alone.

What does HTTPS Everywhere do for this?

comment:10 in reply to:  9 Changed 3 years ago by dcf

Replying to tom:

But since we send the ClientHello down the circuit before we've resolved the name, we have to detect the use of a CDN based off the DNS name alone.

That's how CacheBrowser works, as I understand it. It has a database mapping DNS names to CDNs.

Note: See TracTickets for help on using tickets.