Datenhaufen zu IT und Elektronik.

Schlagwort: Verschlüsselung

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

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.

FreeBSD: Unverschlüsseltes ZFS-Dataset-Jail zu verschlüsseltem ZFS-Dataset migrieren

Bild der Bücher FreeBSD Mastery ZFS und FreeBSD Mastery Advanced ZFS

Mit FreeBSD 13 lässt sich die native ZFS Verschlüsselung direkt nutzen. Dabei muss man zwischen einem komplett verschlüsselten zpool und verschlüsselten Datasets unterscheiden. Hat man einen komplett verschlüsselten zpool, bedeutet es nicht, dass damit auch alle Datasets verschlüsselt sein müssen, so wie es auch nicht bedeutet, dass man Datasets nur verschlüsseln kann, wenn auch der komplette ZFS Pool verschlüsselt ist.

Wer nun also sein FreeBSD auf Version 13 gehoben hat, möchte ggf. einzelne ZFS Datasets verschlüsseln. In der Praxis trifft dieses sicher oft auf Jails zu. Diese liegen in der Regel in eigenen ZFS Datasets und mit dem folgenden Beispiel lassen sich diese und andere Datasets nachträglich verschlüsseln.

Im Beispiel haben wir den Pool zroot und in diesem das Dataset varta. Weder der zpool noch das Dataset sind aktuell verschlüsselt:

root@testtest:/ # zfs list zroot/varta
NAME          USED  AVAIL     REFER  MOUNTPOINT
zroot/varta   100M  12.0G      100M  /zroot/varta
root@testtest:/ # zfs get encryption zroot/varta
NAME         PROPERTY    VALUE        SOURCE
zroot/varta  encryption  off          default
root@testtest:/ #

Aktiviert man bei ZFS Dinge wie Komprimierung oder Deduplikation sind diese immer nur ab dem Moment der Aktivierung und bis genau zur Deaktivierung aktiv. Dieses hat viele Vorteile aber auch Nachteile. So greift dieses nur für Daten, welche neu geschrieben werden. Möchte man dieses nachträglich auf alle Daten anwenden, muss man die Daten komplett neu schreiben. Dieses lässt sich am einfachsten und schnellsten per zfs send und zfs receive erledigen. Wenn man also sein bestehendes Dataset verschlüsseln möchte, dann geht dieses faktisch nicht, sondern man erstellt im Grunde ein neues verschlüsseltes Dataset und schreibt seine Daten dort rein.

Bevor wir nun mit der Migration starten, müssen wir noch eine Kleinigkeit wissen…. Zum Verschlüsseln der Daten benötigen wir noch ein Geheimnis, einen Schlüssel/Key. Dieser kann bei ZFS in verschiedenster Form und an verschiedensten Orten liegen. So könnte man den Key zur Ver- und Entschlüsselung auf einen USB-Stick ablegen. Nur wenn dieser auch im System steckt usw. usw.. Der eingängigste Weg ist sicher ein Passphrase welches per prompt abgefragt wird. Will man sein verschlüsseltes Dataset öffnen, wird man nach einem Kennwort gefragt, welches sich das System bis zum nächsten Reboot oder dem manuellen „Schließen“ des Datasets merkt. Diesen Zustand wollen wir nach der Migration, in diesem Beispiel, erreichen.

Zur Verdeutlichung erstellen wir kurz ein neues verschlüsseltes Dataset:

root@testtest:/ # zfs create -o encryption=on -o keyformat=passphrase -o keylocation=prompt zroot/enc-beispiel
Enter passphrase:
Re-enter passphrase:

Damit haben wir ein neues Dataset welches sofort benutzt werden kann, alles was wir in dieses legen, ist verschlüsselt.

root@testtest:/ # zfs list zroot/enc-beispiel
NAME                 USED  AVAIL     REFER  MOUNTPOINT
zroot/enc-beispiel   200K  12.0G      200K  /zroot/enc-beispiel

