-=Kernel-Error=-

Datenhaufen zu IT und Elektronik.

Schlagwort: DNSSEC (Seite 1 von 2)

S/MIME-Zertifikat per DNS veröffentlichen – SMIMEA

14. März 2025 / / Ein Kommentar
smimea S/MIME Blog Image

Mal wieder soweit: Mein aktuelles S/MIME-Zertifikat zum Signieren von E-Mails läuft aus. Also habe ich mir ein neues besorgt. Da GlobalSign keine Class-2-Zertifikate mehr für Privatpersonen anbietet, musste ich die CA wechseln. Durch Zufall bin ich auf SSLplus gestoßen – die haben echt gute Angebote für alle möglichen Zertifikate. Aber darum soll es in diesem Beitrag nicht gehen.

Wie immer will ich mein Zertifikat öffentlich zugänglich machen, sonst müsste jeder erst eine von mir signierte E-Mail erhalten, bevor er mein Zertifikat hat. Erst dann könnten Absender mir verschlüsselte E-Mails schicken.

Dafür gibt es ein experimentelles RFC 8162, das beschreibt, wie sich ein solches Zertifikat in einer DNSSEC-geschützten Zone veröffentlichen lässt. Natürlich gibt es im Internet wieder zig verschiedene Anleitungen und Wege, um das zu realisieren. Aber nichts wirklich Zuverlässiges, was ich finden konnte. Den DNS-Record für meine Bind9-Zone wieder manuell zu erstellen, hatte ich jedenfalls keine Lust.

Also habe ich zwei kleine Python3-Skripte geschrieben:

smimea_generate_record.py – Erstellt einen kopierbaren RR für die DNS-Zone. Kann interaktiv genutzt werden: Fragt nach E-Mail-Adresse und PEM-Zertifikat. Oder direkt mit Parametern aufgerufen werden. Prüft, ob E-Mail-Adresse und Zertifikat zusammenpassen, und gibt den fertigen Record aus.

./smimea_generate_record.py
Enter the email address: kernel-error@kernel-error.com
Enter the path to the PEM certificate: mail.pem
✅ Email 'kernel-error@kernel-error.com' matches the certificate!

🔹 **Generated BIND9 DNS Record:**

70e1c7d87e825b3aba45e2a478025ea0d91d298038436abde5a4c2d0._smimecert.kernel-error.com. 3600 IN SMIMEA 3 0 0 (
   30820714308204FCA003020102021073C13C478DA7B114B871F00737F1B0FB30
   0D06092A864886F70D01010B0500304E310B300906035504061302504C312130
   1F060355040A0C1841737365636F20446174612053797374656D7320532E412E
   311C301A06035504030C1343657274756D20534D494D4520525341204341301E
   170D3235303331333133343135355A170D3237303331333133343135345A3078
   3114301206035504040C0B76616E206465204D65657231123010060355042A0C
   0953656261737469616E311E301C06035504030C1553656261737469616E2076
   616E206465204D656572312C302A06092A864886F70D010901161D6B65726E65
   6C2D6572726F72406B65726E656C2D6572726F722E636F6D30820222300D0609
   2A864886F70D01010105000382020F003082020A0282020100D0A90BC53ABA04
   08543FE600F0F71C17BE7EB4A8996A8EF5E9122AAC8E7F39D627186617C4D6CA
   734E1A9E6302F8076065EA93D762542D2C12BFF32D5D4942B9A8AA84E2E63CE9
   B843C1665C014A6572A42E376ED0629694FCC942FE53D76052A40CDAB1257A1D
   501D9C65DE18F27C5490A24181498A202E56F4DC0FDCBFE94766F96EBF47C872
   3744ABD69DC684417106DF3D4F12FD52A13B786490366DBF6CB5A843621CD686
   B06D072FD7D486BD0AC706021D137A365718DCD8709D55B64428F8DB56B268BD
   BED463A25231B40566C041A48958BE1767E27E21881D2109935C02F27EA306B6
   4997683EEFDF8685F4F090AB09692F232CD34AC7FF2296768CED62C68C37B4C3
   DD9F04EC9F5C9BB9F712A5032AC2F83D68DA756E4F2886A6F65889CFAEA0C15E
   3624EA3D9E3EFF91D68606F7B7B1B7120035AD4F71369E6D79977B4B2CC3575A
   C51CAF419E795B78822DD36B6D0B0E4622BCE55F7B27FCB52FDCD6A4FBD33EF0
   9F897CADA2E793D1509DE54773B3FBE9091CEA2E27A41CBA38A08BBBE1B15BF5
   6EB35B21D66F5B1B1CC6FDD6362AA88A4010F3D2732F071A841BC765D6F74C3B
   430D036A327918D08156BA2882D78113DD15633599319F4BD5D4F12E1F0102BA
   33766ADF09DC58323246D20BAC815BE5B8822C260EFBB07ADBAB98FA42F31650
   FEFAE5D679D4AD29992F199D59F38D54988D77B61E740CBF470203010001A382
   01C2308201BE300C0603551D130101FF0402300030410603551D1F043A303830
   36A034A0328630687474703A2F2F63736D696D6572736163612E63726C2E6365
   7274756D2E706C2F63736D696D6572736163612E63726C30818306082B060105
   0507010104773075302E06082B060105050730018622687474703A2F2F63736D
   696D6572736163612E6F6373702D63657274756D2E636F6D304306082B060105
   050730028637687474703A2F2F63736D696D6572736163612E7265706F736974
   6F72792E63657274756D2E706C2F63736D696D6572736163612E636572301F06
   03551D2304183016801466FBC30FBEF4BFE09CC9AB4DDE4719BDC0CAA668301D
   0603551D0E041604148D8C102E11D87004F7DDB4E04FF01781888A32A0304C06
   03551D20044530433009060767810C010504023036060B2A84680186F6770264
   01013027302506082B06010505070201161968747470733A2F2F7777772E6365
   7274756D2E706C2F435053301D0603551D250416301406082B06010505070304
   06082B06010505070302300E0603551D0F0101FF0404030204F030280603551D
   110421301F811D6B65726E656C2D6572726F72406B65726E656C2D6572726F72
   2E636F6D300D06092A864886F70D01010B0500038202010070724799F05CF4C8
   21854F43BD950BB608B989046349214F9D0EEC79F73A59DBF4063608FE5A7A7F
   A50CD46A15486018EB9C334418084D8F97FE32EA21CCBAFE902BF6472DB6CA60
   D79EBE09919AFA0652D92CB13B506400BAF4774F3263967A49548A6F723ADCBB
   715AF79705099E5EC84E283DAFA3465908F4148C2B153C41D051C94295D4F042
   54217D1C8E48DF59D92ECBCB4A872EC728A954DAF7B661DE8037F7F103393612
   14163901ACFE98F3D597A67DBE87A8EE1FEC33DB71712F4907E0F3B1171E9176
   158189AC8229B26B369C0FE2BBD5964CA2ABFC7D955485056102844E84E8F79E
   0F30BF41D5F42B3C4F4CCA9BF9334D5728518473A0E61A3AFC88F59034F27154
   6B5D806D86F1E8BC6B54B4E05F80C44835DCC2C534E419F63BBFDB305C1733B4
   2DD2CC5795876F004F18C2E4D64B2C9FC6939590BE32501B6A6CEDB19B5FBF47
   887C76E14C99A36D46E99B5C76782E4E345ECB37E8886303C84849ADC8BDE1AF
   4E3A8096AEE407A40699D5C000ADCD16A4805DDF8FB208FFB902EF14031CFFBE
   3C0DC03588EBF15557B3B1029B2CD196064BC0DEE1F11D12391825B86CB34A6F
   BEBBAD43B0FE0EA43301F93D0B26ACED182B1E27063AE578C003D4D4498132B8
   D980532754CFFBD9E6D8917615B62AE08295FC46391AA0FD9815FDD822D95E9B
   7573CA35477D59B98DE4852065F58FB60E0E620D3E2F5CAD
   )

