It is widely believed that public/private keys or certificates are “more secure” than passwords. E.g., an SSH login via key rather than using a password. Or a site-to-site VPN with certificate authentication rather than a pre-shared key (PSK). However, even certificates and private keys are not unlimited secure. They can be compromised, too, since the public-key cryptography only implies that private keys won’t be exposed if a brute-force attack is nearly impossible.
So, what’s the real security level of passwords compared to public keys/certificates?
Continue reading Passwords vs. Private Keys
In my previous blogpost I talked about the true random number generator (TRNG) within the Raspberry Pi. Now I am using it for a small online pre-shared key (PSK) generator at https://random.weberlab.de (IPv6-only) that you can use e.g. for site-to-site VPNs. Here are some details how I am reading the binary random data and how I built this small website.
Continue reading True Random PSK Generator on a Raspi
Unpredictable random numbers are mandatory for cryptographic operations in many cases (ref). There are cryptographically secure pseudorandom number generators (CSPRNG) but the usage of a hardware random number generator (TRNG) is something I am especially interested in since many years. While there are many proprietary TRNGs (list) with different prices, I had a look at two cheap solutions: the Raspberry Pi’s hardware random number generator as well as an application that uses a DVB-T/RTL/SDR stick for gathering some noise.
I have tested both of them with various options and ran them against the dieharder test suite. In this post I am listing the CLI commands to get the random data from those source and I am listing the results of the tests.
Continue reading Playing with Randomness
Beside using FortiGate firewalls for network security and VPNs you can configure them to mine bitcoins within a hidden configure section. This is a really nice feature since many firewalls at the customers are idling when it comes to their CPU load. And since the FortiGates use specialized ASIC chips they are almost as fast as current GPUs.
If you have not yet used those hidden commands, here we go:
Continue reading Using a FortiGate for Bitcoin Mining
To solve the chicken-or-egg problem for DNSSEC from the other side, let’s use an authoritative DNS server (BIND) for signing DNS zones. This tutorial describes how to generate the keys and configure the “Berkeley Internet Name Domain” (BIND) server in order to automatically sign zones. I am not explaining many details of DNSSEC at all, but only the configuration and verification steps for a concrete BIND server.
It is really easy to tell BIND to do the inline signing. With this option enabled, the admin can still configure the static database for his zone files without any relation to DNSSEC. Everything with signing and maintaining is fully done by BIND without any user interaction. Great.
Continue reading DNSSEC Signing w/ BIND
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 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 Palo Alto Networks nor Cisco ASA support these groups.)
Continue reading Site-to-Site VPNs with Diffie-Hellman Groups 19 & 20 (Elliptic Curve)
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
Pre-shared keys (PSK) are the most common authentication method for site-to-site IPsec VPN tunnels. So what’s to say about the security of PSKs? What is its role for the network security? How complex should PSKs be? Should they be stored additionally? What happens if an attacker catches my PSKs?
I am listing my best practice steps for generating PSKs.
Continue reading Considerations about IPsec Pre-Shared Keys
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)