Schauen wir in die Optionen des Datasets ist die Verschlüsselung aktiviert und der Schlüssel wird per Prompt vom Benutzer abgefragt:

root@testtest:/ # zfs get encryption,keylocation,keyformat zroot/enc-beispiel
NAME                PROPERTY     VALUE        SOURCE
zroot/enc-beispiel  encryption   aes-256-gcm  -
zroot/enc-beispiel  keylocation  prompt       local
zroot/enc-beispiel  keyformat    passphrase   -

Wie immer wird das Dataset sofort eingehangen:

root@testtest:/ # mount |grep enc-beispiel
zroot/enc-beispiel on /zroot/enc-beispiel (zfs, local, noatime, nfsv4acls)

Nach einem reboot, wird das Dataset nicht automatisch eingehangen, da ZFS den Schlüssel nicht hat. Wenn wir es nun einhängen und ZFS anweisen, den Schlüssel zu laden (Option -l), dann werden wir zur Eingabe des Kennwortes aufgefordert und können das Dataset im Anschluss wieder nutzen:

root@testtest:~ # mount | grep enc-beispiel
root@testtest:~ # zfs get encryption,keylocation,keyformat zroot/enc-beispiel
NAME                PROPERTY     VALUE        SOURCE
zroot/enc-beispiel  encryption   aes-256-gcm  -
zroot/enc-beispiel  keylocation  prompt       local
zroot/enc-beispiel  keyformat    passphrase   -
root@testtest:~ # mount | grep enc-beispiel
root@testtest:~ # zfs mount -l zroot/enc-beispiel
Enter passphrase for 'zroot/enc-beispiel':
root@testtest:~ # mount | grep enc-beispiel
zroot/enc-beispiel on /zroot/enc-beispiel (zfs, local, noatime, nfsv4acls)

Gut gut… So viel zu den Basics. Damit ist nun auch klar, warum im nun folgenden zfs send / zfs reveive Beispiel, der Schlüssel einen Umweg nehmen wird. Denn durch das pipen kommen wir so schlecht an die stdin heran, um das Passphrase einzugeben 😉 Wir sind nun also wieder zurück bei unserem unverschlüsselten Dataset varta und dessen Migration in einen verschlüsselten Zustand. Als erstes legen wir nun das gewünschte Passphrase in einer Datei ab:

root@testtest:~ # echo 'Tolles-Kennwort' > /kennwort.txt
root@testtest:~ # cat /kennwort.txt 
Tolles-Kennwort

Ebenfalls erstellen wir einen snapshot vom Dataset varta, welchen wir zur Migration nutzen:

root@testtest:~ # zfs snapshot zroot/varta@migration
root@testtest:~ # zfs list -t snapshot
NAME                    USED  AVAIL     REFER  MOUNTPOINT
zroot/varta@migration     0B      -      100M  -

Jetzt kann die eigentliche Migration starten:

root@testtest:~ # zfs send zroot/varta@migration | zfs receive -F -o encryption=on -o keyformat=passphrase -o keylocation=file:///kennwort.txt zroot/en-varta
root@testtest:~ # zfs list zroot/varta zroot/en-varta
NAME             USED  AVAIL     REFER  MOUNTPOINT
zroot/en-varta   100M  11.8G      100M  /zroot/en-varta
zroot/varta      100M  11.8G      100M  /zroot/varta
root@testtest:~ # zfs list -t snapshot
NAME                       USED  AVAIL     REFER  MOUNTPOINT
zroot/en-varta@migration   112K      -      100M  -
zroot/varta@migration        0B      -      100M  -

Das ist schnell und einfach, oder? Natürlich liegt nun noch immer das Passphrase offen in einer Datei im root des Systems. Wir müssen nun also den Ort des Schlüssels auf prompt ändern:

root@testtest:~ # zfs get keylocation zroot/en-varta
NAME            PROPERTY     VALUE                 SOURCE
zroot/en-varta  keylocation  file:///kennwort.txt  local
root@testtest:~ # zfs set keylocation=prompt zroot/en-varta
root@testtest:~ # zfs get keylocation zroot/en-varta
NAME            PROPERTY     VALUE        SOURCE
zroot/en-varta  keylocation  prompt       local

Damit kann die Datei mit dem Passphrase gelöscht werden:

root@testtest:~ # rm /kennwort.txt

Ebenfalls kann nun auch das unverschlüsselte Dataset weg:

root@testtest:~ # zfs destroy -r zroot/varta

Wenn man nun möchte, kann man das neue Dataset natürlich an die gleiche Stelle mounten oder direkt komplett gleich dem alten benennen:

root@testtest:~ # zfs rename zroot/en-varta zroot/varta

Damit ist die Migration fertig und das Dataset ist verschlüsselt:

root@testtest:~ # zfs list zroot/varta
NAME          USED  AVAIL     REFER  MOUNTPOINT
zroot/varta   100M  11.9G      100M  /zroot/varta
root@testtest:~ # zfs get encryption,keylocation,keyformat zroot/varta
NAME         PROPERTY     VALUE        SOURCE
zroot/varta  encryption   aes-256-gcm  -
zroot/varta  keylocation  prompt       local
zroot/varta  keyformat    passphrase   -

Es sieht nun nach sehr viel aus, ist es aber nicht und es lässt sich sogar automatisieren.

Fragen? Dann fragen!

Linux Mint 20.1: ZFS Root Pool mit Verschlüsselung einrichten

Zu ZFS und warum man es haben will, muss ich hier sicher nicht mehr viel schreiben. Ebenfalls wird sich niemand mehr die Frage stellen, warum man seine Festplatte verschlüsseln möchte.

ABER wenn man nun Linux, ZFS und Verschlüsselung kombinieren möchte, dann gibt es etwas, worüber es sich zu schreiben lohnt. Wie man nun also sehr einfach unter sein Linux Mint >= 20.x einen native encryptet zfs root pool bekommt, darum geht es hier.

Linux ZFS Encryption enter password.

Linux Mint bringt seit Version 20 bereits alles mit um dieses ohne besonderen Aufwand zu erledigen. Natürlich ging es bereits schon früher, nur war es dann fast nur über den Weg möglich, die Festplatte inkl. Grub vollständig von Hand vor und während der Installation selbst fertig zu machen. Dieses ist… Sagen wir mal… „Für den erweiterten Anwender schon fast nicht zu machen“.

Zurück zu Linux Mint 20.x!

Wie erwähnt bringt diese Version alles Nötige mit, nur der Installer ist noch nicht ganz so weit und man muss ihm mit zwei Kleinigkeiten unter die Arme greifen. Einmal muss man die nötigen Pakete im Live-System nachinstallieren. Also einfach die gewünschte Version von Linux mit downloaden und davon booten. Ist man im Live-System angekommen, öffnen man ein Terminal und wirft die Installation der Pakete mit folgendem Befehl an:

sudo aptitude -y install libzfs2linux zfs-initramfs zfsutils-linux zfs-zed

Möchte man nun einfach nur sein Linux Mint auf einem ZFS Pool installieren, ist man schon fertig. Einfach den Installer starten und beim Punkt, auf welche Festplatte man sein neues System installieren möchte auf Advanced features… klicken und unten auf EXPERIMENTAL: Erase disk and use ZFS. Fertig ist!

Möchte man noch seinen zroot Pool verschlüsseln fehlt noch die zweite Kleinigkeit. Da der Installer den Wunsch und somit ebenfalls das Kennwort zur Verschlüsselung des ZFS Pools nicht abfragt, muss man es dem Installer mitgeben, bevor er mit seiner Arbeit startet. Dazu bleibt man im Terminal und editiert das Installerscript wie folgt:

sudo vi /usr/share/ubiquity/zsys-setup

Hier sucht man nun die Sektion, in welcher es ums Anlegen der ZFS Pools geht ?zpool create wäre eine gute Suche 😉

Hat man dieses gefunden (derzeit sollte es genau zwei Mal im Installerscript auftauchen) setzt man einfach vor das zpool create des rpools ein:

echo 'SUPER-SECURE' | 

Die Hochkomma bleiben dabei stehen und ihr ersetzt SUPER-SECURE durch euer gewünschtes Kennwort, was sich natürlich schon jeder gedacht hat. Damit wird dem zpool create rpool später im Installationsprozess euer Kennwort übergeben.

Fehlen nur noch die Optionen beim Erstellen des Pools, damit er ihn auch verschlüsselt. Dafür bitte folgendes vor die Zeile -O mountpoint=/ -R „${target}“ rpool „${partrpool}“ eintragen:

-O encryption=aes-256-gcm \
-O keylocation=prompt \
-O keyformat=passphrase \

Am Ende sieht der Ausschnitt also beispielhaft wie folgt aus:

echo 'Kennwort!' | zpool create -f \
        -o ashift=12 \
        -O compression=lz4 \
        -O acltype=posixacl \
        -O xattr=sa \
        -O relatime=on \
        -O normalization=formD \
        -O mountpoint=/ \
        -O canmount=off \
        -O dnodesize=auto \
        -O sync=disabled \
        -O encryption=aes-256-gcm \
        -O keylocation=prompt \
        -O keyformat=passphrase \
        -O mountpoint=/ -R "${target}" rpool "${partrpool}"

Das war es auch schon. Jetzt, wie gewohnt den Installer starten und schon wird man nach dem Reboot aufgefordert seinen ZFS Pool mit einem Kennwort zu entschlüsseln. Oh, geht natürlich so mit EFi und lagacy und überhaupt….

Ob alles so funktioniert hat, wie man es sich vorstellt, lässt sich direkt nach dem ersten Boot ins neue System prüfen. Einfach Terminal öffnen und mittels folgender Befehle prüfen, ob die Verschlüsselung aktiviert ist und sich auch sauber durch den Pool bis zu den Benutzerdaten weiter vererbt hat:

test@test-VirtualBox:~$ sudo zpool list
NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
bpool  1,38G  97,3M  1,28G        -         -     0%     6%  1.00x    ONLINE  -
rpool  26,5G  4,46G  22,0G        -         -     3%    16%  1.00x    ONLINE  -
test@test-VirtualBox:~$ sudo zpool get feature@encryption
NAME   PROPERTY            VALUE               SOURCE
bpool  feature@encryption  disabled            local
rpool  feature@encryption  active              local
test@test-VirtualBox:~$ sudo zfs get encryption rpool/USERDATA/test_9d9i92
NAME                        PROPERTY    VALUE        SOURCE
rpool/USERDATA/test_9d9i92  encryption  aes-256-gcm  -
test@test-VirtualBox:~$

Hier noch Bilder zum Klicken, das mögen ja viele.

Fragen? Dann fragen…

TLS-ECDHE mit AES-256-GCM-SHA384 einfach erklärt

TLS_AES_256_CGM_SHA384 oder TLS_ECDHE_ECDHE_WITH_AES_256_GCM_SHA384 liest man immer mal wieder, wenn man sich etwas mit Transportverschlüsselung beschäftigt. Was genau dieses bedeutet ist nicht immer ganz klar. Daher möchte ich einmal probieren es etwas aufzuschlüsseln.

Um dieses nachvollziehen zu können, müssen vorher noch die folgenden Begriffe geklärt werden:

  • Key exchange
    Damit ist der Schlüsselaustausch gemeint.
  • Certificate verification
    Hier geht es um das eigentliche Zertifikat vom Server.
  • Bulk encryption
    Die eigentliche Verschlüsselung welche am Ende genutzt wird um die Daten auf ihrem Weg zu verschlüsseln.
  • Hashing
    Die eingesetzten Prüfsummen um sicherstellen zu können, das alles „richtig“ ist.