smimea_lookup.py – Fragt den SMIMEA-Record im DNS ab, lädt das Zertifikat herunter und prüft es mit OpenSSL auf Gültigkeit. Funktioniert interaktiv oder mit übergebenen Werten.

./smimea_lookup.py 
Enter the email address: kernel-error@kernel-error.com

Querying DNS for SMIMEA record:
  70e1c7d87e825b3aba45e2a478025ea0d91d298038436abde5a4c2d0._smimecert.kernel-error.com

Certificate saved as smimea_cert.der
Certificate successfully retrieved and verified:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            73:c1:3c:47:8d:a7:b1:14:b8:71:f0:07:37:f1:b0:fb
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = PL, O = Asseco Data Systems S.A., CN = Certum SMIME RSA CA
        Validity
            Not Before: Mar 13 13:41:55 2025 GMT
            Not After : Mar 13 13:41:54 2027 GMT
        Subject: SN = van de Meer, GN = Sebastian, CN = Sebastian van de Meer, emailAddress = kernel-error@kernel-error.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:
                    00:d0:a9:0b:c5:3a:ba:04:08:54:3f:e6:00:f0:f7:
                    1c:17:be:7e:b4:a8:99:6a:8e:f5:e9:12:2a:ac:8e:
                    7f:39:d6:27:18:66:17:c4:d6:ca:73:4e:1a:9e:63:
                    02:f8:07:60:65:ea:93:d7:62:54:2d:2c:12:bf:f3:
                    2d:5d:49:42:b9:a8:aa:84:e2:e6:3c:e9:b8:43:c1:
                    66:5c:01:4a:65:72:a4:2e:37:6e:d0:62:96:94:fc:
                    c9:42:fe:53:d7:60:52:a4:0c:da:b1:25:7a:1d:50:
                    1d:9c:65:de:18:f2:7c:54:90:a2:41:81:49:8a:20:
                    2e:56:f4:dc:0f:dc:bf:e9:47:66:f9:6e:bf:47:c8:
                    72:37:44:ab:d6:9d:c6:84:41:71:06:df:3d:4f:12:
                    fd:52:a1:3b:78:64:90:36:6d:bf:6c:b5:a8:43:62:
                    1c:d6:86:b0:6d:07:2f:d7:d4:86:bd:0a:c7:06:02:
                    1d:13:7a:36:57:18:dc:d8:70:9d:55:b6:44:28:f8:
                    db:56:b2:68:bd:be:d4:63:a2:52:31:b4:05:66:c0:
                    41:a4:89:58:be:17:67:e2:7e:21:88:1d:21:09:93:
                    5c:02:f2:7e:a3:06:b6:49:97:68:3e:ef:df:86:85:
                    f4:f0:90:ab:09:69:2f:23:2c:d3:4a:c7:ff:22:96:
                    76:8c:ed:62:c6:8c:37:b4:c3:dd:9f:04:ec:9f:5c:
                    9b:b9:f7:12:a5:03:2a:c2:f8:3d:68:da:75:6e:4f:
                    28:86:a6:f6:58:89:cf:ae:a0:c1:5e:36:24:ea:3d:
                    9e:3e:ff:91:d6:86:06:f7:b7:b1:b7:12:00:35:ad:
                    4f:71:36:9e:6d:79:97:7b:4b:2c:c3:57:5a:c5:1c:
                    af:41:9e:79:5b:78:82:2d:d3:6b:6d:0b:0e:46:22:
                    bc:e5:5f:7b:27:fc:b5:2f:dc:d6:a4:fb:d3:3e:f0:
                    9f:89:7c:ad:a2:e7:93:d1:50:9d:e5:47:73:b3:fb:
                    e9:09:1c:ea:2e:27:a4:1c:ba:38:a0:8b:bb:e1:b1:
                    5b:f5:6e:b3:5b:21:d6:6f:5b:1b:1c:c6:fd:d6:36:
                    2a:a8:8a:40:10:f3:d2:73:2f:07:1a:84:1b:c7:65:
                    d6:f7:4c:3b:43:0d:03:6a:32:79:18:d0:81:56:ba:
                    28:82:d7:81:13:dd:15:63:35:99:31:9f:4b:d5:d4:
                    f1:2e:1f:01:02:ba:33:76:6a:df:09:dc:58:32:32:
                    46:d2:0b:ac:81:5b:e5:b8:82:2c:26:0e:fb:b0:7a:
                    db:ab:98:fa:42:f3:16:50:fe:fa:e5:d6:79:d4:ad:
                    29:99:2f:19:9d:59:f3:8d:54:98:8d:77:b6:1e:74:
                    0c:bf:47
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 CRL Distribution Points: 
                Full Name:
                  URI:http://csmimersaca.crl.certum.pl/csmimersaca.crl
            Authority Information Access: 
                OCSP - URI:http://csmimersaca.ocsp-certum.com
                CA Issuers - URI:http://csmimersaca.repository.certum.pl/csmimersaca.cer
            X509v3 Authority Key Identifier: 
                66:FB:C3:0F:BE:F4:BF:E0:9C:C9:AB:4D:DE:47:19:BD:C0:CA:A6:68
            X509v3 Subject Key Identifier: 
                8D:8C:10:2E:11:D8:70:04:F7:DD:B4:E0:4F:F0:17:81:88:8A:32:A0
            X509v3 Certificate Policies: 
                Policy: 2.23.140.1.5.4.2
                Policy: 1.2.616.1.113527.2.100.1.1
                  CPS: https://www.certum.pl/CPS
            X509v3 Extended Key Usage: 
                E-mail Protection, TLS Web Client Authentication
            X509v3 Key Usage: critical
                Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
            X509v3 Subject Alternative Name: 
                email:kernel-error@kernel-error.com
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        70:72:47:99:f0:5c:f4:c8:21:85:4f:43:bd:95:0b:b6:08:b9:
        89:04:63:49:21:4f:9d:0e:ec:79:f7:3a:59:db:f4:06:36:08:
        fe:5a:7a:7f:a5:0c:d4:6a:15:48:60:18:eb:9c:33:44:18:08:
        4d:8f:97:fe:32:ea:21:cc:ba:fe:90:2b:f6:47:2d:b6:ca:60:
        d7:9e:be:09:91:9a:fa:06:52:d9:2c:b1:3b:50:64:00:ba:f4:
        77:4f:32:63:96:7a:49:54:8a:6f:72:3a:dc:bb:71:5a:f7:97:
        05:09:9e:5e:c8:4e:28:3d:af:a3:46:59:08:f4:14:8c:2b:15:
        3c:41:d0:51:c9:42:95:d4:f0:42:54:21:7d:1c:8e:48:df:59:
        d9:2e:cb:cb:4a:87:2e:c7:28:a9:54:da:f7:b6:61:de:80:37:
        f7:f1:03:39:36:12:14:16:39:01:ac:fe:98:f3:d5:97:a6:7d:
        be:87:a8:ee:1f:ec:33:db:71:71:2f:49:07:e0:f3:b1:17:1e:
        91:76:15:81:89:ac:82:29:b2:6b:36:9c:0f:e2:bb:d5:96:4c:
        a2:ab:fc:7d:95:54:85:05:61:02:84:4e:84:e8:f7:9e:0f:30:
        bf:41:d5:f4:2b:3c:4f:4c:ca:9b:f9:33:4d:57:28:51:84:73:
        a0:e6:1a:3a:fc:88:f5:90:34:f2:71:54:6b:5d:80:6d:86:f1:
        e8:bc:6b:54:b4:e0:5f:80:c4:48:35:dc:c2:c5:34:e4:19:f6:
        3b:bf:db:30:5c:17:33:b4:2d:d2:cc:57:95:87:6f:00:4f:18:
        c2:e4:d6:4b:2c:9f:c6:93:95:90:be:32:50:1b:6a:6c:ed:b1:
        9b:5f:bf:47:88:7c:76:e1:4c:99:a3:6d:46:e9:9b:5c:76:78:
        2e:4e:34:5e:cb:37:e8:88:63:03:c8:48:49:ad:c8:bd:e1:af:
        4e:3a:80:96:ae:e4:07:a4:06:99:d5:c0:00:ad:cd:16:a4:80:
        5d:df:8f:b2:08:ff:b9:02:ef:14:03:1c:ff:be:3c:0d:c0:35:
        88:eb:f1:55:57:b3:b1:02:9b:2c:d1:96:06:4b:c0:de:e1:f1:
        1d:12:39:18:25:b8:6c:b3:4a:6f:be:bb:ad:43:b0:fe:0e:a4:
        33:01:f9:3d:0b:26:ac:ed:18:2b:1e:27:06:3a:e5:78:c0:03:
        d4:d4:49:81:32:b8:d9:80:53:27:54:cf:fb:d9:e6:d8:91:76:
        15:b6:2a:e0:82:95:fc:46:39:1a:a0:fd:98:15:fd:d8:22:d9:
        5e:9b:75:73:ca:35:47:7d:59:b9:8d:e4:85:20:65:f5:8f:b6:
        0e:0e:62:0d:3e:2f:5c:ad

