Zero Trust

 View Only
  • 1.  Is Encrypted Client Hello a challenge for Zero Trust implementation?

    Posted Jan 04, 2023 04:56:00 AM
    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 (

    Looking forward to your thoughts ! 

    Zied TURKI
    Technology & Cybersecurity Specialist

  • 2.  RE: Is Encrypted Client Hello a challenge for Zero Trust implementation?

    Posted Jan 05, 2023 08:30:00 AM
    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 Murray

  • 3.  RE: Is Encrypted Client Hello a challenge for Zero Trust implementation?

    Posted Jan 05, 2023 09:16:00 AM

    Hi Nya

    Thank you for sharing your views.

    Yes, ECH is not about rethinking the whole handshake messages. It is only about encrypting the meta data in the ClientHello (SNI, ALPN, etc..)

    Regarding the encryption keys exchange, as per the IETF paper, TLS with ECH encrypts and encapsulates the entire legacy ClientHello handshake message (Inner ClientHello) and sends it as part of the new ClientHello wrapper (Outer ClientHello) message;
    Encryption key (used to encrypt the ClientHello) is obtained through DNS over HTTPS (DoH) using SVCB (SerViCe Binding) or HTTPS RR records.

    Thank you;

    Zied TURKI CISSP #549219
    Technology & Cybersecurity Specialist

  • 4.  RE: Is Encrypted Client Hello a challenge for Zero Trust implementation?

    Posted Jan 05, 2023 09:38:00 AM
    Edited by Jason A. Garbis Jan 05, 2023 09:39:18 AM
    Thanks Zied for posting, and for the link to IETF draft. I have not read this yet, but will.
    And thanks Nya as always for your thoughtful comments. 
    From a SPA perspective, SPA is a great improvement over plan vanilla TCP, but does not solve the key exchange problem (recall, SPA needs a shared secret in order for clients to generate a valid SPA packet).  In the SDP spec we defer to an out-of-band mechanism to distribute this, as part of an implementation-specific onboarding process. So we don't have a complete answer within the scope of the specification.

    I am interesting in reading on the proposed use of DoH via SVCB. I have two IETF specs to read!
    (link for everyone's reference: )

    Of course we will need to think about relying on DoH,  as it may still have an out-of-band problem for distributing the trusted list of DoH servers...


    Jason Garbis, CISSP
    Co-Chair, Zero Trust Working Group
    CPO, Appgate
    Author: Zero Trust Security: An Enterprise Guide

  • 5.  RE: Is Encrypted Client Hello a challenge for Zero Trust implementation?

    Posted Jan 05, 2023 09:49:00 AM
    Thanks Zied for clarification.

    Yes, encryption and decryption.  That is why I think we need a simplification rethink.  Because of the associated problems of encryption keys being lost, not being rotated (the longer keys stay around the more easily they are poached, particularly with the proliferation of insider threat). Then the requirement to update the algorithms when the current crop get cracked, which they will.  These are today's problems with encryption.  It is not a silver bullet, never has been, and never will be.

    Management of encryption by independent authorities is required.



    Nya Alison Murray
    Trac-Car Technology
    UK +44 208133 9249
    Australia +61 73040 1637
    Switzerland +41 22548 1747

  • 6.  RE: Is Encrypted Client Hello a challenge for Zero Trust implementation?

    Posted Jan 06, 2023 06:20:00 AM
    Hi Zied, 

    You know the proposed ECH is part of TLS at the transport layer ???  And the technologies you mention DNS over HTTPS and SVCB are at the network layer?  And that DoH, and DoT just adding further complexity and vulnerabilities into an already vulnerable TLS protocol?  

    So as a proponent of Zero Trust, I do not see ECH as further securing either network layer security at all.  

    You mentioned that this was to address an SNI clear text problem for network validation.  The network is the primary point of ZT security, and therefore my opinion stands, messing around with further extensions to TLS is just adding an extra layer of potential vulnerability, may break existing network arrangements.

    You cannot consider transport layer security out of context of network layer security in a Zero Trust world, in fact, by rights view the problem in respect to the full stack of infrastructure, network, hosting and application services. 

    I am sure your network people would love a simple fix, but that is the core of the security problem that ZT addresses. Simple fixes do not exist. I would not hold my breath for ECH extension, given the challenges of compatibility with existing TLS 1.2 and 1.3 deployments.   And if you are talking about routing security, DNSSEC is a better bet for validation than edge technologies like Dot and DoH. 



    Nya Murray