[TLS] TLS against censorship

[evasilen]

Hi Experts,

I am not a strong person on encryption, but it is evident for me that "TLS
Encrypted Hello"
https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-22 has no value in
fighting censorship.

Whatever DNS name would be used for "client-facing server", it is easy for a
particular country authority to drop traffic directed to it. Because transit
traffic to the real content owners ("backend servers") would not be
affected.

It is especially useless to use a special DNS name (like cloudflare-ech.com)
for "TLS Encrypted Hello" - it is a clear instruction for the country
authority on what to drop.

The fundamental problem here that censors may drop selectively, only to
cloudflare-ecn.com, not to github.com (or many other services). It is not a
situation when they have a danger to completely isolate the country.

Clients would start investigating what has changed in the browser to disable
ECH. It would not work in the same way as it happened for the full SNI
encryption.

 

I could propose the better logic:

1.  The client is choosing SNI randomly among many existing (if service
hiding is needed) or using the real SNI (if hiding is not needed) to write
into the OuterHello.
2.  The client encrypts InnerHello with the public key of "client-facing
server" (if service hiding is needed) or with the public key of the "backend
server" (if hiding is not needed).
3.  The "client-facing server" should always try to decrypt the
InnerHello with its own private key (independent of outer SNI).

If successful, then the real destination could be read from the InnerHello,

If not successful, then the Outer SNI was real.

The censor could not repeat the last step - they do not have the private key
of the "client-facing server".

It is probably not a big burden to ask "client-facing server" to decrypt all
Hello.

It could look that for such a solution, censor could not drop selectively.
They may put them into the dilemma of complete country isolation.

Actually not, they could. The problem that the presence of encrypted
InnerHello is enough to block such solution from proliferation.

You could try to use dummy InnerHello for many years to drive situation to
the case when all Hello has it but it is not used. Then activate InnerHello
on the one day in the browser update.

In such a way you could put censors into the situation "block everything or
nothing".

 

The only real solution would be to have a sort of VPN to CDN providers:

*   The initial Hello would be used to establish communication with
"client-facing server" (some sort of VPN)
*   Then second Hello would be to the "backend server"

It has 2 big drawbacks:

*   Connection would be established in two RTT instead of one.
*   It is a risk for CDN business. If CDN providers would not introduce
such a VPN service synchronously (highly probably), censor would be capable
to punish them one by one

 

Hence, I am pessimistic that ECH (or whatever) would permit to fight
censorship.

It is a fundamental requirement to show real service to have the capability
to forward it to the content provide that has a private key to decrypt.

If service is shown then censorship is possible.

 

PS: Please, keep me on copy of communication - this email is not connected
to datatracker.

Ed/

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: TLS against censorship

[evasilen]

Hi Raghu,
OTTs reading this statement about privacy is probably laughing.
OTTs are collecting the volume of private information - they are the primary 
danger for privacy. ECH would not help even theoretically.
Hence, I do not care about privacy. It is not possible anyway.
I remember a good joke, it was a banner on the street " is hiring in your 
region, resume is not needed".

About your idea to use many DNS names (and probably keys) per IP:UDP.
It looks like it is a burden for censor to trace many DNS names.
Actually, it is not a problem for them, not at all.
As I stated in the message that you did not copy in the quote: they would 
filter out any Hello that has nested InnerHello.
It is pretty automatic solution. As soon as implemented on DPI, this feature 
would not need any configuration or manual intervention.
Only people that upgraded their browser would be punished (not the whole 
population) - they would have to look how to downgrade the browser or disable 
feature.

By the way, InnerHello intersect with interest of many censors, they would 
block it, it would result in the lost hope for privacy too, right?
Eduard
-Original Message-
From: Raghu Saxena  
Sent: Friday, November 15, 2024 5:51 PM
To: evasi...@yandex.ru; tls@ietf.org
Subject: Re: [TLS] TLS against censorship

Dear Ed,

On 11/15/24 4:09 AM, evasi...@yandex.ru wrote:
>
> Hi Experts,
>
> I am not a strong person on encryption, but it is evident for me that 
> “TLS Encrypted Hello”
> https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-22 has no 
> value in fighting censorship.
>
> Whatever DNS name would be used for “client-facing server”, it is easy 
> for a particular country authority to drop traffic directed to it.
> Because transit traffic to the real content owners (“backend servers”) 
> would not be affected.
>
> It is especially useless to use a special DNS name (like
> cloudflare-ech.com) for “TLS Encrypted Hello” – it is a clear 
> instruction for the country authority on what to drop.
>
It's something I've raised in the past, but I think the general IETF consensus 
(well at least for the TLS WG) is that ECH is designed to improve privacy, not 
necessarily fight censorship. That said, server providers who wish to try and 
get around it, can advertise ECH records with "legit" looking domains, since 
they can be configured to not care about the "Outer SNI" at all. As an example, 
you can check out my website, which hosts several different ECH configs on 
different ports[0]. Depending on which port you try and connect to, your client 
should use a different ECHConfig.