Beide Skripte findet ihr auf GitHub, damit ihr sie nutzen oder verbessern könnt.

Warum habe ich geschrieben, dass ich nichts Zuverlässiges finden konnte? Nun, oft stoße ich auf Anleitungen, die noch auf TYPE53 basieren. Das ist nötig, wenn Bind9 den eigentlichen RR-Type noch nicht kennt – also ein klares Zeichen dafür, dass es sich um eine sehr frühe Implementierung handelt.

Ein weiteres häufiges Problem: Der Hash des Local-Parts wird einfach weggelassen. Stattdessen erfolgen die Abfragen direkt auf _smimecert., was aber falsch ist. Ohne den SHA256-Hash des Local-Parts gibt es keine eindeutige Zuordnung zur jeweiligen E-Mail-Adresse.

Warum ist der SMIMEA-DNS-Record so aufgebaut? Ganz einfach:

Der erste Teil, also , sorgt dafür, dass nicht einfach jeder direkt aus der DNS-Zone die E-Mail-Adressen auslesen kann. Statt die E-Mail-Adresse im Klartext zu speichern, wird stattdessen nur der SHA256-Hash des Local-Parts (also der Teil vor dem @) genutzt. Das bedeutet: Wer die genaue E-Mail-Adresse kennt, kann den passenden DNS-Eintrag finden – aber jemand, der einfach nur blind durch die Zone scannt, sieht nur Hashes und kann damit nichts anfangen.

Der _smimecert-Prefix zeigt an, dass es sich um einen SMIMEA-Record handelt, ähnlich wie es bei ._tcp. für SRV-Records oder _acme-challenge. für Let’s Encrypt-Zertifikate der Fall ist.

Und schließlich kommt die Domain, zu der die E-Mail-Adresse gehört.

Zusammen ergibt das einen sicheren, einfach abfragbaren und nicht direkt durchsuchbaren DNS-Eintrag für dein S/MIME-Zertifikat.

Möchte man die Abfrage manuell mit dig für die E-Mail-Adresse „kernel-error@kernel-error.com“ durchführen, muss man zuerst den Local-Part der E-Mail-Adresse (kernel-error) mit SHA256 hashen. Laut RFC 8162, Abschnitt 3.1 wird der SHA-256-Hash auf die ersten 28 Bytes (56 Hex-Zeichen) gekürzt, um die DNS-Label-Längenbeschränkung von 63 Zeichen pro Label (RFC 1035, Abschnitt 2.3.4) einzuhalten.

echo -n "kernel-error" | sha256sum | awk '{print $1}' | cut -c1-56
70e1c7d87e825b3aba45e2a478025ea0d91d298038436abde5a4c2d0

Anschließend kann man die dig-Abfrage korrekt zusammensetzen:

dig +dnssec +short 70e1c7d87e825b3aba45e2a478025ea0d91d298038436abde5a4c2d0._smimecert.kernel-error.com. SMIMEA
3 0 0 30820714308204FCA003020102021073C13C478DA7B114B871F00737 F1B0FB300D06092A864886F70D01010B0500304E310B300906035504 061302504C3121301F060355040A0C1841737365636F204461746120 53797374656D7320532E412E311C301A06035504030C134365727475 6D20534D494D4520525341204341301E170D32353033313331333431 35355A170D3237303331333133343135345A30783114301206035504 040C0B76616E206465204D65657231123010060355042A0C09536562 61737469616E311E301C06035504030C1553656261737469616E2076 616E206465204D656572312C302A06092A864886F70D010901161D6B 65726E656C2D6572726F72406B65726E656C2D6572726F722E636F6D 30820222300D06092A864886F70D01010105000382020F003082020A 0282020100D0A90BC53ABA0408543FE600F0F71C17BE7EB4A8996A8E F5E9122AAC8E7F39D627186617C4D6CA734E1A9E6302F8076065EA93 D762542D2C12BFF32D5D4942B9A8AA84E2E63CE9B843C1665C014A65 72A42E376ED0629694FCC942FE53D76052A40CDAB1257A1D501D9C65 DE18F27C5490A24181498A202E56F4DC0FDCBFE94766F96EBF47C872 3744ABD69DC684417106DF3D4F12FD52A13B786490366DBF6CB5A843 621CD686B06D072FD7D486BD0AC706021D137A365718DCD8709D55B6 4428F8DB56B268BDBED463A25231B40566C041A48958BE1767E27E21 881D2109935C02F27EA306B64997683EEFDF8685F4F090AB09692F23 2CD34AC7FF2296768CED62C68C37B4C3DD9F04EC9F5C9BB9F712A503 2AC2F83D68DA756E4F2886A6F65889CFAEA0C15E3624EA3D9E3EFF91 D68606F7B7B1B7120035AD4F71369E6D79977B4B2CC3575AC51CAF41 9E795B78822DD36B6D0B0E4622BCE55F7B27FCB52FDCD6A4FBD33EF0 9F897CADA2E793D1509DE54773B3FBE9091CEA2E27A41CBA38A08BBB E1B15BF56EB35B21D66F5B1B1CC6FDD6362AA88A4010F3D2732F071A 841BC765D6F74C3B430D036A327918D08156BA2882D78113DD156335 99319F4BD5D4F12E1F0102BA33766ADF09DC58323246D20BAC815BE5 B8822C260EFBB07ADBAB98FA42F31650FEFAE5D679D4AD29992F199D 59F38D54988D77B61E740CBF470203010001A38201C2308201BE300C 0603551D130101FF0402300030410603551D1F043A30383036A034A0 328630687474703A2F2F63736D696D6572736163612E63726C2E6365 7274756D2E706C2F63736D696D6572736163612E63726C3081830608 2B0601050507010104773075302E06082B0601050507300186226874 74703A2F2F63736D696D6572736163612E6F6373702D63657274756D 2E636F6D304306082B060105050730028637687474703A2F2F63736D 696D6572736163612E7265706F7369746F72792E63657274756D2E70 6C2F63736D696D6572736163612E636572301F0603551D2304183016 801466FBC30FBEF4BFE09CC9AB4DDE4719BDC0CAA668301D0603551D 0E041604148D8C102E11D87004F7DDB4E04FF01781888A32A0304C06 03551D20044530433009060767810C010504023036060B2A84680186 F677026401013027302506082B06010505070201161968747470733A 2F2F7777772E63657274756D2E706C2F435053301D0603551D250416 301406082B0601050507030406082B06010505070302300E0603551D 0F0101FF0404030204F030280603551D110421301F811D6B65726E65 6C2D6572726F72406B65726E656C2D6572726F722E636F6D300D0609 2A864886F70D01010B0500038202010070724799F05CF4C821854F43 BD950BB608B989046349214F9D0EEC79F73A59DBF4063608FE5A7A7F A50CD46A15486018EB9C334418084D8F97FE32EA21CCBAFE902BF647 2DB6CA60D79EBE09919AFA0652D92CB13B506400BAF4774F3263967A 49548A6F723ADCBB715AF79705099E5EC84E283DAFA3465908F4148C 2B153C41D051C94295D4F04254217D1C8E48DF59D92ECBCB4A872EC7 28A954DAF7B661DE8037F7F10339361214163901ACFE98F3D597A67D BE87A8EE1FEC33DB71712F4907E0F3B1171E9176158189AC8229B26B 369C0FE2BBD5964CA2ABFC7D955485056102844E84E8F79E0F30BF41 D5F42B3C4F4CCA9BF9334D5728518473A0E61A3AFC88F59034F27154 6B5D806D86F1E8BC6B54B4E05F80C44835DCC2C534E419F63BBFDB30 5C1733B42DD2CC5795876F004F18C2E4D64B2C9FC6939590BE32501B 6A6CEDB19B5FBF47887C76E14C99A36D46E99B5C76782E4E345ECB37 E8886303C84849ADC8BDE1AF4E3A8096AEE407A40699D5C000ADCD16 A4805DDF8FB208FFB902EF14031CFFBE3C0DC03588EBF15557B3B102 9B2CD196064BC0DEE1F11D12391825B86CB34A6FBEBBAD43B0FE0EA4 3301F93D0B26ACED182B1E27063AE578C003D4D4498132B8D9805327 54CFFBD9E6D8917615B62AE08295FC46391AA0FD9815FDD822D95E9B 7573CA35477D59B98DE4852065F58FB60E0E620D3E2F5CAD

