SSHFP biedt structurele oplossing voor 'key distribution'-probleem van SSH
Cryptografische verankering middels DNSSEC
Gebruik je SSH dan ben je zeker bekend met het 'key distribution'-probleem voor de SSH-server: de eerste keer dat je verbinding zoekt met een server vraagt de client je om de fingerprint van de publieke sleutel van de betreffende server te bevestigen. Hoewel de meesten gewoon door zullen klikken, zou je om man-in-the-middle (MITM)-aanvallen te voorkomen deze fingerprint moeten vergelijken met de publieke sleutel op de betreffende server.
SSHFP is een beveiligingsstandaard die voortbouwt op DNSSEC en een structurele oplossing biedt voor dit probleem. Daartoe wordt de fingerprint opgenomen in het DNS-systeem en (digitaal ondertekend met behulp van DNSSEC) voor clients beschikbaar gemaakt.
Publieke sleutels
Het SSH-protocol werkt op basis van asymmetrische cryptografie. Het voordeel daarvan ten opzichte van symmetrische cryptografie is dat je niet tevoren een geheime sleutel tussen de twee betrokken partijen hoeft uit te wisselen. Het nadeel is dat de publieke sleutels wel gepubliceerd moeten worden op een alom bekend en vertrouwd ("well-known") online medium. Voor de versleuteling van e-mail maken we bijvoorbeeld gebruik van een aantal bekende OpenPGP Key Servers. Voor SSH bestaan dergelijke key servers echter niet. In plaats daarvan toont de client een fingerprint (een digitale samenvatting) van de publieke sleutel die de SSH-server aanbiedt, met de vraag daarbij of je die wilt bevestigen. Doe je dat inderdaad, dan wordt deze publieke sleutel door de client opgeslagen (in de file '~/.ssh/known_hosts'). De volgende keer dat je je bij de betreffende server aanmeldt weet de client welke publieke sleutel de server aan zou moeten bieden en ga je in één keer door naar de authenticatie.
Het SSHFP-record
SSHFP lost dit 'key distribution'-probleem op door de fingerprint van de publieke sleutel van de SSH-server in het DNS-systeem te publiceren. Daarvoor is in RFC 4255 het speciale SSHFP-record gedefinieerd. Een dergelijk record genereer je met de de 'ssh-keyscan -D'-opdracht. Maar let op dat je dit commando strikt genomen alleen op de server zelf mag uitvoeren om een MITM-aanval te voorkomen.
[user@server ~]$ ssh-keyscan -D example.nl. ; example.nl.:22 SSH-2.0-OpenSSH_8.0 example.nl. IN SSHFP 1 1 827381207b4e350996d2f0b32fabc1da72d7c870 example.nl. IN SSHFP 1 2 9b382aef6550da23e4844ca60f0c5efd206a868aa914ecb71ba95f5c9257f6aa ; example.nl.:22 SSH-2.0-OpenSSH_8.0 example.nl. IN SSHFP 3 1 9d6554b55f82de976d7f94282441771abcc110d4 example.nl. IN SSHFP 3 2 87bc585d085c05507780c13b066c0b7d42fde5ec1e9d72ffde91a89c892f9a3d ; example.nl.:22 SSH-2.0-OpenSSH_8.0 example.nl. IN SSHFP 4 1 5c87b3e44c9c857d25b4c01b3232868f71b2697b example.nl. IN SSHFP 4 2 4f6f2d6c8fbc1aa3da30ea8fe325e69c9e93e8b175f1ffba577602ccdf8eac94
Wat je hier terugkrijgt zijn maar liefst zes SSHFP-records: twee verschillende fingerprints (gebaseerd op de SHA-256 en SHA-1 hashes) voor drie verschillende cryptografische algoritmen (RSA, ECDSA en Ed25519). Voor de details van het SSHFP-record verwijzen we je naar RFC 4255. De RFC's 6594 en 7479 bevatten aanvullingen voor het gebruik van respectievelijk SHA-256 en Ed25519. De door IANA toegekende parameterwaarden voor de cryptografische algoritmen vind je hier. Let op dat oudere versies van ssh-keyscan de '-D'-optie nog niet ondersteunen. In die gevallen kun je de opdracht 'ssh-keygen -r example.nl' gebruiken. Weet daarbij dat ssh-keygen geen netwerkverbinding opzet maar alleen de locale sleutelbestanden in de directory /etc/ssh/ uitleest. De hostname wordt hier alleen gebruikt om de SSHFP-records te genereren. En merk op dat de SSHFP-records niet per poort/service maar per hostname zijn gedefinieerd. Dat betekent dat alle SSHFP-records voor een host in een en dezelfde resource record set (RRset) terecht komen, ongeacht het gebruikte poortnummer.
Validatie
Neem je bovenstaande records op in de zone, en voeg je de instelling 'VerifyHostKeyDNS yes' toe aan de SSH-client configuratie (in de directory '/etc/ssh/' of '~/.ssh/config'"), dan valideert de client bij het verbinden met de SSH-server de fingerprint. Dat gebeurt door de fingerprint van de publieke sleutel, zoals die aangeboden wordt door de server, te vergelijken met de fingerprint die in de DNS wordt gepubliceerd. Komen die twee fingerprints overeen, dan gaat de client gelijk door naar de authenticatie. Is er geen match, dan valt de client terug naar de traditionele, handmatige bevestiging:
[user@client ~]$ ssh example.nl The authenticity of host 'example.nl (192.0.2.162)' can't be established. ED25519 key fingerprint is SHA256:T29tbI+6HqPaMOqP1yG2nJ6T6LF48f+6V3YDvN+OvJQ. No matching host key fingerprint found in DNS. This key is not known by any other names Are you sure you want to continue connecting (yes/no/[fingerprint])?
Overigens hoefden we op ons Fedora (versie 34) Linux-systeem de 'VerifyHostKeyDNS'-optie niet aan te zetten. Deze werd al geïnstalleerd (in de file '/etc/ssh/ssh_config.d/10-dnssec-trigger.conf') als onderdeel van DNSSEC-Trigger. De populaire terminal emulator PuTTY ondersteunt SSHFP-validatie niet. OpenSSH op MacOS kan in eerste instantie problemen opleveren, maar werkt dan wel als je via Homebrew een versie van OpenSSH installeert. Het lijkt erop dat Apple zelf een compilatie-optie vergeten is, maar als iemand meer informatie heeft over de oorzaak/reikwijdte van dit probleem dan horen we dat graag.
Cryptografische verankering
SSHFP is een voorbeeld van een nieuwe beveiligingstoepassing mogelijk gemaakt door DNSSEC. Door de fingerprint in het DNSSEC-beveiligde DNS-systeem op te nemen wordt deze cryptografisch verankerd, waarmee het 'key distribution'-probleem voor de SSH-server structureel opgelost is. Alles over het opzetten van DNSSEC – voorwaarde voor de toepassing van SSHFP – vind je op deze overzichtspagina. In ons maturitymodel voor moderne internetstandaarden hebben we SSHFP onder de kop 'state-of-the-art' geschaard. Tegelijkertijd is de implementatie ervan zo eenvoudig, dat we iedereen die DNSSEC heeft geïmplementeerd toch willen aanraden om die records gelijk aan zijn DNS toe te voegen.