Verschlüsselung-cipher

Ebenfalls muss man wissen, dass es seit TLSv1.3 einen Unterschied in der Schreibweise der cipher suite gibt. Bei <= TLSv1.2 tauchen in der cipher suite als erstes das Protokoll auf, dann der Algorithmus für den Schlüsselaustausch, nun die digitalen Signaturen des Serverzertifikates gefolgt vom „Rest“. Die Menge möglicher Kombinationen ist jetzt schon sehr hoch. Damit diese „Liste“ nicht in ihrer Länge explodiert hat man bei TLSv1.3 die beiden Punkte Key exchange und Certificate verification aus der Schreibweise entfernt.

Mit diesem Wissen kann man nun anfangen die beiden Zeichenkennten zu „zerlegen“.

TLS_ECDHE_ECDHE_WITH_AES_256_GCM_SHA384

  • TLS
    Nicht schwer, das eingesetzte Protokoll TLS (Transport Layer Security)
  • ECDHE
    Key exchange in diesem Fall ECDHE
  • ECDHE
    Certificate verification bei mir inzwischen ECDHE, sehr oft aber RSA
  • WITH_AES_256_GCM
    Bulk encryption also die eigentliche Verschlüsselung der Daten. In diesem Fall AES (Advanced Encryption Standard) mit der maximalen Länger von 256bit und GCM (Galois/Counter Mode).
  • SHA384
    Das eingesetzte Hashing SHA (Secure Hash Algorithm) in Version 2 mit einer Länge von 384bit.

TLS_AES_256_CGM_SHA384 schafft nun jeder allein, oder?

Sprechen wir noch kurz über den Key exchange. In diesem ist spezifiziert, wie sich Client und Server auf einen eigenen Schlüssel für ihre verschlüsselte Kommunikation einigen. Brauchbar sind dabei Kombinationen aus DHE (wenn sie >= 2048bit sind) und besser noch ECDHE, dabei stehe EC für elliptische Kurven DHE ist Diffie-Hellman. Diffie-Hellmann hat nämlich eine Möglichkeit aufgeführt, wie man für die Verschlüsselung einer Verbindung temporäre Schlüssel einsetzten kann. Denn es lassen sich auch verschlüsselte Verbindungen aufzeichnen. Natürlich kann man so noch immer nicht den Inhalt sehen.. Kommt man an den eingesetzten Schlüssel für die Kommunikation kann man diese damit entschlüsseln. Setzte man also auf einen temporären Schlüssel, gibt es diesen nur für eine gewisse Zeit und dann verschwindet er. Die Zeit, um an diesen Schlüssel zu kommen, ist daher extrem begrenzt und sorgt für eine zusätzliche Sicherheit. „Früher“ hat es gereicht sich einfach irgendwann/irgendwie den Schlüssel vom Server zu besorgen und man konnte mit diesem die Aufgezeichneten Verbindungen entschlüsseln. Bugs wie Heartbleed haben dieses noch vereinfacht. DHE minimiert also etwas das Risiko von Bugs und ergaunerten privat Keys vom Server. Man möchte für seine Verbindungen also nur DHE, besser noch ECDHE! Am besten bietet der Server nichts anders an, da sonst ggf. ein Angreifer versuchen könnte die Verbindung auf etwas „schlechteres“ herunter zu stufen, um so doch am Ende wieder an etwas kommen zu können.