Was bedeutet das?
3 → Gibt an, dass es sich um einen S/MIMEA-Record handelt. Die Zahl steht für den sogenannten „Usage“-Wert, also wie das Zertifikat genutzt wird. In diesem Fall bedeutet 3, dass es für eine End-Entity-Zertifizierung gedacht ist, also für die tatsächliche E-Mail-Verschlüsselung und Signatur.

0 → Der „Selector“-Wert. Hier steht 0, was bedeutet, dass der gesamte Public Key aus dem Zertifikat gespeichert wird. Alternativ könnte 1 stehen, dann wäre nur der „Subject Public Key Info“-Teil enthalten.

0 → Gibt an, welche Hash-Funktion verwendet wird. Ist es 1, steht es für SHA-256 steht. Alternativ könnte 2 für SHA-512 verwendet werden oder, wie in unserem Fall 0, was für das komplette Zertifikat steht.

Hexwerte → Das ist der eigentliche Zertifikatsinhalt, also der öffentliche Schlüssel in hexadezimaler Darstellung.

Möchte man den kompletten DNS-Record einmal manuell auf der Konsole prüfen, geht das wie folgt:

dig +short 70e1c7d87e825b3aba45e2a478025ea0d91d298038436abde5a4c2d0._smimecert.kernel-error.com SMIMEA | sed 's/^3 0 0 //' | tr -d '[:space:]' > dns_cert.hex

Damit holen wir uns den SMIMEA-Eintrag, entfernen die vorderen 3 0 0, da diese nur die Nutzungsparameter angeben, und speichern den reinen HEX-Wert in eine Datei.

xxd -r -p dns_cert.hex dns_cert.der

Hier wandeln wir den HEX-String in eine binäre DER-Datei um.

openssl x509 -inform DER -in dns_cert.der -text -noout

So kann man sich das Zertifikat im lesbaren Format anzeigen lassen.

Und nun?

SMIMEA ist leider noch immer nicht besonders weit verbreitet. Das liegt sicherlich daran, dass das RFC noch immer experimental ist, aber auch daran, dass es auf weiteren Techniken aufbaut, die ebenfalls eher selten genutzt werden. So braucht man SMIMEA nur, wenn man überhaupt selbst ein S/MIME-Zertifikat zur Signatur und Verschlüsselung von E-Mails verwendet. Zusätzlich muss die Domain per DNSSEC geschützt sein – was noch weniger verbreitet ist – und dann muss auch noch der zusätzliche Mehrwert von SMIMEA verstanden werden.

Denn SMIMEA verteilt nicht nur die Zertifikate, sondern macht einen direkt initial verschlüsselt erreichbar. Wenn man der Empfänger einer solchen signierten Nachricht ist, kann man das Zertifikat zudem gegen eine vertrauenswürdige DNS-Zone halten und sich so vergewissern, dass es wirklich die Signatur des Absenders ist – ähnlich wie bei TLSA/DANE.

Ihr kennt das doch mit der Sicherheit im Internet: Sie ist nur relevant, wenn man damit Geld verdienen kann oder wenn man Opfer geworden ist. Die Implementierung von SMIMEA ist also aktuell sehr überschaubar. Es gibt Milter für beispielsweise Postfix oder Plugins für Thunderbird, aber vor allem im Enterprise-Umfeld ist mir momentan keine funktionierende Lösung bekannt.

Pffff… Eigentlich wollte ich doch nur schnell schreiben, dass ich da zwei Python-Skripte zusammengebastelt habe – und am Ende ist es doch wieder so ein riesiges Ding geworden. 😅

Aber ich denke, vor allem der Teil mit dem gekürzten Hash des Local-Parts der E-Mail-Adresse ist wichtig zu erklären. Das ist echt eine verrückte Konstruktion. Klar, das hat seinen Sinn, aber zumindest ich bin damals genau an diesem Punkt hängen geblieben.

Naja, jetzt könnt ihr die Skripte nutzen und euch den ganzen Fummel selbst auf der CLI anschauen, testen und vor allem auch verstehen.

Viel Spaß! 😃

B.t.w.: Das einzig korrekt funktionierende online Tool, was ich finden konnte ist: https://www.co.tt/smimea.cgi

Alle anderen sind nicht erreichbar, halten sich nicht ans RFC oder ich war zu blöde, sie zu bedienen.

DNSSEC unter Linux Mint & Ubuntu: SSH-Hostkey-Verifikation erklärt​

29. März 2024 / / Keine Kommentare

Heute habe ich versucht, mich von meiner neuen Linux Mint Installation aus mit einem meiner SSH-Server zu verbinden. Mein SSH-Client hat mich direkt mit der Frage begrüßt, ob ich dem neuen Hostkey vertrauen möchte oder nicht.

