John Lampe’s Post

The ECH (Encrypted Client Hello) protocol feature explicitly and deliberately and unapologetically disintermediates edge network operators. This includes enterprise policy checking and enforcement, family filtering, even my laptop's apps and virtual machines. The driving market force is device makers, browser makers, CDNs, and content farms who do not want their traffic to be inspectable. Their concern as described in RFC 7258 is inappropriate agency-in-the-middle attacks. My concern is that the Internet was once a network of networks, where each network was autonomous and sovereign. In the post-Snowden world, the Internet as described in RFC 8890 is a viral entity to which edge networks either connect unquestionably and fully, or not at all.

Web access changes due to the rollout of ECH in TLS. Cloudflare begins to roll this out gradually. Your organisation may see impacts soon, such as decreased visibility in your IDS or IPS system. This ECH rollout changes the landscape for enterprise security. Cloudflare positions themselves:                                                   1) They have visibility into DNS queries through their DOH service. 2) They maintain visibility with their share of internet traffic. 3) Cloudflare Gateway users avoid issues with ECH SNI changes.          This move forces organisations to lose visibility or adopt Cloudflare Gateway. It creates questions about advantage and market position. Organisations not using Cloudflare's services will likely face challenges in maintaining visibility for security operations. We need discussions about balancing privacy with organisational security needs and ensuring industry competition. To learn about expectations and options, see this blog for enterprises: https://lnkd.in/egj6cs5S How do we navigate this change? How do we ensure privacy and security yet let organisations control their own data?

Web access is evolving 👀 .

Let me add to this...Encrypted Client Hello is something that should get every cyber security professional to sit up and take notice. Check out this white paper on ECH to understand why it is so important - https://lnkd.in/g3wHgQKF.

This is an interesting read to say the least. This will also effect any packet analysis one might need to do.

Spot on that ECH is disabled generally in the enterprise. We wrote about CLI and container-based methods to turn it off for Chrome here: https://lnkd.in/ewGsKbfg

The rollout of ECH does not impact JA4. Despite the name "Encrypted Client Hello" the initial client hello is not encrypted. What ECH does is send 2 client hellos, one in the clear with a generic SNI (cloudflare-ech.com) and another post encryption with the true SNI. ECH is intended to hide the true destination domain from anyone listening. Though, this does not apply to enterprises as all managed browsers have ECH disabled by default. So your enterprise NDR tools remain unaffected. Outside of the enterprise, privacy conscious users have been using VPNs which already hide the true destination so this mainly impacts ISPs collecting traffic statistics. I'm sure ECH was created to increase online privacy but it also happens to give Google an overnight monopoly on the ability to sell your browsing data 🤔

Web access is changing due to the rollout of a feature in TLS called ECH that was delayed during the initial attempt. Cloudflare has announced that they are beginning to roll this out gradually now. Your organization may begin to see the impacts soon, such as decreased visibility in your IDS or IPS system. To learn more on what to expect and your options, see the following blog that may be helpful for the enterprise: https://lnkd.in/egj6cs5S

Kathleen Moriarty thank you for bringing attention to this critical development and rollout of #ECH and how it will impact #network level visibility. More people need to realize their expensive Next-Gen #Firewall will quickly become just a latency router. Whether you are for or against ECH, one thing is certain, the industry has been overly reliant on network level #inspection for far too long. Further, the proponents of ECH wrongfully assume that end point level inspection and control is always possible. There needs to be balance. It feels like the philosophy of privacy at any cost and deploy #AI as quickly as possible are two paths that lead to a potentially scary outcome for end users and businesses everywhere and really quickly. There does not seem to be sufficient oversight and regulation about these new technologies. The fact that a small number of people (4-6) from two browser companies and one CDN can make a decision to upend the entire market is a problem. Whether it is at the #ITU, the #IETF, or OASIS or any of the other tier one SDOs or SSOs, the industry needs to wake up and get back involved in #standardization. No longer can you just sit back and absorb the outcomes. Companies also need to quit judging standards activity like sales and marketing activity. This needs to be a strategic and LONG term commitment. Otherwise you have to live with things that are terrible ideas or ones that are very problematic for your business.

Interesting article and worthy of review by all SASE proponents. My reactions to some of the key points. 1. Agree that Secure Web Gateways can’t handle everything but no one technique can. Defense in depth is always the answer. Thus a. Absolutely you need full end point protection on managed devices. b. Most SWG’s also support clientless access, which implies much less end point management, and needs to be thought through 2. Which is why “managed browsers” are the next big thing from both a strategic and marketing hype perspective. They will both utilize and augment the control of the SWG/SASE and help with the complexity of modern web assembly attacks 3. Interesting point about channels/protocols that often do not get decrypted or inspected (WebRTC, etc). This is because of most security teams perspective on the level of threat within those protocols versus the perceived risk of inserting latency via inspection. If the consensus about risks about tjhese channels increases, they will get inspected.