Tag: TLS

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

Caught on tape: Malware Distribution Techniques

If you haven’t already done so, you should read the Verizon Data Breach Investigations Report that they publish annually. In the 2018 Verizon DBIR, it is chock-full of good reading around the specifics of breaches in 2017 and provides an insight to the Who, How, Why, What, and When. In the report you can read about the internal threat actors down to how malware was distributed. In all, Verizon has dotted all the I’s and crossed all of the T’s and provided you visibility into 53,000 incidents and 2,216 confirmed breaches across all verticals in 2017. Historically I have used these reports to help educate myself and my customers on the threat landscape as well as leverage the information to help justify spend on security related products, tools, or services to help keep the enterprise safe.

While reading the report, the sections regarding malware (ransomware included) stood out to me. Why? Well come on, you would think by 2017 will all of the security tools deployed that malware, even 0-day, wouldn’t be an issue but it still is. On pages 17/18, the report discusses the frequency of malware vectors, or basically how malware is distributed.

Continue reading Caught on tape: Malware Distribution Techniques

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