ssh username@hostname.kernel-error.org
The authenticity of host 'hostname.kernel-error.org (2a01:5a8:362:4416::32)' can't be established.
ED25519 key fingerprint is SHA256:kTRGVCMRLiHfvJunW2CbW5H3NZmn3Wkx2KnHJXl3iJu.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Für viele mag diese Meldung bekannt und vollkommen normal erscheinen. In der Regel antwortet man initial mit „yes“ und sieht sie nie wieder. Aber diese Meldung hat ihren Grund. Beim initialen Aufbau einer Verbindung zu einem SSH-Server wird einem der Fingerprint des HostKeys angezeigt. So hat man die Möglichkeit, den Fingerprint mit dem erwarteten Fingerprint abzugleichen, um sicherzustellen, dass man sich wirklich mit dem gewünschten SSH-Server verbindet und nicht etwa ein Angreifer Zugangsdaten abfischt. Wenn man eh immer nur „JA“ sagt, könnte man diesen Check auch direkt in seiner ~/.ssh/config mit folgendem Eintrag deaktivieren:

Host *
    StrictHostKeyChecking no

Warum erzähle ich das alles? Nun, weil es für mich eigentlich nicht normal ist, diese Meldung zu sehen. Denn es gibt die Möglichkeit, die Fingerprints der erwarteten HostKeys in seiner DNS-Zone zu hinterlegen und seinen SSH-Client mit der folgenden Konfiguration in seiner ~/.ssh/config anzuweisen, dies einfach selbst zu überprüfen, sofern der SSH-Client eine vertrauenswürdige Antwort vom DNS-Server erhält.

Host *
   VerifyHostKeyDNS yes

Vertrauenswürdige Antwort vom DNS-Server… Hier sind wir schon bei DNSSEC angekommen. Meine DNS-Server, einschließlich des lokalen Resolvers auf meinem Router, unterstützen alle DNSSEC. Meine SSH-Client-Konfiguration ist korrekt und dennoch erscheint die Meldung…. Also habe ich den Verbindungsaufbau mit etwas mehr Debugging-Output gestartet, was bei ssh einfach die zusätzliche Option -vvv bedeutet:

ssh usermane@hostname.kernel-error.org -vvv
[...]
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:kTRGVCMRLiHfvJunW2CbW5H3NZmn3Wkx2KnHJXl3iJu
debug3: verify_host_key_dns
debug1: found 2 insecure fingerprints in DNS
debug3: verify_host_key_dns: checking SSHFP type 4 fptype 1
debug1: verify_host_key_dns: matched SSHFP type 4 fptype 1
debug3: verify_host_key_dns: checking SSHFP type 4 fptype 2
debug1: verify_host_key_dns: matched SSHFP type 4 fptype 2
debug1: matching host key fingerprint found in DNS
[...]

Zu meiner Überraschung sehe ich:

debug1: found 2 insecure fingerprints in DNS

Hm… „insecure“… Er hat also die passenden Einträge in der DNS-Zone gefunden, kann diesen aber nicht vertrauen, weil… ja, warum? Die Antwort des DNS-Servers ist nicht vertrauenswürdig? OK, das lässt sich einfach mit dig und der Option +dnssec testen. Wir suchen einfach im Header nach „ad„:

dig +dnssec hostname.kernel-error.org @8.8.8.8

; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> +dnssec hostname.kernel-error.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48645
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
[...]

@8.8.8.8 gibt an, dass direkt der öffentliche DNS-Server von Google gefragt wird. Dieser wird natürlich meine Server fragen usw., einfach um sicherzugehen, dass meine eigentlichen DNS-Server, die für die Zone zuständig sind, sauber konfiguriert sind. Ich sehe ein „ad„, also ist dort schon mal alles gut. Im Anschluss habe ich den Test noch mit meinem lokalen DNS-Resolver auf dem Router durchgeführt. Also einfach @192.168.0.1 oder was auch immer euer lokaler Router ist. Gleiches Ergebnis…. Aber warum will dann mein Linux Mint nicht? Sollte Linux Mint etwa kein DNSSEC können?

dig +dnssec hostname.kernel-error.org

; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> +dnssec hostname.kernel-error.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1789
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
[...]

Öhhh ähhh… Ja, öhm, geht nicht… Aber warum? Was steht denn in meiner /etc/resolv.conf? 127.0.0.53? Ohhhhhhhh, stimmt! systemd-resolv! OK, ok… Ich könnte also in meiner /etc/systemd/resolved.conf nun einfach DNSSEC=yes setzen und mit einem systemctl restart systemd-resolved sollte dann… Nope, leider nicht. Nun geht überhaupt keine DNS-Auflösung mehr. Es scheint am eingesetzten Stub-Resolver zu liegen, den man ebenfalls noch ändern kann usw… Nennt mich etwas oldschool, aber für meine Zwecke reicht der klassische Weg über die vom NetworkManager gepflegte resolv.conf. Um also systemd-resolved zu deaktivieren und auf den NetworkManager zu wechseln, sind die folgenden Schritte nötig:

sudo systemctl disable systemd-resolved
sudo systemctl stop systemd-resolved
sudo rm /etc/resolv.conf

Dann in die Konfigurationsdatei vom NetworkManager /etc/NetworkManager/NetworkManager.conf in der [main]-Sektion die folgende Option setzen:

dns=default

Nun nur noch den NetworkManager neu starten und schon sollte die /etc/resolv.conf mit den DNS-Informationen gefüttert werden:

sudo systemctl restart NetworkManager
cat /etc/resolv.conf
# Generated by NetworkManager
search kernel-error.local
nameserver 10.10.88.1
nameserver fd00:424e:6eff:f525:454e:6eff:f525:4241

Perfekt! Also los, noch ein Versuch mit dem SSH-Client und… nichts… DNS-Auflösung funktioniert, aber es ist noch immer „insecure„. Stimmt! Es fehlt etwas in meiner resolv.conf. Wir brauchen bestimmt noch die folgende Option:

options edns0

Jetzt aber! HA, dig ist schon mal glücklich, ich sehe ein „ad“. Ähm, aber der SSH-Client noch immer nicht?! Was zum… OK, OK… Irgendwas um SSH muss ich vergessen haben. Aber was? Wie macht SSH das überhaupt? Vielleicht gibt mir das eine Idee. Also, mal kurz in den Code geschaut, C bekomme ich gerade noch hin:

        /* Check for authenticated data */
        if (ldns_pkt_ad(pkt)) {
                rrset->rri_flags |= RRSET_VALIDATED;
        } else { /* AD is not set, try autonomous validation */
                ldns_rr_list * trusted_keys = ldns_rr_list_new();

                debug2("ldns: trying to validate RRset");
                /* Get eventual sigs */
                rrsigs = ldns_pkt_rr_list_by_type(pkt, LDNS_RR_TYPE_RRSIG,
                    LDNS_SECTION_ANSWER);

                rrset->rri_nsigs = ldns_rr_list_rr_count(rrsigs);
                debug2("ldns: got %u signature(s) (RRTYPE %u) from DNS",
                       rrset->rri_nsigs, LDNS_RR_TYPE_RRSIG);

                if ((err = ldns_verify_trusted(ldns_res, rrdata, rrsigs,
                     trusted_keys)) == LDNS_STATUS_OK) {
                        rrset->rri_flags |= RRSET_VALIDATED;
                        debug2("ldns: RRset is signed with a valid key");
                } else {
                        debug2("ldns: RRset validation failed: %s",
                            ldns_get_errorstr_by_id(err));
                }

                ldns_rr_list_deep_free(trusted_keys);
        }

Aaaaaaaaaaaaaaaaaaaaaaa… ldns… woher bekommt er wohl die Trust Keys? Genau… woher? Da fehlt also NOCH etwas in meiner resolv.conf:

options edns0 trust-ad

Und? genau… geht 😀 

ssh usermane@hostname.kernel-error.org -vvv
[...]
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:kTRGVCMRLiHfvJunW2CbW5H3NZmn3Wkx2KnHJXl3iJu
debug3: verify_host_key_dns
debug1: found 2 secure fingerprints in DNS
debug3: verify_host_key_dns: checking SSHFP type 4 fptype 1
debug1: verify_host_key_dns: matched SSHFP type 4 fptype 1
debug3: verify_host_key_dns: checking SSHFP type 4 fptype 2
debug1: verify_host_key_dns: matched SSHFP type 4 fptype 2
debug1: matching host key fingerprint found in DNS
[...]