Wenn wir dabei sind… Certificate verification. Nur eine verschlüsselte Verbindung alleine hilft ja nicht, wenn man sich mit dem falschen Server unterhält. Ich meine damit, dass ein Angreifer einfach dafür sorgt, dass wir nicht mit dem gewünschten Server sprechen, sondern mit seinem und dieser vielleicht einfach nur alle Daten durchreicht. Um dieses möglichst zu erschweren gibt es eine ganze Reihe verschiedener Möglichkeiten. Eine davon ist die Certificate verification. Der Server hat also ein Zertifikat, welches vielleicht noch von einer CA signiert wurde, dessen Prüfsumme im DNSsec geschützten DNS liegt, zu dem es HPKP (http Public Key Pinning) gibt oder oder… Dieses Zertifikat sollte daher ebenfalls so gebaut sein, dass man es nicht einfach „nachmachen“ kann. Daher sollte es >=2048bit RSA (asymmetrisches kryptographisches Verfahen) sein, besser noch 4096bit RSA. Hier sieht man schon ein „Problem“. Die Systeme „rechnen“ schneller und damit wird die Bitzahl erhört und die zu übertragenden Daten und das errechnen der Clients usw.. Insg. keine sehr schöne Lösung. ECDHE Zertifikate sind deutlich kleiner, damit schneller zu übertragen und zudem noch für den Client schneller zu prüfen.

Als Beispiel:
Ein Zertifikat mit elliptischen Kurven und einer Länge von 256bit ist grob vergleichbar mit einem RSA Zertifikat mit 3072bit. Wenn jemand daher auf elliptische Kurven setzt, sollten diese nicht kleiner als <=secp256r1 sein. secp224r1 liegt schon zu nahe an 1024bit RSA und fliegt bald weg. secp384r1 ist ganz vorne mit dabei, hat aktuell keinen besonderen Vorteil.

Bulk encryption, tjo die eingesetzte Verschlüsselung. Hier gibt es verschiedene Kombinationen, welche als „sicher“ gelten. Alle zu erklären sprengt sicher den Rahmen. April 2020 kann man sicher merken:

Kombinationen aus AES >=128bit mit GCM oder ChaCha20 mit Poly1305 sind ganz gut. OK ist im Moment noch AES >=128bit mit CBC. 3DES sollte man in keiner Kombination mehr nutzen, das fliegt bald aus der „Sicher“ Liste raus, so wie <= TLSv1.2. Von allen anderen Kombinationen sollte man tunlichst die Finger lassen!

Das Hashing bei der Bulk encryption (das Hashing für Key exchange und Certificate verification hängt am Serverzertifikat, unterliegt den gleichen Merkpunkten) sollte etwas um >= 256bit SHA 2 sein. Ein ganz guter Mittelweg ist hier SHA-384. SHA1 „geht“ wohl dabei ebenfalls noch. Ich würde davon und von allem anderen dennoch die Finger lassen. Wenn ihr irgendwo MD5 RC4 oder ähnliches seht, rennt weg!

Habe ich etwas vergesse, ist etwas falsch oder es gibt Fragen? Dann einfach E-Mail bitte!

Keine RSA-Zertifikate mehr: Was du jetzt wissen musst

….. naja, fast :-/

Wir sind alle in 2020 angekommen und so laaaannngggsssaaammmm könnte man von 4096 bit RSA Zertifikaten mal auf >= 256 bit EC Zertifikate wechseln, oder? Bringt mehr Sicherheit, die Schlüssel sind kleiner und so schneller gerechnet und alle gängigen Browser machen es ebenfalls schon ein paar Jahre.

Vor knapp 6 Monaten habe ich daher einen Satz neuer Schlüssel erstellt und diese schon mal in mein HPKP Header eingebunden, damit der Key-Rollover gut funktioniert. Heute habe ich zu den Schlüsseln Zertifikate gebaut, diese von einer CA signieren lassen und alles eingebunden.

Bei meinem nginx vollkommen schmerzfrei. Einfach die neuen Schlüssel hinterlegt und die Cipherliste von allem RSA-Zeug befreit:

ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256;

Restart vom nginx und zack, schon läuft alles!

