TLS 1.3 is coming in hot

Editor Note:
In December 2021, Zscaler rolled out full inspection of TLS 1.3 across all clouds. This was done transparently to all users and was enabled by default. We are talking 10 of millions of users and a cloud moving 2+ tbps with zero support tickets opened. That’s just how they do it over there; inspect all traffic, stop the bad guys, and look good doing it.

TLS 1.3 was finalized in April of 2018 with the promises of privacy, security, and performance and unlike its predecessors, adoption of this protocol might be coming in sooner than you think. In a post on reddit, PAN indicates that Google Chrome will be implementing a strict TLS 1.3 in January of 2019:

…using web browsers that implement strict TLS 1.3 compliance. We have been informed that Google Chrome is planning to implement strict TLS 1.3 compliance in their upcoming version 72. The stable build of Google Chrome version 72 may be available in January 2019

I have poked around looking for actual documentation from google, specifically around the wording “strict TLS 1.3 compliance” on the interwebs and haven’t found anything. Why? There is a key difference between supporting TLS 1.3 and going strict TLS 1.3. The former means the client can still negotiate the connection and most likely if the client doesn’t support TLS 1.3, the connection will be downgraded to TLS 1.2. The latter indicates that Chrome and Google based applications, such as gmail, will only work over TLS 1.3. The closest documentation that I was able to find that supports PANs claim was on The Chromium Project. The article makes no mention of strict TLS 1.3 or timelines but does mention this:

Gmail fails to load with ERR_SSL_VERSION_INTERFERENCE or ERR_TLS13_DOWNGRADE_DETECTED.

Certainly seems like strict TLS 1.3 to me.

In either case, what does that mean to you? Just like your facebook relationship status, it’s complicated. If you are a Cisco or Palo Alto Networks customer, it appears that you need to upgrade:

Continue reading TLS 1.3 is coming in hot

Executing Security at Scale

Raise your hand if you’re using any or all of these technologies:

  • NGFW
  • IPS/IDS
  • URL Filter
  • Antivirus
  • DLP
  • Sandbox
  • VPN
  • DDoS Mitigation

Pretty much all of us, right? Now raise your hand if you are decrypting SSL/TLS outbound.

While HTTP/2 doesn’t require SSL/TLS, it will use it by default if it is available. Oh by the way, all modern browsers have supported HTTP/2 since January of 2016. Factor in the efforts of Let’s Encrypt, the adoption of SSL/TLS has skyrocketed in the past few years and will continue to grow. Hell, even this shitty blog is using TLS 🙂 If you aren’t decrypting SSL/TLS you have to ask yourself, what good is my NGFW, IPS, Antivirus, etc if I am completely blind to it? The answer is simple, it isn’t good, in fact it’s terrible. You are bound by the constraints of legacy security, source/destination and ports. It’s like locking a screen door. It will keep the flies out but it won’t stop any real threats.

Continue reading Executing Security at Scale