Pfff… nun habe ich natürlich die Optionen von Hand in meine resolv.conf eingetragen, der NetworkManager wird diese Option also spätestens beim nächsten Boot rauswerfen. Also muss ich noch meinem NetworkManager beibringen, dass er bitte diese Option ebenfalls in meine resolv.conf schreibt, wenn das jeweilige Netzwerkprofil aktiviert ist. Dazu gibt es aber leider keinen Menüpunkt in der GUI vom NetworkManager, also muss das per CLI gemacht werden. Dieses für IPv4 und IPv6 gleichermaßen, sonst greift es leider nicht!

nmcli conn modify DEINE-PROFIL-UUID ipv4.dns-options edns0,trust-ad
nmcli conn modify DEINE-PROFIL-UUID ipv6.dns-options edns0,trust-ad

Oh, ein nmcli conn show listet die bestehenden und vor allem das aktive Profil inkl. der UUID auf. Davon abgesehen, klappt es nun so und ist rebootfest.

So und nun ihr! Ich bin mit meinem FreeBSD-Wissen an das Thema herangegangen. Wie macht man das als Hardcore-Linux-User und mit systemd-resolved richtig und funktionierend?

DNSSEC, EDNS und PMTU-Size Fehler beim BIND beheben

5. Juli 2017 / / Keine Kommentare

Mir ist in der letzten Zeit an ein paar Systemen ein kleines „Problem“ im Zusammenhang mit DNSSEC, IPv6 und UDP Paketgrößen aufgefallen. Wobei aufgefallen hier nicht ganz korrekt ist, ich bin durch http://dnsviz.net darauf gestoßen worden. Die Jungs kommen mir nämlich mit der folgenden Warnung entgegen:

domain.tld/A: No response was received until the UDP payload size was decreased, indicating that the server might be attempting to send a payload that exceeds the path maximum transmission unit (PMTU) size. (2001:210:5000:bbbb::aaaa:1, UDP_0_EDNS0_32768_4096)

Diese Meldung besagt das es vom jeweiligen DNS Server erst eine Antwort gegeben hat, nachdem die UDP Größe verringert wurde. Dieses fällt einem im normalen Tests mit dig / drill oder ähnlichem nicht wirklich auf. Denn hier wird absolut automatisch die Paketgröße weiter verringert bis es klappt. Es „dauert“ nur etwas länger….

Der DNS-Server, in diesem Fall ein bind9.11, versucht auf die Frage mit einem IPv6 UDP Paket zu Antworten und schickt dieses mit 4096 Byte raus. Aus irgendeinem Grund (Firewall, Einstellungen im OS, Filter auf dem Netzwerk….) wird dieses Paket auf seinem Weg aber verworfen und erreicht sein Ziel nicht. Da wir hier über UDP sprechen merkt das der Server nicht und glaubt er habe seinen Job gut gemacht. Woher soll bind auch wissen das sein Paket nicht angekommen ist oder irgendwas auf dem Weg sein Pakete mit dieser Größe nicht mag?

Um als Admins herauszufinden wie groß die Pakete von seinem System denn werden können kann man folgenden einfachen Test nutzen:

$ dig +short rs.dns-oarc.net txt
rst.x490.rs.dns-oarc.net.
rst.x499.x490.rs.dns-oarc.net.
rst.x457.x499.x490.rs.dns-oarc.net.
"2001:310:6000:f::1fc7:1 sent EDNS buffer size 512"
"Tested at 2017-07-05 08:23:52 UTC"
"2001:310:6000:f::1fc7:1 DNS reply size limit is at least 499"

Wie zu erkennen ist endet es auf diesem System bei 512 Byte. Wenn wir uns jetzt nicht weiter um den Grund kümmern wollen oder können, müssten wir also unserem bind sagen das er bitte immer nur mit maximal 512 Byte arbeitet, wenn er UDP nutzt. Dieses geht wie folgt im Options Block:

options {
	[....]
	edns-udp-size 512;
	max-udp-size 512;
	[....]
};

edns-upd-size ist hier für das Empfangen und max-udp-size für das Senden von Paketen. Ab dem Moment probiert es bind nur noch mit 512 Byte und die Clients werde auf ihre erste Frage hin direkt eine Antwort bekommen, ohne die Frage so oft wiederholen zu müssen, bis sie schrittweise zurück auf 512 Byte sind.

So long…

DNSSEC IPv6 DENIC und ein DNS in Japan

30. Januar 2017 / / Keine Kommentare

Ich brauche mal eure Hilfe…

Zum Spaß habe ich mir einen VPS Server in Japan geklickt. Was nun damit tun? Einfach mal ein weiteren DNS Server nutzen \o/ Gute Idee? Nein… Warum nicht? Weil der Server in Japan steht, höhere Antwortzeiten hat und der meist zufällig entscheidet, welcher DNS Server nun gefragt wird. Ich habe somit also sporadisch DEUTLICH langsamere DNS Antworten. Für meinen Spieltrieb aber gerade OK .-P

Ist also nun ein FreeBSD 10 mit einem Bind9.11 als slave für drei Spielzonen (kernel-error.org, kernel-error.com, kernel-error.de). FreeBSD ans Ende gepatcht, aktuellen Bind drauf, getestet ob die Kiste sauber signierte Zonen abfragen und prüfen kann (TCP/UDP und größer 512) alles gut. Dann als slave eingebunden wieder getestet und dann in die Zone darüber eintragen lassen. Die Zonen org. sowie com. haben den DNS-Server einfach gefressen. die Zone de. meckert aber! DNS timeout bei IPv6 O_o Öhm, ok… dig und drill sagen das geht aber. Bind ist auch fest ein und ausgehend an die IPv6 Adresse gebunden. Als „Firewall“ rennt PF, das mal deaktiviert ändert aber nichts. Vielleicht filter der Provider? Nope nur switch, iptables und ebtables öhm, das klingt sehr spartanisch.

Hat das Problem nur denic? Nö, DNSViz scheint es auch nicht zu können: http://dnsviz.net/d/kernel-error.com/dnssec/

Wie gesagt NUR bei IPv6! Jetzt habe ich mir alle Mühe gegeben diesen Timeout selbst mal zu produzieren, klappt aber nicht. Bei mir geht es einfach IMMER egal was für Optionen ich dig mitgebe.

# dig @2001:310:6000:f::1fc7:1 +edns +multi +norec +bufsize=4096 kernel-error.com IN MX +short
10 smtp.kernel-error.de.
# dig @2001:310:6000:f::1fc7:1 +tcp +edns +multi +norec +bufsize=4096 kernel-error.com IN MX +short
10 smtp.kernel-error.de.

Ich verstehe das nicht! Ich mache am bind keine Unterscheidung zwischen IPv4 und IPv6, für mich geht alles. Alle Antworten und Fragen in alle Richtungen laufen ohne jedes Problem. Nur DNSViz und denic scheinen ein „Problem“ zu haben. Mal sehen ob jemand von der denic mit einen sinnvollen Tipp geben kann. Mir würde ja schon der dig Aufruf reichen der zu einem timeout führt :-/ Dann hätte ich etwas zum Testen.

Oh ja, ich habe natürlich auch ganz brav mal tcpdump laufen lassen. Leider sieht es hier ebenfalls einfach funktionstüchtig aus 🙁

https://www.kernel-error.de/download/dns.tar.gz

Hat von euch irgendjemand eine Idee?