Bei den Webseiten also überhaupt kein Problem. Etwas anders ist es bei E-Mail! Postfix macht es natürlich schon, ach LANGE.. Aber ein Microsoft Exchange 2016 in der (weiter weiter fertigstellen) Installation natürlich nicht. Wenn ich also von so einem System weiterhin E-Mails erhalten möchte (ja will ich und per RSA kann so ein System es auch in ~sicher~), muss ich weiterhin etwas auf RSA Basis anbieten.

Jetzt haben sich die Entwickler(innen) bei Postfix schon so etwas gedacht und bieten dieses in der Konfiguration an. Also RSA Keys/Zertifikate? Richtig… OK, das ist nichts besonders aber das es in Kombination mit ECD Keys/Zertifikaten möglich ist. Ach schaut einfach mal die Konfiguration:

smtpd_tls_eckey_file = /usr/local/etc/postfix/ec-postfix.key
smtpd_tls_eccert_file = /usr/local/etc/postfix/ec-postfix.pem
smtpd_tls_key_file = /usr/local/etc/postfix/postfix.key
smtpd_tls_cert_file = /usr/local/etc/postfix/postfix.pem

Ha, ist das nicht schön? smtpd_tls_eckey_ und smtpd_tls_key_?!? Der Server wirft jedem Client nun also zwei Serverzertifikate entgegen. Einmal EC und einmal RSA (ok man braucht also nun ebenfalls zwei Zertifikate).

Schaut mal:

➜  ~ testssl.sh -t smtp smtp.kernel-error.de:25
[....]
  Server Certificate #1
   Signature Algorithm          SHA256 with RSA
   Server key size              RSA 4096 bits
   Server key usage             Digital Signature, Key Encipherment
   Server extended key usage    TLS Web Server Authentication, TLS Web Client Authentication
   Serial / Fingerprints        4F7A9159AEED9414B7D542ED / SHA1 908FD237EF13A6048077082023C4CDE092F55F33
                                SHA256 74E3984BD5F9FAC26375DAEA6F0326229A0F42AC2EE53088A73DFD5F65107FA9
   Common Name (CN)             *.kernel-error.de 
   subjectAltName (SAN)         *.kernel-error.de kernel-error.de 
   Issuer                       AlphaSSL CA - SHA256 - G2 (GlobalSign nv-sa from BE)
   Trust (hostname)             Ok via SAN wildcard (same w/o SNI)
   Chain of trust               Ok   
   EV cert (experimental)       no 
   ETS/"eTLS", visibility info  not present
   Certificate Validity (UTC)   403 >= 60 days (2020-02-26 14:19 --> 2021-04-05 13:58)
   # of certificates provided   2
   Certificate Revocation List  http://crl2.alphassl.com/gs/gsalphasha2g2.crl
   OCSP URI                     http://ocsp2.globalsign.com/gsalphasha2g2
   OCSP stapling                not offered
   OCSP must staple extension   --
   DNS CAA RR (experimental)    available - please check for match with "Issuer" above
                                iodef=mailto:kernel-erro@kernel-error.de, issue=comodoca.com, issue=geotrust.com, issue=globalsign.com, issue=letsencrypt.org, issue=thawte.com
   Certificate Transparency     yes (certificate extension)

  Server Certificate #2
   Signature Algorithm          SHA256 with RSA
   Server key size              EC 256 bits
   Server key usage             Digital Signature, Key Agreement
   Server extended key usage    TLS Web Server Authentication, TLS Web Client Authentication
   Serial / Fingerprints        24E25E2F3D57B41671392F25 / SHA1 763EE6D52D3CF0237D9858F27EDF42EF4696B1E2
                                SHA256 9C4C0FCE32BA7E8AEAF17210B509D871D6B2EF237E0E887D7190F28F28011143
   Common Name (CN)             *.kernel-error.de 
   subjectAltName (SAN)         *.kernel-error.de kernel-error.de 
   Issuer                       AlphaSSL CA - SHA256 - G2 (GlobalSign nv-sa from BE)
   Trust (hostname)             Ok via SAN wildcard (same w/o SNI)
   Chain of trust               Ok   
   EV cert (experimental)       no 
   ETS/"eTLS", visibility info  not present
   Certificate Validity (UTC)   365 >= 60 days (2020-02-26 13:37 --> 2021-02-26 13:37)
   # of certificates provided   2
   Certificate Revocation List  http://crl2.alphassl.com/gs/gsalphasha2g2.crl
   OCSP URI                     http://ocsp2.globalsign.com/gsalphasha2g2
   OCSP stapling                not offered
   OCSP must staple extension   --
   DNS CAA RR (experimental)    available - please check for match with "Issuer" above
                                iodef=mailto:kernel-erro@kernel-error.de, issue=comodoca.com, issue=geotrust.com, issue=globalsign.com, issue=letsencrypt.org, issue=thawte.com
   Certificate Transparency     yes (certificate extension)
