TLS 1.3 – BD | Application and Network Security Blog

Thanks to wikileaks, HTTPS Everywhere, and Let’s Encrypt, adoption of encryption (HTTPS) has skyrocketed in the past couple of years. According to the Google Transparency Report, they are seeing as much as 90%+ adoption with traffic headed to google:

While I love my privacy and fully support end to end encryption, encryption, specifically TLS 1.2 (with PFS) and above, straight up blinds me from a packet capture perspective. When a destination website support TLS 1.2 or greater, I am no longer able to record traffic, open wireshark and see what is going on past L4.

Troubleshooting the web in todays world without application layer data (L7) is straight up useless. Wireshark has become a tool to validate connectivity; source/destination port/protocol–lame. If you are a network monkey, I am sure you are thrilled with that level of visibility but trust there is much more going on at L7. Today, most people actually rely on headers captures or Fiddler to see what is going on at L7 but let me tell you, I miss wireshark.

Spoiler alert, you can decrypt TLS with PFS (ECC keys) and it doesn’t require MiTM:

Yup, that’s a pcap opened in wireshark when I logged into the admin portal of this blog. And for what it’s worth, SSL Labs gives this blog an A+ for security so you have piece of mind that my capture wasn’t picking up clear text traffic. Note the form items “log” and “pwd”; that’s the username/password combination I used to log in. But also notice Decrypted TLS (130 bytes) as well 😉

Continue reading Cracking open that TLS connection

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