*U-P-D-A-T-E*

Die interne Fehlermeldung der API DENIC:

ERROR: 223 Timeout after switching from UDP to TCP – switch to TCP due to timeout (target) (ns3.kernel-error.com./2001:310:6000:f:0:0:1fc7:1:53)

*U-P-D-A-T-E*

Mal querry log eingeschaltet:

30-Jan-2017 18:30:04.669 client @0x802e62600 2a02:568:201:214::1:15#38145 (ns3.kernel-error.com): query: ns3.kernel-error.com IN A -E(0)DC (2001:310:6000:f::1fc7:1)
30-Jan-2017 18:30:04.670 client @0x802e62600 2a02:568:201:214::1:15#41589 (ns3.kernel-error.com): query: ns3.kernel-error.com IN AAAA -E(0)DC (2001:310:6000:f::1fc7:1)
30-Jan-2017 18:30:04.938 client @0x802e62600 2a02:568:201:214::1:15#20703 (kernel-error.de): query: kernel-error.de IN SOA - (2001:310:6000:f::1fc7:1)
30-Jan-2017 18:30:05.510 client @0x802e6f800 2a02:568:201:214::1:15#58465 (kernel-error.de): query: kernel-error.de IN NS -T (2001:310:6000:f::1fc7:1)
30-Jan-2017 18:30:05.889 client @0x802e62600 2a02:568:201:214::1:15#47548 (kernel-error.de): query: kernel-error.de IN SOA -E(0)D (2001:310:6000:f::1fc7:1)
30-Jan-2017 18:30:05.896 client @0x802e62600 2a02:568:201:214::1:15#55493 (kernel-error.de): query: kernel-error.de IN DNSKEY -E(0)D (2001:310:6000:f::1fc7:1)
30-Jan-2017 18:30:06.416 client @0x802e70c00 2a02:568:201:214::1:15#37170 (kernel-error.de): query: kernel-error.de IN DNSKEY -E(0)TD (2001:310:6000:f::1fc7:1)

*U-P-D-A-T-E*

Ich glaube es nicht… Ich teste hier gerade rum, will einem Kollegen zeigen das es nicht geht und das Update läuft bei DENIC einfach durch und OK Ö_ö ich verstehe das nicht, wirklich nicht. Absolut 0,0 warum geht das jetzt und warum meint DNSViz das es dennoch nicht geht? Was passiert hier?

*U-P-D-A-T-E*

Bleibt nur noch meine Vermutung, dass es wirklich um die Antwortzeit des Servers geht… Die liegt so zwischen 200 und 300ms. Das ist echt lange aber auch nicht SOOOOOOO lange :-/ Mal sehen ob von denic irgendwas kommt?!?!

*U-P-D-A-T-E*

Da fliegt mir doch gerade folgende Info rein:

die DENIC meinte dazu:

    unsere Kollegen können derzeit nicht genau sagen woran es hängt. Jedoch sind unsere Verbindungen nach Korea zeitweise leicht beeinträchtigt, evtl. wurde dir Nast Prüfung genau in dem Moment durchgeführt.


Es scheint als bekommen wir das nicht geklärt. Aber schön, wenn das
Update nun durch ist.

PS: Ein leicht ungutes Gefühl bleibt ...

DNSSEC, DANE und TLSA mit Postfix: Hintergründe und aktuelle Probleme

16. Januar 2015 / / Keine Kommentare

Man man man… Was ist denn da passiert? Seit 3 oder 4 Tagen scheint das Thema im Internet irgendwie besonders aktiv zu sein, oder? Nur warum?!?!

Plötzlich bekomme ich nicht nur jeden Tag einen Haufen Anfragen zu dem Thema, viel scheinen auch irgendwas testen zu wollen und pumpen E-Mails mit Random-Empfängern an meine Domains….

Im Grunde habe ich ja nichts gegen Tests. Nur grob abgesprochen wäre schon schön, mein Monitoring wird sonst immer so „wuschig“! 😀

Um noch mal ein paar Themen zusammen zu fassen:

1. Basis von allem ist DNSsec
2. TLSA Records „ist DANE“
3. Postfix kann TLSA Records auswerden, ohne selbst welche für sein System zu haben.

Mein kleines DNSSEC Howto

DNSSEC und DNS-based Authentication of Named Entities (DANE)

Postfix SSL/TLS gesichert mit TLSA / DANE und DNSSEC

DNSSEC fähiger Registrar

TLSA / DANE RECORD von Hand manuel prüfen.

So long…

Neue dnssec KSKs

18. November 2014 / / Keine Kommentare

Ich habe nach längerem dann mal meinen KSK für´s dnssec getauscht. Bzw. ich bin gerade dabei 🙂

Der alte war noch ein 1024bit NSEC3RSASHA1. Jetzt ist auch klar warum er getauscht werden musste 😛 Der neue ist nun ein NSEC3RSASHA1 mit 4096bit. Als zweiten neuen Key habe ich einen RSASHA512 mit ebenfalls 4096bit erstellt. So habe ich für den Fall der Fälle auch direkt einen ohne SHA1 im „Anschlag“.

Dieser neue Key ersetzt in Kürze den alten 1024bit KSK Schlüssel. Bereits jetzt sollte es aber für jeden nur noch über den 4096bit NSEC3RSASHA1 Schlüssel laufen.

Inzwischen sollte wohl jede halbwegs aktuelle Software mit dnssec Support mit diesen Schlüsseln umgehen können. Wenn nicht, wird es Zeit für ein Update 😀

In diesem Sinne!

* U-P-D-A-T-E *

Inzwischen ist auch der andere Schlüssel oben und sollte sich so langsam durch die Welt sprechen….

http://dnsviz.net/d/kernel-error.de/dnssec/

http://dnsviz.net/d/kernel-error.org/dnssec/

http://dnsviz.net/d/kernel-error.com/dnssec/

DNSSEC fähiger Registrar

18. Juni 2014 / / Keine Kommentare

In der letzten Zeit häufen sich bei mir die Anfragen, mit welchem Registart ist zusammenarbeite. Vor allem im Hinblick auf DNSSEC und dem KSK oder besser der DS-RECORDS.

Hier kann und möchte ich gerne die SpeedPartner GmbH aus Neuss empfehlen. Hier arbeite ich gerne mit dem Herrn Metz zusammen. Es ist immer jemand erreichbar, vor allem lassen sich schnell und einfach auch etwas ungewöhnliche Dinge umsetzten. Zwar ist das Webinterface (stand 06.2014) noch nicht so weit das man darüber DS-RECORDS einwerfen kann, der Weg per E-Mail funktioniert aber in der Regel binnen Minuten / Stunden.

Es kommt ja eher selten bis nie vor, das ich hier Werbung für ein Unternehmen mache, dieses hat es aber verdient.

So long…

Webseite: http://www.speedpartner.de/

E-Mail Adresse: info@speedpartner.de

Postfix SSL/TLS sichern mit TLSA, DANE und DNSSEC

28. Januar 2014 / / Keine Kommentare

Mein Domains sind nun schon seit langem per DNSSEC gesichert. Schnell habe ich auch TLSA-RECORDS für mein SSL/TLS X.509 Zertifikat des Webservers Apache veröffentlicht, damit die verschlüsselte Verbindung zu meiner Webseite ebenfalls per DANE gesichert ist.

DNSSEC: https://www.kernel-error.de/dnssec

DANE: https://www.kernel-error.de/dnssec/tls-ssl-zertifikatschecksummen-im-dns

Seit Januar diesen Jahres beherscht nun Postfix ebenfalls die Möglichkeit TLSA Records zu prüfen. Da mache ich natürlich mit!

