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?
Similar to my test with Diffie-Hellman group 14 shown here I tested a VPN connection with the elliptic curve Diffie-Hellman groups 19 and 20. The considerations why to use these DH groups are listed in the just mentioned post – mainly because of the higher security level they offer. I tested the site-to-site IPsec connections with a Juniper ScreenOS firewall and a Fortinet FortiGate firewall. (Currently, neither the Palo Alto nor the Cisco ASA support these groups.)
Continue reading Site-to-Site VPNs with Diffie-Hellman Groups 19 & 20 (Elliptic Curve)
In den Release Notes der neuesten AVM FRITZ!Box Version FRITZ!OS 06.20 stand unter anderem: “VPN-Verbindungen unterstützen jetzt zusätzliche Diffie-Hellman-Gruppen 5, 14 und 15”. Coole Sache, ist doch die Sicherheit bei der Perfect Forward Secrecy mit DH-14 deutlich höher und der heutigen Zeit angemessen. Also habe ich das bei einem meiner VPNs direkt mal eingerichtet und entsprechend getestet. Leider hat sich aber mit der neuen Version die Kompatibilität zu diversen Firewalls/VPN-Gateways deutlich verschlechtert. Es ist also nicht nur Gewinn, die Version 06.20 am laufen zu haben.
Continue reading FRITZ!OS ab 06.20: Änderungen bei VPNs
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
When talking about VPNs it is almost always clear that they are encrypted. However, it is not so clear on which security level a VPN is established. Since the Perfect Forward Secrecy (PFS) values of “DH group 5” etc. do not clearly specify the “bits of security”, it is a misleadingly assumption that the security is 256 bits due to the symmetric AES-256 cipher. It is not! Diffie-Hellman group 5 has only about 89 bits of security…
Therefore, common firewalls implement DH group 14 which has a least a security level of approximately 103 bits. I tested such a site-to-site VPN tunnel between a Palo Alto and a Juniper ScreenOS firewall which worked without any problems.
Continue reading Site-to-Site VPNs with Diffie-Hellman Group 14
During the last few months the concept of Perfect Forward Secrecy (PFS) was presented on 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)