Så er der DNSSEC på hacking.dk
Så er DNSSEC slået til på mit første domæne. Ja, det har været muligt i et stykke tid, men først nu har jeg haft tid tid at få det hele til at virke. Jeg bruger GratisDNS til mine domæner, så jeg er fri for at fedte med nøgler selv, man trykker bare DNSSEC i kontrolpanelet.
Og det var det? Joo, havde det været et .se domæne så havde GratisDNS kunnet klare resten. Med DK-Hostmaster skal jeg selv have snavsede fingre. Det vil sige at jeg skal slå en række DNSKEY records op på GratisDNS's navneservere, vælge den rigtige nøgle, konvertere den til DS-format og endelig uploade den hos DK-Hostmaster.
UPDATE **(tidligt 5. oktober): **Nu viser GratisDNS alle de nødvendige oplysninger når man trykker 'DNSSEC' ud for domænet i kontrolpanelet, men først når GratisDNS's navneservere er klar. Så med mindre du vil have forklaringen, så spring trykt ned til afsnittet "Så fat dit handle..." Men læs og forstå teksten i kontrolpanelet, support af dnssec er ikke en del af den gratis service. Stor tak til Peter Larsen og hans muntre mænd for en god service.
For at starte i midten, så har jeg fundet et værktøj der konvertere fra DNSKEY-records til DS-records. Som en del af NLnet Labs' ldns-projekt findes værktøjet 'ldns-key2ds' som gør netop dette. Men som en del af samme projekt findes en 'dig' klon 'drill' der automatisk kan oversætte DNSKEY-records til DS-records.
Så, brug 'drill' til at slå DNSKEY records op for mit domæne:
$ drill -s DNSKEY hacking.dk @ns1.gratisdns.dk [...] ;; ANSWER SECTION: hacking.dk. 43200 IN DNSKEY 257 3 5 AwEAAa/WYzGybI3ZaDXVFZfaK/KkGvXLIHtOJj/8A0a0JqeO+3gPT9CZVRoX5Cx27lV1utyMSaQOpfcWtlPXCrZSYLE= ;{id = 44068 (ksk), size = 512b} hacking.dk. 43200 IN DNSKEY 256 3 5 AwEAAcwQic5V2V2NwQPlA4xF65ZdQoXdqavsNmNT65d2Sb6VpEaxEx8SC+89EI/wmqG00gUirPnyeT3gZXpnAAbVBo0= ;{id = 33825 (zsk), size = 512b}
[...]
; hacking.dk. 43200 IN DS 44068 5 1 19b64fa4b782613db8ce639fbe0618f6e1051211 ; xeker-kofop-gotum-demif-tuvis-vymyn-zuzeb-kikoz-kemib-hugoc-cexix ; hacking.dk. 43200 IN DS 33825 5 1 f3f3fd7058087b3462151c8d6c0df87d0b4ba5bd ; xusoz-fizel-bekab-mevyf-gimic-hulum-tureb-tevol-todeg-renar-texex
En DNSKEY record indeholder en række felter: Først en 16bit værdi med flag, så et protokol-felt (der altid skal være 3), så en angivelse af algoritmen (her nummer 1) og endelig selve nøglen. Derudover er drill så venlig at hive et nøgle-id ud og sætte det ind i et kommentar.
Den nøgle vi skal have fat i er den med den mindst-betydende bit sat i flag-feltet (altså hvor værdien er ulige). Det betyder 'Secure Entry Point' og er den nøgle som resten af zonens nøgler er signeret med. I kommentaren kalder drill den også for 'ksk' (Key signing key). Vi er altså interesseret i nøglen med id 44068.
En DS-record indeholder et nøgle-id, algoritmen brugt til selve nøglen (her 5), algoritmen brugt til at generere signaturen (her 1) og endelig selve signaturen. Det er linjen med DS-recorden med for nøgle-id 44068 vi skal have sat ind i DK-Hostmasters zone-fil.
Så fat dit handle og din adgangskode til DK-Hostmasters selvbetjeningssystem og vælg menupunktet 'DNSSEC nøgle(r)'. Har man mange domæner er webgrænseflader besværlige og ifølge DK-Hostmaster skal man være XML-entusiast for at kunne drømme om at bruge standarden som alle moderne registrys bruger. Så heldigvis har DK-Hostmaster udviklet deres egen protokol DSU for HTTP-entusiaster der heller vil parse ikke-standard HTTP-headere.
Der er lidt ventetid her og der i processen. Den kan man passende bruge på at drikke en hel del kaffe og ellers spekulere over hvad man skal bruge DNSSEC til. For det første bør man sætte sin egen resolver op, jeg kan anbefale Unbound, men man skal lige huske at lære den om nøglen rod-zonen er signeret med.
Som min første 'brug' af DNSSEC har jeg lagt ssh host keys op i en SSHFP-record for vps1.hacking.dk. I teorien kan jeg så undgå at skulle huske på den og godkende den når jeg logger på fra en maskine der ikke kender den i forvejen. I virkeligheden kunne jeg ikke få det til at virke på min Debian, men under OpenBSD virker det. (Husk 'VerifyHostkKeyDNS yes' i konfigurationen). Men det ville selvfølgelig være mere interessant hvis jeg havde 200-300 hosts og ingen anden god måde at distribuerer knownhost-filer ud til alle mine brugere.
Der er Google Chrome-udviklere der arbejder på at lægge TLS-certifikater i DNS. På den måde kan jeg helt gratis får en SSL-sikkerhed der svare til de billigste certifikater.
Og eftersom DNSSEC også kan bevise ikke-eksistensen af records, så kan folk nu sikre sig at de får alle mine DNS-records, så hverken A-records eller SPF bliver blokeret. Det vil i hvert fald gøre enhver form for DNS-blokering tydelig og gøre det muligt at rent faktisk stole på at man har alle data til for eksempel spam-filtrering med SPF.
Mulighederne er mange, lad os komme igang!
Om Peter MakholmKommentarer (15)
Det ville være rart hvis GratisDNS's kontrolpanel gav mulighed for at finde den rigtige DS-record let. Jeg har ikke lige kunne finde den funktionalitet.
På den anden side, hvis man indsætter DS-records hos registryet (DK-Hostmaster) inden ens navneservere er opdaterede med DNSKEY records, så holder 'ting' op med at virke.
På langt sigt skal det være meget lettere. Men lige i øjeblikket kan jeg godt acceptere at det primært er for folk der ønsker selv at pille lidt.
-
0 -
0
Jeg hører i mit øre at det er på todo-listen at gøre det lettere. Så kan man reservere afsnittene fra "For at starte i midten" til "Så fat dit handle" for os der gerne vil forstå hvad der foregår.
-
0
-
0
Når jeg kikker lidt på diverse feature requests i Debian BTS, så ser det ud til at burde virke med Squeeze. Men det afhænger af et samspil mellem at man har sat en dnssec-aware resolver op samt de rette versioner af både libc6 og openssh.
Er der nogen der kan få det til at virke?
Hvis man prøver at udføre følgende kommando: 'ssh -v -o VerifyHostKeyDNS=ask -p 443 vps1.hacking.dk' så skal den gerne umidelbart før den spørge om man vil godkende et fingerprint skrive:
debug1: found 1 secure fingerprints in DNS
debug1: matching host key fingerprint found in DNS
(Jeg slår port 443 fra en af dagene, så hvis I slet ikke får kontakt har jeg bare lukket)
-
0
-
0
yep:
....
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5
debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: found 1 insecure fingerprints in DNS
debug1: matching host key fingerprint found in DNS
debug1: checking without port identifier
debug1: checking without port identifier
The authenticity of host '[vps1.hacking.dk]:443 ([109.74.200.101]:443)' can't be established.
RSA key fingerprint is e1:cb:4c:4f:8d:12:49:c2:23:a2:a7:23:9e:c8:f9:3e.
Matching host key fingerprint found in DNS.
(mac os x 10.6)
-
0
-
0
Eske, der står 'found 1 insecure fingerprints in DNS'. Altså har din OpenSSH ikke tillid til at SSHFP-recorden i DNS er sikret med DNSSEC.
-
0
-
0
Samme hos mig, på Debian Unstable/SID:
$ ssh -v -o VerifyHostKeyDNS=ask -p 443 vps1.hacking.dk
OpenSSH_5.5p1 Debian-5, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to vps1.hacking.dk [109.74.200.101] port 443.
debug1: Connection established.
debug1: identity file /home/lab/.ssh/id_rsa type -1
debug1: identity file /home/lab/.ssh/id_rsa-cert type -1
debug1: identity file /home/lab/.ssh/id_dsa type -1
debug1: identity file /home/lab/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5
debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-5
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: found 1 insecure fingerprints in DNS
debug1: matching host key fingerprint found in DNS
debug1: checking without port identifier
The authenticity of host '[vps1.hacking.dk]:443 ([109.74.200.101]:443)' can't be established.
RSA key fingerprint is e1:cb:4c:4f:8d:12:49:c2:23:a2:a7:23:9e:c8:f9:3e.
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[vps1.hacking.dk]:443,[109.74.200.101]:443' (RSA) to the list of known hosts.
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/lab/.ssh/id_rsa
debug1: Trying private key: /home/lab/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey).
-
0
-
0
Min forståelse ang. dit SSHFP problem er at der florer diverse bugbeskrivelser omkring dette.
Problemet, som jeg ser det, bunder i at man på et tidspunkt har "flippet" diverse defaults bits, og uden at følge op på det i de forskellige os'er. Der burde være en patch til feks redhat/fedora (men er pt utestet her).
eksempel:
https://bugzilla.redhat.com/show_bug.cgi?id=205842
Btw:
Husk at google's latterlige informationsindsamlende cachedns service IKKE giver et "ad" (Authenticated Data) svar på flags, dvs:
maria# dig +dnssec +adflag SSHFP vps1.hacking.dk
; <<>> DiG 9.3.3 <<>> +dnssec +adflag SSHFP vps1.hacking.dk
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21137
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;vps1.hacking.dk. IN SSHFP
;; ANSWER SECTION:
vps1.hacking.dk. 42602 IN SSHFP 1 1 C2D62DAF9B546AA6CA442906D26452816D071CFB
vps1.hacking.dk. 42602 IN RRSIG SSHFP 5 3 43200 20101101010804 20101002010804 33825 hacking.dk. sXh3aHqtg8JMO1PQWZPeagN05uNq5/p2QBv/Tq+74/WNMx2yTgRjD8BC 4Cobb5bLsI7o37U1F5X3MS92oV0URg==
;; Query time: 0 msec
;; SERVER: 213.173.243.253#53(213.173.243.253)
;; WHEN: Tue Oct 5 02:49:33 2010
;; MSG SIZE rcvd: 184
.. og her google cachedns version:
maria# dig +dnssec +adflag @8.8.8.8 SSHFP vps1.hacking.dk
; <<>> DiG 9.3.3 <<>> +dnssec +adflag @8.8.8.8 SSHFP vps1.hacking.dk
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21634
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;vps1.hacking.dk. IN SSHFP
;; ANSWER SECTION:
vps1.hacking.dk. 20137 IN SSHFP 1 1 C2D62DAF9B546AA6CA442906D26452816D071CFB
vps1.hacking.dk. 20137 IN RRSIG SSHFP 5 3 43200 20101101010804 20101002010804 33825 hacking.dk. sXh3aHqtg8JMO1PQWZPeagN05uNq5/p2QBv/Tq+74/WNMx2yTgRjD8BC 4Cobb5bLsI7o37U1F5X3MS92oV0URg==
;; Query time: 37 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Oct 5 02:53:53 2010
;; MSG SIZE rcvd: 184
(bemærk forskel i flags)
hvilket er det første kriterie for at SSHFP virker...
In other news:
GratisDNS er opdateret så DNSSEC informationerne der skal bruges til DK-Hostmaster.dk fremgår tydeligt. Go play :)
-
0
-
0
GratisDNS er opdateret så DNSSEC informationerne der skal bruges til DK-Hostmaster.dk fremgår tydeligt. Go play :)
Cool!
-
0
-
0
GratisDNS er opdateret så DNSSEC informationerne der skal bruges til DK-Hostmaster.dk fremgår tydeligt. Go play :)
Fedt, jeg har tilføjet en update oppe i blogindlæget.
God pointe med at man skal tjekke resolveren før man kan forvente at OpenSSH virker. Da jeg prøvede med OpenSSH på hhv. Debian og OpenBSD brugte jeg i begge tilfælde sammen unbound-installation (på Debian).
-
0
-
0
Hvilke data tilføjede du i SSHFP recorden på GratisDNS? Jeg kan ikke umiddelbart få mening i data, Preference 1 og Preference 2 - og får konsekvent at vide af systemet at mine input skal være mellem 0 og 65535, ligegyldigt hvad jeg så indtaster
-
0
-
0
Jeg tror at kontrolpanelet er lidt misvisnede og at de nok bare har klippet lidt template-data ind. SSHFP-recorden er defineret i RFC4255 og har tre felter: Et algoritmenummer (1 for RSA, 2 for DSA), en finger-print type (1 for sha1) og endelig selve finger-printet.
Bemærk at det der står i din known_host fil og i /etc/ssh/ssh_host_{rsa,dsa}_key.pub er hele nøglen base64-kodet. Det vil sige at først skal de base64-dekode hvad der står i den rette fil og dernæst skal du tage en sha1-sum og udskrive den som hex-tal.
Jeg har brugte scriptet fra 'sshfp' pakken (http://www.xelerance.com/software/sshfp/) men har lige testeet efter i hånden.
-
0
-
0
Havde fundet de rette værdier at bruge, jeg havde bare ikke fundet den rette kombination til formen ... hvilket er:
Data: SHA1 hash
Preference 1: algoritme
Preference 2: fingerprint type
Udmærket tip ang. script
-
0
-
0
For en uges tid siden skrev jeg et script der kunne hente en DNSKEY record via dns op uploade den modsvarende DS record til DK-Hostmaster gennem deres egen DSU-protokol.
Desvære var der lige nogle problemer i DK-Hostmasters ende, så det var først i går jeg så at det rent faktisk virkede. Det er et ret simpelt perl-script og kan findes på github:
Der er nogle småproblemer, som jeg læser specifikationen bør DSU automatisk slette alle eksisterende nøgler når man uploader et nyt sæt. Istedet får jeg bare en unique constraint error ved gentagelser og nye nøgler bliver bare tilføjet de gamle.
Jeg må tilstå at det nok gik hurtigere med DSU end hvis jeg lige skulle have haft et passende overfladisk kendskab til EPP. Men hvis jeg skulle understøtte en tre-fire registrys, så ville jeg nok stærkt foretrække end standardiseret løsning - og den hedder vist nu engang EPP og er nu engang (desvære) baseret på XML.
-
0
-
0
Der er Google Chrome-udviklere der arbejder på at lægge TLS-certifikater i DNS. På den måde kan jeg helt gratis får en SSL-sikkerhed der svare til de billigste certifikater.
De billigste certifikater er gratis: http://www.startssl.com/
-
0
-
0
