This is a guest blog post by Erik Hjelmvik, an expert in network forensics and network security monitoring at NETRESEC.
PolarProxy is a transparent TLS proxy that outputs decrypted TLS traffic as PCAP files. PolarProxy doesn’t interfere with the tunnelled data in any way, it simply takes the incoming TLS stream, decrypts it, re-encrypts it and forwards it to the destination. Because of this PolarProxy can be used as a generic TLS decryption proxy for just about any protocol that uses TLS encryption, including HTTPS, HTTP/2, DoH, DoT, FTPS, SMTPS, IMAPS, POP3S and SIP-TLS.
PolarProxy is primarily designed for inspecting otherwise encrypted traffic from malware, such as botnets that use HTTPS for command-and-control of victim PCs. Other popular use cases for PolarProxy is to inspect encrypted traffic from IoT devices and other embedded products or to analyze otherwise encrypted traffic from mobile phones and tablets. The fact that PolarProxy exports the decrypted traffic in a decrypted format without any TLS headers also enables users to inspect the decrypted traffic with products that don’t support TLS decryption, such as intrusion detection and network forensics products like Suricata, Zeek and NetworkMiner.
Continue reading Decrypting TLS Traffic with PolarProxy
Another small post out of my “At a Glance” series: The different types of virtual private networks (VPNs). Looking at Site-to-Site and Remote Access VPNs.
Continue reading Types of VPN
It is quite common that organizations use some kind of TLS decryption to have a look at the client traffic in order to protect against malware or evasion. (Some synonyms are SSL/TLS interception, decryption, visibility, man-in-the-middle, …) Next-generation firewalls as well as proxies implement such techniques, e.g., Palo Alto Networks or Blue Coat. To omit the certificate warnings by the clients, all spoofed certificates are signed by an internal root CA that is known to all internal clients. For example, the root CA is published via group policies to all end nodes.
But what happens if the DNS-based Authentication of Named Entities (DANE) is widely used within browsers? From the CA perspective, the spoofed certificates are valid, but not from the DANE perspective. To my mind we need something like an on-the-fly TLSA record spoofing technique that works in conjunction with TLS decryption.
Continue reading Idea: On-the-Fly TLSA Record Spoofing
DNS-based Authentication of Named Entities (DANE) is a great feature that uses the advantages of a DNSSEC signed zone in order to tell the client which TLS certificate he has to expect when connecting to a secure destination over HTTPS or SMTPS. Via a secure channel (DNSSEC) the client can request the public key of the server. This means, that a Man-in-the-Middle attack (MITM) with a spoofed certificate would be exposed directly, i.e., is not possible anymore. Furthermore, the trust to certificate authorities (CAs) is not needed anymore.
In this blog post I will show how to use DANE and its DNS records within an authoritative DNS server to provide enhanced security features for the public.
Continue reading How to use DANE/TLSA
In the paper of the Logjam attack, a sentence about the F5 load balancers confused me a bit: “The F5 BIG-IP load balancers and hardware TLS frontends will reuse unless the “Single DH” option is checked.” This sounds like “it does NOT use a fresh/ephemeral diffie-hellman key for new connections”. I always believed, that when a cipher suite with EDH/DHE is chosen, the diffie-hellman key exchange always generates a new for computing . Hm.
Therefore, I tested this “Single DH use” option on my lab F5 unit, in order to find out whether the same public key (as noted in Wireshark) is used for more than one session.
Continue reading F5 SSL Profile: “Single DH use” not working?
Another fixed issue in the just released PANOS version 6.1.2 from Palo Alto Networks is bug ID 71321: “Removed support for SSL 3.0 from the GlobalProtect gateway, GlobalProtect portal, and Captive Portal due to CVE-2014-3566 (POODLE).” I scanned my lab unit before (6.1.1) and after the OS upgrade (6.1.2) and here are the results.
Continue reading Palo Alto PANOS 6.1.2: No more SSLv3/POODLE
I was interested to tune my https sites with Apache to support only cipher suites that use the ephemeral Diffie-Hellman key exchange = perfect forward secrecy. But after searching a while through the Internet, only SSLCipherSuite with a few concrete algorithms were presented, while I wanted to use a more generic option such as known from “!MD5”. Here it is:
Continue reading Apache SSL Cipher Suites: Perfect Forward Secrecy
During the last few months, the concept of Perfect Forward Secrecy (PFS) was presented in many newspapers and guidelines. This concept is related to the session key generation for SSL/TLS as well as for IPsec tunnels. And even though many of these articles describe the benefit of PFS, I was still missing a picture that shows the main difference between the classical key exchange via RSA and the exchange via Diffie-Hellman with PFS. So, here comes my poster. ;)
Continue reading At a Glance: Perfect Forward Secrecy (PFS)
Zur Zeit wird viel über Abhörmaßnahmen im Internet und speziell über das generelle Mitschneiden von Traffic normaler User geredet. Und während große Firmen gezielt Verschlüsselungstechniken einsetzen können hat der Otto Normalverbraucher kaum das Wissen, um ernsthaft etwas gegen das Mitschneiden seiner Daten zu tun. Dabei ist es gar nicht so schwer, zumindest die Übertragung der eigenen E-Mails hin zu seinem Provider über entsprechende Maßnahmen abzusichern. Ob man damit die internationalen Geheimdienste aussperrt bleibt fraglich, aber zumindest schränkt man das Mitlesen der privaten E-Mails durch Unbefugte im Internet deutlich ein! Hier kommt also eine Erklärung inkl. einiger Screenshots der gängigen E-Mail Programme und Smartphones, um die eigenen E-Mails über einen verschlüsselten Kanal zu übertragen. Continue reading E-Mail Übertragung verschlüsseln