Regards,
Raghu Saxena

[0] https://rfc5746.mywaifu.best:4443/


___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: TLS against censorship

[evasilen]

Hi all,

 

*   I don't think there is much ECH spec can do about this - versatility of 
public name construction depends on many internal operational details of the 
hosting service.

Don’t agree. It is possible. Just introduce 2 stages for adoption:

1.  Stage 1: TLS extension that makes no any harm for censors. Add nested 
InnerHello header, just populate it with encrypted nonce (computer name + time 
may be enough).
Censors are lazy, they would not block it because it does not produce immediate 
problem for them.
2.  Stage 2: Monitor the InnerHello header adoption. After it would reach 
90+%, activate the real SNI inside InnerHello.
By the way, do not make a mistake to populate original SNI with the special DNS 
(it is assumed by the current spec), put there some random (but real) DNS name.

 

*   The ECH draft specifies a greasing mechanism that achieves exactly 
that. Clients can insert an ECH extension with fake values -- but only the 
client and the front end server know it is fake. The on-path attackers cannot 
tell -- they just see an ECH extension with a bunch of random bytes in it, 
which is not different from an ECH extension with encrypted data in it. If they 
block these packets, they are going to block way more that their desired 
targets.

Maybe I was not careful enough, I have not found it in the draft. Moreover, the 
article from CloudFlare stress that they would reserve a special DNS name (to 
make life of censor easy). Hence, CloudFlare has read the spec not careful too. 
Strange, right?

I need to repeat again: you currently provision 2 mechanisms for censor’s 
filtering:
1) new header in the hello packet.

2) clear DNS name in the original SNI to point that it is “evasion”.

The first one is an objective problem that needs something special (like 
2-stage feature introduction).

The second one is just an IETF/TLSWG mistake.

Please, clearly specify that original SNI should become finally random DNS name 
(it should be real one!).

 

*   You assume that the censorship will be deployed before the next browser 
versions are deployed, and that a browser that systematically grease the ECH 
extension would become immediately unusable. But blocking new versions of 
browsers will be very costly for the censor -- users do want the security, 
features and bug fixes of the new versions. We have no evidence of that 
happening yet.

Censors do not care about security. The only thing they care is the full 
country isolation from the internet. Up to 10% of population temporary 
isolation from the Internet – is an acceptable trade-off for them.

2 stage feature introduction is mandatory to rise harm from X% to 90%.

 

Ed/

From: Yaroslav Rosomakho  
Sent: Saturday, November 16, 2024 5:48 AM
To: Christian Huitema ; evasi...@yandex.ru
Cc: Raghu Saxena ;  
Subject: Re: [TLS] Re: TLS against censorship

 

Christian,

 

I believe the issue that we are currently observing with "blocked ECH" is 
specific to how public SNI is constructed. A given CDN uses a certain 
pre-defined public name for all ECH enabled resources - hence an inline 
filtering party that wants to prevent ECH can match on that specific public 
name and presence of ECH extension in ClientHello.

 

Ed,

 

I don't think there is much ECH spec can do about this - versatility of public 
name construction depends on many internal operational details of the hosting 
service.

 

On top of that, public SNI is used by some intermediaries to perform their own 
DNS lookup and replace destination IP. This is often done to optimise traffic 
routing by cloud security providers as the closest CDN node from cloud security 
provider perspective could be different than the one resulting from client DNS 
lookup. It is also a technique to prevent certain kinds of domain fronting 
attacks without invasive TLS inspection. Hence, replacing public SNI with a 
random string that would not be resolvable to the correct destination is likely 
to create another set of access issues.

 

Best Regards,

Yaroslav

 

On Sat, Nov 16, 2024 at 2:12 AM Christian Huitema mailto:huit...@huitema.net> > wrote:


On 11/15/2024 9:57 AM, Raghu Saxena wrote:
> Hey Ed,
>
> On 11/16/24 1:08 AM, evasi...@yandex.ru   wrote:
>> Actually, it is not a problem for them, not at all.
>> As I stated in the message that you did not copy in the quote: they 
>> would filter out any Hello that has nested InnerHello.
>> It is pretty automatic solution. As soon as implemented on DPI, this 
>> feature would not need any configuration or manual intervention.
>> Only people that upgraded their browser would be punished (not the 
>> whole population) - they would have to look how to downgrade the 
>> browser or disable feature.
>
> Well yes, any new TLS extension can be directly blocked by DPI if they 
> want. I think practically the best way around such stuff would be to 
> use existing TLS stuff which is too mainstream, e.g. an HTTPS proxy.

Ed,