Hi Zied
Interesting problem. I had a brief read of the draft spec. I think it depends on how ECH is implemented. However I cannot help thinking that addressing ECH in isolation might inevitably result in unintended consequences
Then it does depend on source and destination IP. QA would have to include TLS 1.2 and 1.3 as both are in common use.
If you are going to experience network validation problems (because the name certificate is being used as a factor in routing) then maybe it is just one more bandaid on the handshake protocols. TLS 1.3 handshake has vulnerabilities anyway, apart from unencrypted server info.
Without rethinking the whole handshake, because the original problem has not really been solved. How do you trust, and negotiate keys without exposing server information in clear text?
I suppose the question is, what is the simplest, practical way to allow servers to identify approved traffic. It seems to me that a simple encryption is problematic because of all the rule changes to identify the encrypted name. And then what happens if an encryption key/keypair is compromised, how difficult is it to then update all the changes.
I think we have been putting off rethinking the TLS handshake problem for too long. I would prefer to see a new version of TLS that fixes up some of the weaknesses of TLS 1.3 (too many steps in the handshake being one of them IMHO). From a software-defined-perimeter point of view, we had some preliminarty discussions whether it was possible to use a SPA approach (single packet authentication) approach to authenticate and negotiate a communication. I've been thinking that a JWT based handshake would put the complexity into the packet, rather than the hello-ack-response-ack- er hello again which handshake do you want to do, straight, mason's wiggle, double fist knock, -ack-ack ack etc :) :)
On reflection I think a rethink is in order because complex handshakes are being exploited by APT (Advanced Persistent Threat) actors. It is a problem that has not been solved by any Zero Trust Network approach that I know of, including mTLS, which is also very handshake happy too, with vulnerabilities that have been exploited there.
Nya
------------------------------
Nya Murray
Director
Trac-Car
------------------------------
Original Message:
Sent: Jan 04, 2023 04:56:09 AM
From: Zied TURKI
Subject: Is Encrypted Client Hello a challenge for Zero Trust implementation?
Hi all,
"Network" and "Visibility & Analysis" are 2 Zero Trust Pillars. Network security provides a set of security capabilities that help enterprises to protect their assets and comply to a growing set of Policies and Regulations.
On the other hand, privacy in modern internet services is crucial. Industry is still working on Transport Layer Security (TLS) extensions to ensure privacy. ECH (Encrypted Client Hello) [draft-ietf-tls-esni-15 - TLS Encrypted Client Hello] is one of these extensions that is designed to mask the service type (SNI) which goes in plain-text in the initial handshakes of vanilla TLS. The SNI is used by network security capabilities to identify the service type and enforce policies such as (URL filtering, selective inspection, protection, etc.)
TECH adoption will then prevent enterprises' network security middle boxes the access to SNI and makes it difficult and even impossible for some use cases for security teams to defend and perform advanced network analysis.
I am currently working on this topic: 1/ identity the potential impact of ECH adoption on Zero Trust implementation scenarios 2/ Understand the possible alternatives.
Here an active IETF Internet draft that explains ECH deployment considerations for enterprises draft-campling-ech-deployment-considerations-03 - Encrypted Client Hello Deployment Considerations (ietf.org)
Looking forward to your thoughts !
------------------------------
Zied TURKI
Technology & Cybersecurity Specialist
Paris
------------------------------