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
We needed to configure the Internet-facing firewall for a customer to block encrypted files such as protected PDF, ZIP, or Microsoft Office documents. We tested it with two next-generation firewalls, namely Fortinet FortiGate and Palo Alto Networks. The experiences were quite different…
TL;DR: While Fortinet is able to block encrypted files, Palo Alto fails since it does not identify encrypted office documents! [UPDATE: Palo Alto has fixed the main problem, see notes below.]
Continue reading File Blocking Shootout – Palo Alto vs. Fortinet
I came across some strange behaviors on a Palo Alto Networks firewall: Certain TLS connections with TLS inspection enabled did not work. Looking at the traffic log the connections revealed an Action of “allow” but of Type “deny” with Session End Reason of “policy-deny”. What?
Continue reading Palo Alto policy-deny though Action allow
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
Implementing DNSSEC for a couple of years now while playing with many different DNS options such as TTL values, I came around an error message from DNSViz pointing to possible problems when the TTL of a signed resource record is longer than the lifetime of the DNSSEC signature itself. Since I was not fully aware of this (and because I did not run into a real error over the last years) I wanted to test it more precisely.
Continue reading Signed DNS Zone with too long-living TTLs
In my last blogpost I showed how to perform a DNSSEC KSK rollover. I did it quite slowly and carefully. This time I am looking into an emergency rollover of the KSK. That is: What to do if your KSK is compromised and you must replace it IMMEDIATELY.
I am listing the procedures and commands I used to replace the KSK of my delegated subdomain
dyn.weberdns.de with BIND. And as you might already suggest it, I am showing DNSViz graphs after every step since it greatly reveals the current DNSKEYs etc.
Continue reading DNSSEC KSK Emergency Rollover
Probably the most crucial part in a DNSSEC environment is the maintenance of the key-signing key, the KSK. You should rollover this key on a regular basis, though not that often as the zone signing keys, the ZSKs. I am doing a KSK rollover every 2 years.
In the following I will describe the two existing methods for a KSK rollover along with a step-by-step guide how I performed such a rollover for my zone “weberdns.de”. Of course again with many graphics from DNSViz (with “redundant edges”) that easily reveal the keys and signatures at a glance.
Note that this blogpost is NOT about the Root Zone KSK Rollover that appears in 2017/2018. It is merely about your OWN zone that is secured via DNSSEC.
Continue reading DNSSEC KSK Key Rollover
Until now I generated all SSHFP resource records on the SSH destination server itself via
ssh-keygen -r <name>. This is quite easy when you already have an SSH connection to a standard Linux system. But when connecting to third party products such as routers, firewalls, whatever appliances, you don’t have this option. Hence I searched and found a way to generate SSHFP resource records remotely. Here we go:
Continue reading Generating SSHFP Records Remotely
This is actually a bad user experience problem: To generally omit the manual verification of SSH key fingerprints I am using SSHFP. With fully qualified domain names (FQDN) as the hostname for SSH connections such as
ssh nb10.weberlab.de this works perfectly. However, admins are lazy and only use the hostname without the domain suffix to connect to their servers since the domain search does the rest:
ssh nb10. Not so for SSHFP which fails since the default OpenSSH client does not use canonicalization for its DNS queries. Hence you must explicitly enable canonicalization for OpenSSH.
Continue reading SSHFP: FQDN vs. Domain Search/DNS-Suffix
I am intensely using the SSH Public Key Fingerprint (SSHFP, RFC 4255) in all of my environments. Since my zones are secured via DNSSEC I got rid of any “authenticity of host ‘xyz’ can’t be established” problems. As long as I am using my central jump host with OpenSSH and the “VerifyHostKeyDNS yes” option I can securely login into any of my servers without any warnings. Great!
However, I encountered a couple of daily problems when using SSHFP. One of them was the question whether SSHFP works behind CNAMEs, that is, when connecting to an alias. Short answer: yes. Some more details here:
Continue reading SSHFP behind CNAME
What is the biggest problem of PGP? The key distribution. This is well-known and not new at all. What is new is the OPENPGPKEY DNS resource record that delivers PGP public keys for mail addresses. If signed and verified with DNSSEC a mail sender can get the correct public key for his recipient. This solves both key distribution problems: 1) the delivery of the public key and 2) the authenticity of the key itself, i.e., that you’re using the correct key to encrypt a mail.
The “DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP” is specified in the experimental RFC 7929. Let’s have a look on how you can add your public key into the zone file of your DNS server.
Continue reading PGP Key Distribution via DNSSEC: OPENPGPKEY
I really like the kind of security features that are easy to use. The CAA “DNS Certification Authority Authorization” is one of those, specified in RFC 6844. As a domain administrator you must only generate the appropriate CAA records and you’re done. (Unlike other security features such as HPKP that requires deep and careful planning or DANE which is not used widely.) Since the check of CAA records is mandatory for CAs since 8. September 2017, the usage of those records is quite useful because it adds another layer of security.
Continue reading CAA: DNS Certification Authority Authorization
It is probably one of the most used protocols in my daily business but I have never captured it in detail: IKE and IPsec/ESP. And since IKEv2 is coming I gave it a try and tcpdumped two VPN session initiations with IKEv1 main mode as well as with IKEv2 to see some basic differences.
Of course I know that all VPN protocols are encrypted – hence you won’t see that much data. But at least you can see the basic message flow such as “only 4 messages with IKEv2” while some more for legacy IKEv1. I won’t go into the protocol details at all. I am merely publishing two pcap files so that anyone can have a look at a VPN session initiation. A few Wireshark screenshots complete the blogpost.
Continue reading IKEv1 & IKEv2 Capture