[....]

Jetzt kann noch ein 2016 Microsoft Exchangeserver einliefern und auch die „coolen Kinder“. Was mache ich wohl 2021? Exchange 2016 ignorieren?!?!


Kleines Update, da es Fragen gab..

Natürlich sollte man seine ciphers in einer sinnigen Reihenfolge für seinen Postifx konfigurieren. Kommen sie in der Reihe erst nach den RSA ciphern wird es natürlich fast nie benutzt *kopfschüttel*. Leute bitte kein copy & paste, mitdenken!

Ein Beispiel für die cipherliste wäre:

tls_high_cipherlist = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256

TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256 sind dabei für TLS1.3

ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256 sind für den gewünschten ECD-Key

ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256 sind dann für TLS 1.2 RSA Verbindungen.

Kommt nun ein Client/einliefernder Mailserver, dann wird dieser dank:

tls_preempt_cipherlist = yes

Die vom Server übermittelte cipherliste durchgehen und die erste für beide funktionierende Kombination benutzen.

RSA Verbindungen sehen dann so aus:

Mar  3 08:24:13 smtp postfix/smtpd[49650]: Anonymous TLS connection established from RSA-mailserver[1.2.3.4]: TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)

ECD Verbindungen so:

Mar  3 08:23:53 smtp postfix/smtpd[49650]: Anonymous TLS connection established from EDC-mailserver[5.6.7.8]: TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)

Einfach, oder?

TLS 1.3 für Postfix und Dovecot: So richtest du es ein

Sowohl mein Postfix als auch der Dovecot sprechen nun sauber TLS 1.3.

Wenn Postfix sowie Dovecot sauber gegen OpenSSL 1.1.1 gebaut sind fehlen nur zwei Configänderungen.

Dovecot spricht es meist sofort wenn man hier die minimale TLS Version ind der 10-ssl.conf:

ssl_min_protocol = TLSv1.1

Beim Postfix setzt man einfach die zu nutzenden TLS Versionen in der main.cf:

smtpd_tls_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtp_tls_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtpd_tls_mandatory_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtp_tls_mandatory_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1, !SSLv2, !SSLv3

Schon spricht Postfix TLS 1.3 mit anderen Server und beide Dienste sind in der Lage dieses mit Clients zu sprechen!

Test für smtp:

$ openssl s_client -starttls smtp -crlf -connect smtp.kernel-error.de:25
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3944 bytes and written 404 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

Test für imap:

$ openssl s_client -connect imap.kernel-error.de:993 -crlf
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3944 bytes and written 404 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

So sieht ein Logfile doch schon viel mehr nach 2019 aus, oder?

Feb 15 16:05:43 smtp postfix/smtp[7475]: Verified TLS connection established to mx1.freebsd.org[2610:1c1:1:606c::19:1]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256

Bei Fragen, einfach fragen 🙂

© 2025 -=Kernel-Error=-

Theme von Anders NorénHoch ↑