Zuerst muss die Postfix Version natürlich passen. Kleiner 2.11 sollte es nicht sein, die Postfixversion zeigt sich schnell per:

$ postconf -d | grep mail_version
mail_version = 2.11.0

Mein Mailserver bietet natürlich schon immer die Möglichkeit einer verschlüsselten Verbindung an. Daher gehe ich einfach mal nicht näher darauf ein, wie man sein Postfix dazu überredet. Ganz kurz… Aktivieren lässt sich die Unterstützung für DANE / TLSA mit folgenden drei Konfigurationsänderungen:

$ postconf -e "smtpd_use_tls = yes"
$ postconf -e "smtp_dns_support_level = dnssec"
$ postconf -e "smtp_tls_security_level = dane"

Keine Sorge, alles bietet einen Failback an, so leidet die Kommunikation mit _nicht_ DANE fähigen Systemen nicht.

Zum erstellen des TLSA-RECORDS muss selbstverständlich nicht unbedingt der von mir in früheren Beiträgen erwähnte Hash-slinger eingesetzt werden. Openssl macht dieses fast genau so schnell.

$ openssl x509 -in postfix.pem -outform DER | openssl sha256
(stdin)= 94c8e1bdfff4f6d3fec0c4e2f26293d78870650bfd3534e77b93cdaccb77eb95

Aus diesem Hash erstelle ich nun den TLSA RECORD. Für die E-Mail Kommunikation ist es mir lieb, wenn der TTL (Lebensdauer) des Records nicht ZU lange ist. Bei einem Zertifikatswechsel dauert es sonst unnötig lange bis der neue Record gültig ist. Daher setzte ich ihn auf 1 Stunde.

_25._tcp.smtp.kernel-error.de. 1H IN TLSA 3 1 1 8cb0fc6c527506a053f4f14c8464bebbd6dede2738d11468dd953d7d6a3021f1
_465._tcp.smtp.kernel-error.de. 1H IN TLSA 3 1 1 8cb0fc6c527506a053f4f14c8464bebbd6dede2738d11468dd953d7d6a3021f1

Wie zu sehen ist biete ich den TLSA RECORD direkt für Port TCP 25 und TCP 465 an. Schnell nur noch testen ob der TLSA RECORD mit dig auch sauber abgefragt werden kann.

$ dig _25._tcp.smtp.kernel-error.de +dnssec +m

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> _25._tcp.smtp.kernel-error.de +dnssec +m
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28381
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;_25._tcp.smtp.kernel-error.de. IN A

;; AUTHORITY SECTION:
kernel-error.de.        86400 IN SOA ns1.kernel-error.de. root.kernel-error.de. (
                                20140102708 ; serial
                                10000      ; refresh (2 hours 46 minutes 40 seconds)
                                1800       ; retry (30 minutes)
                                604800     ; expire (1 week)
                                86400      ; minimum (1 day)
                                )
kernel-error.de.        86400 IN RRSIG SOA 7 2 86400 20150511054702 (
                                20140516054702 38150 kernel-error.de.
                                QXUpVl3myVAUGn/ox8J5aihAySHdWpojyPuhV5QKgDUy
                                qYRPyryWyBoGG+x5cGs0JpPBqQA3lRovAM4JFvC3hRmO
                                FU3fVTiYlvAJK7WsTSgPJLYpXrBnS+NN0O2UW3W+Ru1K
                                2P5dj+BWNO1wqXs+VU7WpMPwq/ESlK88hxXE1Gc= )
_25._tcp.smtp.kernel-error.de. 86400 IN NSEC _465._tcp.smtp.kernel-error.de. RRSIG NSEC TLSA
_25._tcp.smtp.kernel-error.de. 86400 IN RRSIG NSEC 7 5 86400 20150511054702 (
                                20140516054702 38150 kernel-error.de.
                                ToC8GtXFenieGjA32eoHACNGCg+tFr05vz6w9yiHYrDj
                                rHGBabc7MMjqUWNsf7L059YhR7dLoAPqhy2ZThWqFbRD
                                ZsfPQSgHIazEuKvOE7i2Ee/znU2d57X8nVkp8scUKZ1R
                                kGdK5DUDlAcYn0YdpjYaUTn2STdbM9IDcdrASPE= )

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Mo Jan 27 08:50:36 2014
;; MSG SIZE  rcvd: 506

Schon lässt sich im Postfix Logfile erkennen ob Verbindungen getraut wird oder nicht.

Jan 27 08:32:02 mailserver postfix/smtp[3779]: Verified TLS connection established to mx02.example.de[99.88.12.167]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Jan 27 08:33:19 mailserver postfix/smtp[3779]: Untrusted TLS connection established to smtp2.example.de[2001:333:6661:99::34]:25: TLSv1 with cipher ADH-AES256-SHA (256/256 bits)

Wenn man mich fragt, ist die Kombination aus DNSSEC, DANE / TLSA deutlich besser als dieses hässliche EmiG. EmiG benötigt eine unnötig teure Zertifizierung durch den TüV, dieses kann sich nicht jeder leisten. Damit ist dieses „sichere“ Verfahren fast nur durch Unternehmen zu realisieren die genug Kohle haben. Kleinere werden damit einfach abgehängt. Verfahren die Sicherheit nur für „reiche“ zur Verfüfung stellen sollte man aus meiner Überzeugnung nicht unterstützen.

Eine weitere schnelle und einfache Möglichkeit seinen TLSA-RECORD des Mailservers / Postfix zu testen ist posttls-finger:

$ posttls-finger -t30 -T180 -c -L verbose,summary kernel-error.de
posttls-finger: initializing the client-side TLS engine                                                                                                                                                                          
posttls-finger: using DANE RR: _25._tcp.smtp.kernel-error.de IN TLSA 1 0 1 94:C8:E1:BD:FF:F4:F6:D3:FE:C0:C4:E2:F2:62:93:D7:88:70:65:0B:FD:35:34:E7:7B:93:CD:AC:CB:77:EB:95                                                       
posttls-finger: setting up TLS connection to smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25                                                                                                                                  
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: TLS cipher list "aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!aNULL"                                                                                        
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: depth=1 verify=0 subject=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA                      
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: depth=1 verify=0 subject=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA                      
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: depth=0 verify=1 subject=/description=y0xkuso3gx7t8h0o/C=DE/ST=Nordrhein-Westfalen/L=Sprockh\xF6vel/O=Sebastian Van De Meer/CN=smtp.kernel-error.de/emailAddress=postmaster@kernel-error.de                                                                                                                                                                                                   
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: depth=0 matched end entity certificate sha256 digest 94:C8:E1:BD:FF:F4:F6:D3:FE:C0:C4:E2:F2:62:93:D7:88:70:65:0B:FD:35:34:E7:7B:93:CD:AC:CB:77:EB:95         
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: subject_CN=smtp.kernel-error.de, issuer_CN=StartCom Class 2 Primary Intermediate Server CA, fingerprint=E1:92:93:D4:CA:E9:5D:44:B5:CC:A4:15:1F:12:A6:E0:B5:C2:97:56, pkey_fingerprint=E9:84:8E:51:47:99:90:53:0B:2C:2E:1E:70:6E:DE:CA:A4:65:8A:C5                                                                                                                                             
posttls-finger: Verified TLS connection established to smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

So bei Fragen, einfach fragen 🙂

09-08-2014 Update

Ich habe zur Auswertung den Mailgraph etwas angepasst ( mailgraph Graphen um DANE erweitern ). Dieser wirft mir nun den unten stehenden Graphen für ausgehende Verbindungen raus.

« Ältere Beiträge

© 2025 -=Kernel-Error=-

Theme von Anders Norén — Hoch ↑