BD | Application and Network Security Blog – Page 2

Cracking open that TLS connection

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

DNS Flag Day: Are you ready?

You might asking yourself, what the heck is DNS Flag Day anyways? Before you go Google it yourself, let me break it down for you. On or around February 1st, 2019 major DNS service providers are going to start enforcing EDNS. Which DNS service providers you ask?

…and what is EDNS? Extension Mechanisms for DNS (EDNS aka EDNS0) essentially allows for larger packet sizes, 512 bytes being this traditional size for DNS. By increasing it to 4096*, EDNS allows for the ability to inject client IP information which is ideal for CDNs (cough cough CloudFlare) or to support DNSSEC. DNSSEC (Domain Name System Security Extension) was designed to protect applications (and caching resolvers serving those applications) from using forged or manipulated DNS data, such as that created by DNS cache poisoning.

*Size matters in this case.
Many NGFWs may block traffic as they are expecting the packet to be 512 bytes and may drop. You may need to add an additional firewall rule to permit DNS packet that are =< 4096 bytes.

Sadly this spec has been around since 1999, so now the giants have drawn the line in the sand, support it as of 02/01/2019 or not, we don’t care. If you don’t, this is how it will look for your customer, users, and/or contractors that rely on 3rd party DNS services:

I think we can all agree that doing this on a Friday is a terrible idea. Want to piss off people who work in IT? Don’t socialize a change that could impact many people and make sure that the people who can troubleshoot it and fix it, work through the weekend. They love that kinda stuff. About as much as they like when their puppy eats a shoe lace and they have to pull it out of their butthole.

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