Datenhaufen zu IT und Elektronik.

Kategorie: Kernel-Error-Blog (Seite 1 von 48)

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.

PDS OSIcom-Office Box: Retro-PC mit JUMPtec & SUSE Linux

Vor etwas über 20 Jahren habe ich unter anderem mit OSIcom-office Boxen von PDS (Programm und Datenservice) gearbeitet. Dazu habe ich schon mal etwas geschrieben.

Picture of an PDS OSIcom-office Box

Zufällig bin ich dann in einem Onlineshop auf genau so eine OSIcom Box gestoßen, die dort zum Verkauf angeboten wurde. Der Preis lag deutlich über dem, was ich aus nostalgischen Gründen bereit wäre, dafür zu zahlen – aber ich habe einfach mal mein Glück versucht und per E-Mail ein Angebot unterbreitet. Und siehe da, der Verkäufer war einverstanden! Nun bin ich also Besitzer einer alten OSIcom-office Box. An dieser Stelle noch einmal vielen Dank an Wie-Tec für das Entgegenkommen.

Die Box basiert auf einem SBC (Single Board Computer) von JUMPtec. Das Modell scheint folgendes zu sein: 07029-0000-26-7. Im POST wird die BIOS-Version <LEU2R118> angezeigt. Hersteller: JUMPtec® Industrielle Computertechnik AG.

Verbaut sind ein Intel Pentium MMX 266 MHz, 256 MB RAM, eine 40 GB Festplatte, ein Diskettenlaufwerk, sowie eine Netzwerk- und ISDN-Karte. Der SBC steckt in einer ISA-Backplane. Das könnte sogar ein ziemlich guter Retro-DOS-Gaming-PC werden!

Spannenderweise war die Festplatte noch mit Daten gefüllt. Ob es sich dabei nur um eine Testinstallation oder echte Produktivdaten handelt, kann ich nicht bewerten. Überrascht hat mich das dennoch positiv, denn so konnte ich den kompletten Bootvorgang noch einmal genießen. Wobei – nicht nur ich:

Kernel 2.4.27 – man, ist das lange her! Grundlage ist ein altes SUSE Linux. Natürlich habe ich auch noch ein paar Bilder für euch angelegt.

Das BIOS konnte ich sichern, und zusammen mit den Bildern wird das sicher eine brauchbare Ergänzung für „The Retro Web“. Falls jemand von euch noch Handbücher oder ähnliches zur Hardware hat – ich würde mich sehr darüber freuen!

DALLAS DS80C400: Ethernet-Mikrocontroller neu entdeckt

Vor ziemlich genau 20 Jahren habe ich in einem Unternehmen gearbeitet, in dem Teile einer eigens entwickelten Lösung eine Zeit lang auf einem DALLAS DS80C400 basierten.

Der DALLAS DS80C400 ist ein hochintegrierter, netzwerkfähiger Mikrocontroller, der auf der Architektur des klassischen 8051 basiert. Entwickelt wurde er von Dallas Semiconductor (später Maxim Integrated) und war besonders für eingebettete Systeme geeignet, die eine Ethernet-Konnektivität benötigten.

Ja, klingt nicht weiter spannend, ich weiß – aber wir schreiben ja auch das Jahr 2025 und nicht 2005. Viele werden sich erinnern, dass der Raspberry Pi (Model B) im Februar 2012 veröffentlicht wurde. Arduino gab es zwar bereits seit 2005, aber ein einfach nutzbares TCP/IP-Netzwerk? Das war damals noch nicht so selbstverständlich. Der DS80C400 war mit seinem integrierten Netzwerkstack also ein ziemlich guter Mikrocontroller seiner Zeit.

Ich hatte ihn damals fertig montiert auf den Entwicklerboards von MAXIM in den Fingern. Das DSTINIM400 Embedded-Modul hatte 1 MB Flash, 1 MB SRAM, konnte 10/100 Mbit/s Ethernet, hatte zwei serielle RS232-Schnittstellen und noch ein paar andere nette Features. Dieses Modul steckte dann auf einem DSTINIS400, das – na ja, nennen wir es Hostboard – also eine Platine, die das DSTINIM400 aufnimmt und die verschiedenen Schnittstellen bereitstellt (Maxim TINI s400 Evaluation Board Socket).

Genau so ein Teil habe ich nun beim Aufräumen meiner „da muss ich noch mal nachschauen“-Elektronikkiste gefunden. Wirklich etwas damit tun wollte ich nicht, aber aus nostalgischen Gründen wollte ich es zumindest einmal booten sehen. Meine Erinnerung daran, wie das alles genau funktionierte, ist allerdings ziemlich verblasst. Irgendwas war da mit einer der beiden RS232-Schnittstellen und einem Terminalprogramm … also los.

Die mit Loader – Serial 0 beschriftete RS232-Schnittstelle war es, meine ich. Also habe ich mein Breakout-Board angeschlossen und ein bisschen herumgemessen. Sah soweit richtig aus – zumindest zeigte mein Oszilloskop beim Booten Aktivität auf den Datenleitungen. Die Pin-Belegung ist 1:1.

DSTINIm400 (DB9, DCE)PC (DB9, DTE)Funktion
2 (TXD)2 (RXD)Senden → Empfangen
3 (RXD)3 (TXD)Empfangen ← Senden
5 (GND)5 (GND)Gemeinsame Masse

Die Konfiguration der RS232 ist 9600 Baud, also 9,6 kbps. Dann noch 8N1:

  • 8 Datenbits (8 Bits pro Zeichen)
  • N Paritätsbit (keine Parität)
  • 1 Stoppbit

Da wirklich nur diese drei Leitungen benötigt werden, habe ich den Rest direkt beim Aufruf meiner Terminalemulation deaktiviert:

screen /dev/ttyUSB1 9600,cs8,-dtr,-rts

Hm … es passiert etwas, aber leider kommt nur Zeichensalat. Das spricht eher dafür, dass ich eine falsche Baudrate eingestellt habe. Also habe ich unterschiedliche Geschwindigkeiten ausprobiert – leider mit mehr oder weniger dem gleichen Ergebnis.

Vielleicht ist das auch der Grund, warum das Teil überhaupt in dieser Kiste gelandet ist?!

Ich wollte schon aufgeben, da fiel mir auf der Rückseite etwas auf: Ein MAX560CAI, ein Low-Dropout-Voltage-Regulator. In seiner direkten Nachbarschaft fehlen zwei Kondensatoren – C33 und C34. Klingt so, als wenn dort ein Keramik- oder Tantal-Kondensator für 10V und irgendwas zwischen 1 µF bis 10 µF hingehört. Und das könnte durchaus problematisch sein, denn einige Leitungen führen direkt bis zur RS232-Schnittstelle.

Um die richtigen Werte für die Kondensatoren zu finden, musste ich dann doch ein bisschen im Internet suchen. Dabei bin ich zumindest schon mal auf ein paar PDFs gestoßen, die ich hier mit euch teilen möchte.

DSTINIS-005-DSTINIS400.pdf
TINI_GUIDE.pdf
DSTINIm400.pdf
DSTINIm400EVKit.pdf

Im DSTINIS-005-DSTINIS400.pdf bin ich dann zum Glück fündig geworden:

  • C10, C31, C32, C34-C361 µF
  • C3310 nF

Passende SMD-Bauteile hatte ich zwar nicht (nicht gefunden), aber THT sollte für einen Test reichen. Für C33 habe ich einfach ebenfalls einen 1 µF-Kondensator genommen – das war mir passend genug für einen Versuch.

Noch ein Test mit 115200 Baud und … ha, er bootet! 😃

TINI Slush OS v1.17 – man, man, man … lange nicht gesehen!

Sicherheitslücken melden: Mein Umgang mit einem Vulnerability Report

Vulnerability Report

Vor Kurzem habe ich einen Vulnerability Report erhalten. Ich freue mich natürlich immer über solche Hinweise – sie helfen mir, zu wachsen und mein Setup zu verbessern, bevor jemand eine Schwachstelle tatsächlich ausnutzt.

Der Report lautet wie folgt:

Subject: Vulnerability Report: Vulnerable System Detected at openpgpkey.kernel-error.com

Hello Team,

I have identified a security issue in your system related to a vulnerability (CVE-2023-48795) in Terrapin.

Vulnerability Details:
- CVE Identifier: CVE-2023-48795
- Vulnerability Type: javascript
- Severity: medium
- Host: openpgpkey.kernel-error.com
- Affected Port: 22

Description: A security vulnerability (CVE-2023-48795) related to Terrapin has been detected in your system. This vulnerability could be exploited to compromise your system's security. Please see the details below for more information.

Impact: Impact:
1. Potential for Unauthorized Access: Attackers may exploit this vulnerability to gain unauthorized access.
2. System Compromise: Vulnerable systems could be compromised, leading to data loss or further attacks.
3. Increased Attack Surface: Exposing systems with this vulnerability increases the risk of exploitation.


Recommendation: Recommendation:
1. Apply patches for CVE-2023-48795: Ensure your systems are updated to address this vulnerability.
2. Conduct a Security Review: Regularly review and update your security policies and procedures.
3. Monitor for Suspicious Activity: Implement continuous monitoring to detect any potential exploitation attempts.
4. Restrict Access: Limit access to systems vulnerable to exploitation.


Best Regards,
Security Team

Ich war mir eigentlich sicher, dass ich Terrapin schon vor langer Zeit überall gepatcht und in den SSH-Konfigurationen berücksichtigt hatte.

Dann kam der Hinweis auf openpgpkey.kernel-error.com. Die Domain existiert als CNAME und gehört zur Web Key Directory (WKD), was im Groben dazu dient, öffentliche GPG-Keys möglichst automatisiert abrufen zu können. Wenn mir also jemand eine Mail schreiben möchte, aber meinen öffentlichen Key nicht hat, kann er diesen einfach über WKD beziehen. Ich habe das Ganze als CNAME zu wkd.keys.openpgp.org angelegt, weil dieser Keyserver zumindest eine E-Mail-Validierung beim Hochladen öffentlicher Schlüssel durchführt. Ich muss ja nicht jede Infrastruktur selbst betreiben.

Allerdings gehört der betroffene SSH-Server und das gesamte Zielsystem somit gar nicht zu meiner Infrastruktur – ich kann also selbst nichts tun.

Vulnerability Type: JavaScript

Das verstehe ich nicht ganz. Vermutlich hat der Finder einfach sein Standard-Template benutzt und nicht angepasst?! Aber zumindest wollte ich prüfen, ob seine Einschätzung zum SSH-Server überhaupt zutrifft:

# general
(gen) banner: SSH-2.0-OpenSSH_8.4p1 Debian-5+deb11u3
(gen) software: OpenSSH 8.4p1
(gen) compatibility: OpenSSH 7.4+, Dropbear SSH 2018.76+
(gen) compression: enabled (zlib@openssh.com)

# security
(cve) CVE-2021-41617                        -- (CVSSv2: 7.0) privilege escalation via supplemental groups
(cve) CVE-2016-20012                        -- (CVSSv2: 5.3) enumerate usernames via challenge response

# key exchange algorithms
(kex) curve25519-sha256                     -- [info] available since OpenSSH 7.4, Dropbear SSH 2018.76
                                            `- [info] default key exchange since OpenSSH 6.4
(kex) curve25519-sha256@libssh.org          -- [info] available since OpenSSH 6.4, Dropbear SSH 2013.62
                                            `- [info] default key exchange since OpenSSH 6.4
(kex) ecdh-sha2-nistp256                    -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
                                            `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp384                    -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
                                            `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp521                    -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
                                            `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) diffie-hellman-group-exchange-sha256 (3072-bit) -- [info] available since OpenSSH 4.4
                                                      `- [info] OpenSSH's GEX fallback mechanism was triggered during testing. Very old SSH clients will still be able to create connections using a 2048-bit modulus, though modern clients will use 3072. This can only be disabled by recompiling the code (see https://github.com/openssh/openssh-portable/blob/V_9_4/dh.c#L477).
(kex) diffie-hellman-group16-sha512         -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73
(kex) diffie-hellman-group18-sha512         -- [info] available since OpenSSH 7.3
(kex) diffie-hellman-group14-sha256         -- [warn] 2048-bit modulus only provides 112-bits of symmetric strength
                                            `- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73
(kex) kex-strict-s-v00@openssh.com          -- [info] pseudo-algorithm that denotes the peer supports a stricter key exchange method as a counter-measure to the Terrapin attack (CVE-2023-48795)

# host-key algorithms
(key) rsa-sha2-512 (2048-bit)               -- [warn] 2048-bit modulus only provides 112-bits of symmetric strength
                                            `- [info] available since OpenSSH 7.2
(key) rsa-sha2-256 (2048-bit)               -- [warn] 2048-bit modulus only provides 112-bits of symmetric strength
                                            `- [info] available since OpenSSH 7.2
(key) ssh-rsa (2048-bit)                    -- [fail] using broken SHA-1 hash algorithm
                                            `- [warn] 2048-bit modulus only provides 112-bits of symmetric strength
                                            `- [info] available since OpenSSH 2.5.0, Dropbear SSH 0.28
                                            `- [info] deprecated in OpenSSH 8.8: https://www.openssh.com/txt/release-8.8
(key) ecdsa-sha2-nistp256                   -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
                                            `- [warn] using weak random number generator could reveal the key
                                            `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(key) ssh-ed25519                           -- [info] available since OpenSSH 6.5

# encryption algorithms (ciphers)
(enc) chacha20-poly1305@openssh.com         -- [info] available since OpenSSH 6.5
                                            `- [info] default cipher since OpenSSH 6.9
(enc) aes128-ctr                            -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
(enc) aes192-ctr                            -- [info] available since OpenSSH 3.7
(enc) aes256-ctr                            -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
(enc) aes128-gcm@openssh.com                -- [info] available since OpenSSH 6.2
(enc) aes256-gcm@openssh.com                -- [info] available since OpenSSH 6.2

# message authentication code algorithms
(mac) umac-64-etm@openssh.com               -- [warn] using small 64-bit tag size
                                            `- [info] available since OpenSSH 6.2
(mac) umac-128-etm@openssh.com              -- [info] available since OpenSSH 6.2
(mac) hmac-sha2-256-etm@openssh.com         -- [info] available since OpenSSH 6.2
(mac) hmac-sha2-512-etm@openssh.com         -- [info] available since OpenSSH 6.2
(mac) hmac-sha1-etm@openssh.com             -- [fail] using broken SHA-1 hash algorithm
                                            `- [info] available since OpenSSH 6.2
(mac) umac-64@openssh.com                   -- [warn] using encrypt-and-MAC mode
                                            `- [warn] using small 64-bit tag size
                                            `- [info] available since OpenSSH 4.7
(mac) umac-128@openssh.com                  -- [warn] using encrypt-and-MAC mode
                                            `- [info] available since OpenSSH 6.2
(mac) hmac-sha2-256                         -- [warn] using encrypt-and-MAC mode
                                            `- [info] available since OpenSSH 5.9, Dropbear SSH 2013.56
(mac) hmac-sha2-512                         -- [warn] using encrypt-and-MAC mode
                                            `- [info] available since OpenSSH 5.9, Dropbear SSH 2013.56
(mac) hmac-sha1                             -- [fail] using broken SHA-1 hash algorithm
                                            `- [warn] using encrypt-and-MAC mode
                                            `- [info] available since OpenSSH 2.1.0, Dropbear SSH 0.28

# fingerprints
(fin) ssh-ed25519: SHA256:vwCCSg+OuRwAflHQs/+Y22UJ7p2lM57vbukGFt5AAaY
(fin) ssh-rsa: SHA256:o+WUM9bAmH2G5xMAsJfZRsmh8hvMoU4dx9gdmahLM+M

# algorithm recommendations (for OpenSSH 8.4)
(rec) -ecdh-sha2-nistp256                   -- kex algorithm to remove 
(rec) -ecdh-sha2-nistp384                   -- kex algorithm to remove 
(rec) -ecdh-sha2-nistp521                   -- kex algorithm to remove 
(rec) -ecdsa-sha2-nistp256                  -- key algorithm to remove 
(rec) -hmac-sha1                            -- mac algorithm to remove 
(rec) -hmac-sha1-etm@openssh.com            -- mac algorithm to remove 
(rec) -ssh-rsa                              -- key algorithm to remove 
(rec) !rsa-sha2-256                         -- key algorithm to change (increase modulus size to 3072 bits or larger) 
(rec) !rsa-sha2-512                         -- key algorithm to change (increase modulus size to 3072 bits or larger) 
(rec) -diffie-hellman-group14-sha256        -- kex algorithm to remove 
(rec) -hmac-sha2-256                        -- mac algorithm to remove 
(rec) -hmac-sha2-512                        -- mac algorithm to remove 
(rec) -umac-128@openssh.com                 -- mac algorithm to remove 
(rec) -umac-64-etm@openssh.com              -- mac algorithm to remove 
(rec) -umac-64@openssh.com                  -- mac algorithm to remove 

# additional info
(nfo) For hardening guides on common OSes, please see: <https://www.ssh-audit.com/hardening_guides.html>
(nfo) Be aware that, while this target properly supports the strict key exchange method (via the kex-strict-?-v00@openssh.com marker) needed to protect against the Terrapin vulnerability (CVE-2023-48795), all peers must also support this feature as well, otherwise the vulnerability will still be present.  The following algorithms would allow an unpatched peer to create vulnerable SSH channels with this target: chacha20-poly1305@openssh.com.  If any CBC ciphers are in this list, you may remove them while leaving the *-etm@openssh.com MACs in place; these MACs are fine while paired with non-CBC cipher types.

Joar, das sieht tatsächlich nicht ganz so optimal aus. Ein Hinweis darauf ist also nicht unberechtigt. Ich habe dem Finder also freundlich und dankbar geantwortet, aber auch darauf hingewiesen, dass das System nicht zu meiner Infrastruktur gehört. Zusätzlich habe ich ihm die relevanten Whois-Informationen zur IPv4 des angegebenen Hosts mitgeschickt.

Seine Antwort hat nicht lange auf sich warten lassen:

Thank you for your answer.

Let me know if you need anything else from myside

I hope this type of hard efforts deserves something reward

Hm… „hard efforts“. Ich will das jetzt nicht schlechtreden. Wäre der Hinweis im beruflichen Umfeld angekommen, hätte ich mich vielleicht sogar für eine Kleinigkeit stark gemacht. Aber da es hier nur um meine private Infrastruktur geht – und dann noch mit dem JavaScript-Hinweis und der Meldung zu einem fremden System – wirkt das Ganze doch etwas oberflächlich. Also habe ich ihn freundlich darauf hingewiesen.

Mein Tipp für den Umgang mit solchen Meldungen

Wenn euch mal eine solche Nachricht erreicht: Schnell und freundlich reagieren! Den Report ernst nehmen, bewerten und eine angemessene Rückmeldung geben. Die Mühe des Finders sollte wertgeschätzt werden. Zwei Wochen später mit „Anzeige ist raus!“ zu antworten, wäre der falsche Weg. Denn ganz ehrlich: Es ist für jemanden deutlich aufwendiger, sich die Mühe zu machen, eine Meldung zu schreiben, als einfach das Ganze in ein passendes Darknet-Forum zu posten und dort ein paar XMR oder Bitcoin einzusammeln.

Macht es den Leuten also möglichst einfach, euch zu kontaktieren. Eine security.txt oder klare Kontaktinformationen für eine Security-Mailbox helfen ungemein. Hauptsache, jemand kann seinen Report unkompliziert abgeben – und er wird von jemandem gelesen, der das Ganze bewerten kann.

Hier noch etwas zum klicken für die security.txt:
https://securitytxt.org/
https://de.wikipedia.org/wiki/Security.txt
https://www.allianz-fuer-cybersicherheit.de/Webs/ACS/DE/Home/_/infos/20240430_securitytxt.html

Meine SSH Konfiguration sieht von außen wie folgt aus:

# general
(gen) banner: SSH-2.0-OpenSSH_9.7 DemMeisterSeinRennAuto
(gen) software: OpenSSH 9.7
(gen) compatibility: OpenSSH 8.5+, Dropbear SSH 2018.76+
(gen) compression: enabled (zlib@openssh.com)

# key exchange algorithms
(kex) sntrup761x25519-sha512@openssh.com    -- [info] available since OpenSSH 8.5
(kex) curve25519-sha256                     -- [info] available since OpenSSH 7.4, Dropbear SSH 2018.76
                                            `- [info] default key exchange since OpenSSH 6.4
(kex) curve25519-sha256@libssh.org          -- [info] available since OpenSSH 6.4, Dropbear SSH 2013.62
                                            `- [info] default key exchange since OpenSSH 6.4
(kex) diffie-hellman-group16-sha512         -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73
(kex) diffie-hellman-group18-sha512         -- [info] available since OpenSSH 7.3
(kex) diffie-hellman-group-exchange-sha256 (3072-bit) -- [info] available since OpenSSH 4.4
                                                      `- [info] OpenSSH's GEX fallback mechanism was triggered during testing. Very old SSH clients will still be able to create connections using a 2048-bit modulus, though modern clients will use 3072. This can only be disabled by recompiling the code (see https://github.com/openssh/openssh-portable/blob/V_9_4/dh.c#L477).
(kex) ext-info-s                            -- [info] pseudo-algorithm that denotes the peer supports RFC8308 extensions
(kex) kex-strict-s-v00@openssh.com          -- [info] pseudo-algorithm that denotes the peer supports a stricter key exchange method as a counter-measure to the Terrapin attack (CVE-2023-48795)

# host-key algorithms
(key) ssh-ed25519                           -- [info] available since OpenSSH 6.5

# encryption algorithms (ciphers)
(enc) aes256-gcm@openssh.com                -- [info] available since OpenSSH 6.2
(enc) aes128-gcm@openssh.com                -- [info] available since OpenSSH 6.2
(enc) aes256-ctr                            -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
(enc) aes192-ctr                            -- [info] available since OpenSSH 3.7
(enc) aes128-ctr                            -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52

# message authentication code algorithms
(mac) hmac-sha2-256-etm@openssh.com         -- [info] available since OpenSSH 6.2
(mac) hmac-sha2-512-etm@openssh.com         -- [info] available since OpenSSH 6.2
(mac) umac-128-etm@openssh.com              -- [info] available since OpenSSH 6.2

# fingerprints
(fin) ssh-ed25519: SHA256:kPRXNCMRLiHfvJunW2CbW5H3NZmn3Wkx2KnHJXl1aLc

# algorithm recommendations (for OpenSSH 9.7)
(rec) +rsa-sha2-256                         -- key algorithm to append 
(rec) +rsa-sha2-512                         -- key algorithm to append 

Magenta SmartHome: Lösung für „Lüften“-Probleme auf Android

Seit inzwischen knapp 10 Jahren nutze ich das Magenta SmartHome-System. Eine der wirklich praktischen Funktionen ist „Lüften“.

Sobald ein Tür- oder Fensterkontakt signalisiert, dass er geöffnet ist, wird ein Signal an die Heizungsventile gesendet, damit diese schließen. Gerade mit Kindern im Haushalt ist das eine tolle Funktion, denn so heize ich nicht versehentlich durch ein offenes Fenster oder gleich die ganze Terrasse.

Diese Funktion findest du in der SmartHome-App unter: Mehr → Heizung → Overflow-Menü → Einstellungen → Sensoren konfigurieren. Dort kannst du für jeden Raum die Kontakte auswählen, die für die Funktion genutzt werden sollen.

Screenshot der Telekom Magenta SmartHome App auf einem Andriod. Gezeigt wird das Menü Sensoren konfigurieren, für die Funktion Lüften der Heizungssteuerung.

Vor knapp zwei Jahren ist mir in der Winterzeit aufgefallen, dass ein ausgetauschter Sensor zwar einwandfrei funktionierte, aber von der „Lüften“-Funktion komplett ignoriert wurde. Also habe ich im Menü nachgeschaut: Der Sensor wurde als nicht ausgewählt angezeigt (grauer Haken oben rechts auf der Kachel). Ich wählte ihn aus, bestätigte mit dem Haken, wechselte erneut ins Menü „Sensoren konfigurieren“ – und der Sensor war wieder nicht ausgewählt. Ein endloser Kreislauf.

Zuerst dachte ich, das Problem liegt vielleicht an meinem Smartphone. Doch auch auf dem Gerät meiner Frau zeigte sich derselbe Fehler. Also: App deinstallieren, neu installieren. Leider ohne Erfolg.

Daraufhin kontaktierte ich den Magenta SmartHome-Support und schilderte mein Problem. Die Antwort kam nach ein paar Tagen: Ein alter Sensor blockiere wohl die Funktion. Als Lösung schlug man vor, die komplette SmartHome-App von der Zentrale zu löschen und alles neu einzurichten. Das hätte bedeutet, dass meine gesamte Konfiguration, alle Regeln und Szenen verloren gehen – und ich jedes Gerät neu anlernen müsste.

Da ich zahlreiche Geräte im Einsatz habe, war das für mich keine Option. Also entschied ich mich, abzuwarten. Schließlich war ich nicht der Einzige mit diesem Problem, und früher oder später würde es sicher eine Lösung geben.

Nun ist wieder Winter, und das Problem besteht weiterhin. Also wandte ich mich erneut an den Support, in der Hoffnung auf eine bessere Lösung. Diesmal bekam ich folgende Antwort:

Das Problem ist hier, dass noch ein alter bereits abgelernter Tür-Fensterkontakt in der Lüften Einstellung fest hängt.
Erkennen kann man dies in der Android App bei der Auswahl der Tür-Fensterkontakte. Hier wird oben in der Titelzeile die Anzahl der ausgewählten Geräte angezeigt. 
Ist die Zahl hier höher, als die sichtbar ausgewählten Tür-Fensterkontakte, so ist der Kunde von diesem Problem betroffen.
Unter iOS wird die Anzahl der ausgewählten Tür-Fensterkontakte nicht angezeigt.

Update 08.01.2025: Es wird noch ein weiteres Magenta SmartHome App Release mit Fehlerbehebungen geben. Es ist geplant, dass der Fehler dort behoben wird.
 
Workaround 1: Da der Fehler nur in der Android App auftritt, kann man das Problem mit der iOS App lösen. Mit der iOS App reicht es einen Tür-Fensterkontakt abzuwählen und zu speichern.
Danach lassen sich die aktuell angelernten Tür-Fensterkontakte wieder wie gewohnt auswählen/abwählen und auch speichern. Auch in der Android App.
Sofern der Kunde also ein iOS Gerät hat, ist dieser Workaround dem Workaround 2 zu bevorzugen.

Workaround 2: Das Plugin vom 3rd Level löschen lassen. Hier muss der Kunde dann jedoch alle Einstellungen, die er in der App vorgenommen hat, wieder neu Einrichten.
Regeln, Szenen, Heizkurve,  Übersichten ... alles. Insofern fragt bitte den Kunden bevor ihr ein 3rd Level Ticket erstellt, ob er mit dieser Löschung einverstanden ist. 

Workaround 2 war für mich weiterhin keine Option. Aber Workaround 1 klang vielversprechend – ein iOS-Gerät hatte ich noch im Regal. Also installierte ich die App, ging ins Menü „Sensoren konfigurieren“, wählte die gewünschten Sensoren aus – und siehe da: Es funktionierte! Seitdem läuft die Funktion auch wieder einwandfrei unter Android.

Man stelle sich vor, ich hätte tatsächlich den aufwendigeren Workaround 2 gewählt, nur um später herauszufinden, dass ein einmaliger Abstecher in die iOS-App genügt hätte.

Vielleicht rettet diese Info ja jemanden vor unnötigem Aufwand 😉 Laut Support soll das Problem mit einem zukünftigen Update behoben werden.

GeoGuessr im Cyber-Sicherheitskontext: Wie IP-Kameras zum Risiko werden können

Die meisten von euch werden das Spiel GeoGuessr kennen. Man bekommt ein Google-Street-View-Bild gezeigt, kann sich vielleicht noch ein paar Meter hin- und herbewegen und muss dann auf einer Weltkarte einen Marker setzen, wo man meint, dass dieses Bild aufgenommen wurde. Wer dem Punkt am nächsten kommt, gewinnt.

Eine etwas abgewandelte Version begegnet mir immer mal wieder, wenn ich mich an einem Bug-Bounty-Programm beteilige oder einfach mit offenen Augen durchs Internet spaziere. Damit ist natürlich kein aktives Port-Scanning auf Netzblöcke oder Ähnliches gemeint.

Worum geht es genau?

In den letzten Jahren verbreiten sich immer mehr billige „China-Kameras“ bei Heimanwendern, aber auch bei Unternehmen. Dagegen spricht erst einmal nichts.

Was leider oft übersehen wird, sind die kleinen automatischen Helferlein, die die Einrichtung und den Betrieb einer solchen Kamera möglichst einfach machen sollen. UPnP (Universal Plug and Play) haben manche vielleicht schon mal im Zusammenhang mit Windows 95 oder USB gehört (ja, ich bin alt …). So etwas gibt es aber auch für Router und Firewalls, also für Netzwerke. Bei einer Fritzbox nennt sich das beispielsweise „Automatische Portfreigabe“.

Der eine oder andere ahnt jetzt sicher schon etwas: Es gibt IP-Kameras, die sich so – vielleicht sogar ohne das Wissen des Betreibers – selbst über das Internet erreichbar machen. Das betrifft nicht selten die komplette Weboberfläche. Mal ist diese kennwortgeschützt, mal nicht.

Sehr oft findet sich auch nur der RTSP-Port (Real Time Streaming Protocol) offen im Internet. Per RTSP werfen solche Kameras oft einen einfachen Videostream aus, der die Anbindung an zentrale Videoüberwachungssysteme erlaubt. Auch RTSP-Streams lassen sich mit einer Anmeldung schützen, was aber scheinbar in der Regel werkseitig deaktiviert ist.

Wenn dieser Port offen ist, könnte man sich einfach per ffplay einen solchen Stream anschauen:

ffplay rtsp://1.2.3.4/11

Wenn man sich nicht sicher ist, wie die korrekte RTSP-URL für die jeweilige IP-Kamera lautet, kann nmap zusammen mit dem Script rtsp-url-brute helfen:

nmap --script rtsp-url-brute -p 554 1.2.3.4

Die rechtliche Lage

Nun kann es natürlich rechtlich schwierig sein, bei einer fremden IP-Adresse nach dem offenen Port 554/TCP zu suchen, dort per nmap nach einer nutzbaren RTSP-URL zu scannen und sich den Stream dann live per ffplay, nmap oder vlc anzuschauen. Schließlich hat man nicht das Einverständnis des Betreibers.

Screenshot of shodan search engine, filtering for RTSP Streams.

Natürlich hält das wohl weniger Menschen ab, die ohnehin Schlechtes im Sinn haben. Ebenfalls gibt es verschiedene Dienste, die 24/7 nichts anderes tun. Ein Beispiel ist hier vielleicht shodan.io – dort lässt sich direkt nach solchen Vorschaubildern filtern, ohne dass man selbst eine Verbindung zu betroffenen IPs aufnehmen muss.

Warum ist das alles überhaupt problematisch?

Hat ein Angreifer Böses im Sinn, ist ein Zugriff auf die Überwachungskamera sehr hilfreich. Man kommt so möglicherweise an Insiderinformationen, findet heraus, wo wertvolle Dinge gelagert werden, wann und wie die Öffnungszeiten sind oder sogar mögliche Zugangscodes und Kennwörter. Natürlich auch, welche Kunden sich zu welcher Zeit dort aufhalten usw.

Denkt man an eine Arztpraxis, kann das schnell eine echte Datenschutzkatastrophe werden. Wenn die Kamera im Wohnzimmer oder Schlafzimmer einer Wohnung steht, führt das ebenfalls schnell zu ungewollten Einblicken.

Wenn man einmal außer Acht lässt, dass niemand gerne ohne sein Wissen per Livestream im Internet zu sehen ist, halte ich das Thema Datenschutz für eines der größten Risiken.

In der Vergangenheit sind mir bereits Beispiele begegnet, die das Problem verdeutlichen: Arztpraxen mit Kamerablick von hinten auf die Anmeldung – inklusive direktem Blick auf Patienten, Monitore mit Patientendaten oder Vertragsabschlüsse bei Mobilfunkanbietern. Auch Überwachungskameras in DHL-Filialen, die Bild und Ton in Zoom und 4K aufzeichnen, habe ich gesehen.

Für private Betreiber kann es ebenfalls schnell zu einem Datenschutzproblem werden. Nicht jeder achtet beim eingestellten Bildausschnitt der Kamera darauf, die Vorgaben des Datenschutzes einzuhalten. So werden oft mehr öffentliche Bereiche oder sogar Nachbargrundstücke gefilmt, als zulässig ist.

Wenn diese Daten dann auch noch ohne Schutz und Hürden in die Hände Dritter geraten, wird es heikel. Hier sollte besser jemand mit rechtlichem Hintergrund eine Einschätzung abgeben. Für mich klingt das alles jedenfalls ziemlich unschön.

Was kann man tun?

Eine Abuse-Mail an den jeweiligen ISP (Internet Service Provider) schicken, mit der Bitte, ihre Kunden zu informieren? Kann man machen. Bei kleineren ISPs klappt das oft sogar, und die Betreiber werden informiert. Spricht man aber über einen großen ISP wie die Telekom, verschwinden einzelne Abuse-Mails gefühlt einfach im Nichts.

Sonst jemanden zu finden, der ein Interesse daran hat, den meist unwissenden Betreiber zu informieren, ist nahezu unmöglich. Weder unsere Behörden noch das BSI interessieren sich dafür. Möchte man also den Betreiber darauf hinweisen, bleibt realistisch nur die Möglichkeit, ihn selbst zu kontaktieren.

GeoGuessr in der Praxis

Jetzt sind wir beim Thema GeoGuessr: Man hat also nur das Bild der Kamera, die IP-Adresse mit einer recht groben und nicht immer stimmigen Geolokalisierung und vielleicht noch ein paar weitere Rahmeninfos oder Dienste auf dieser IP-Adresse. Hin und wieder macht es mir daher sogar Spaß, den eigentlichen Betreiber ausfindig zu machen und ihm per E-Mail oder telefonisch kurz auf diesen möglichen Missstand hinzuweisen.

Wenn du das also gerade liest, weil ich dich darauf hingewiesen habe, weißt du jetzt, warum 😀

Natürlich trifft man oft auf Unverständnis – oder das klassisch deutsche „Anzeige ist raus!“ begegnet einem immer mal wieder. Es bietet also auch eine gute Möglichkeit, die eigenen Kommunikationsskills zu erweitern.

Milchkühlschrank selber bauen?: Warum Reparieren sich lohnt !

Heute möchte ich euch eine kleine Geschichte zu meinem Milchkühlschrank erzählen. Ob das spannend wird? Na, da bin ich mir noch nicht so sicher.

In meiner Küche steht so ein Kaffeevollautomat – einfach wegen lecker Kaffee und so. Dieser ist, bei angeschlossener Milch, auch in der Lage, die gängigen Milchkaffeegetränke (nennt man das so?) auf Knopfdruck zuzubereiten. Also alles top. Nun trinke ich, vor allem wenn ich im Homeoffice sitze, schon mal einen Kaffee mehr. Da räume ich natürlich nicht für jeden Kaffee die Milch raus und wieder rein. Damit die Milch mehr als einen halben Tag überlebt, braucht sie etwas Kühlung. Genau an dieser Stelle kommt ein Milchkühlschrank ins Spiel.

In der Regel basieren solche kleinen Kühlschränke oder Kühlboxen auf einem einfachen thermoelektrischen Kühler namens Peltierelement. Ein solches Peltier-Modul funktioniert recht simpel. Meistens ist es ein kleines, flaches Quadrat mit zwei Leitungen. Schließt man die passende Stromversorgung an, wird eine der beiden Seiten warm und die andere kalt. Das Modul sorgt also dafür, dass es eine Temperaturdifferenz zwischen beiden Seiten gibt.

Sagen wir einfach mal, das Modul erzeugt immer eine Temperaturdifferenz von 30°C. Bei einer Raumtemperatur von 20°C wäre die eine Seite also bei 20°C und die andere bei -10°C. Gut, das ist nur die halbe Wahrheit, denn die heiße Seite wird im Betrieb wärmer, weil dort zwei Wärmequellen zusammenkommen:

Wärmeübertragung von der kalten Seite (Peltier-Effekt):
Der Peltier-Effekt transportiert Wärme von der kalten zur heißen Seite, wenn ein Strom durch das Modul fließt. Diese transportierte Wärme wird an der heißen Seite freigesetzt.

Joulesche Verlustwärme (Widerstandserwärmung):
Beim Fließen des elektrischen Stroms durch die Halbleiterelemente des Peltier-Moduls entsteht aufgrund des elektrischen Widerstands zusätzliche Wärme (Joule-Effekt). Diese Wärme erhöht ebenfalls die Temperatur der heißen Seite.

Kurz gesagt: Man muss die heiße Seite kühlen, damit die kalte Seite auch wirklich kalt wird. Diese wird allerdings nicht unendlich kalt, da wir nur einen Temperaturunterschied erzeugen können. Die Kühlung der heißen Seite ist also sehr wichtig. Dieses Wissen wird später noch hilfreich sein, also bitte kurz merken.

Zurück zum Milchkühlschrank. Wie funktioniert dieser nun? Um das besser erklären zu können, habe ich euch eine kleine Zeichnung angefertigt:

Schematische Darstellung, der Funktion eins Peltier Milchkühlers.

1 Schaumstoffdämmung, 2 Kühlkörper, 3 Befestigungsschrauben, 4 Peltier Modul, 5 Aluminiumblock

Die dicke schwarze Linie an der Innenseite der Schaumstoffdämmung stellt eine Metallplatte dar, die die Innenseite des Kühlschranks bildet. Diese ist mit etwas Wärmeleitpaste (für bessere Temperaturübertragung) mit dem Aluminiumblock verbunden. Im Aluminiumblock befinden sich Temperaturfühler, die dafür sorgen, dass das Peltier-Modul bei der gewünschten Temperatur abgeschaltet wird. Die kalte Seite des Moduls ist ebenfalls mit Wärmeleitpaste am Aluminiumblock befestigt, während die heiße Seite mit einem großen Kühlkörper verbunden ist. Dieser Kühlkörper vergrößert die Oberfläche der heißen Seite, sodass die Wärme besser an die Umgebungsluft abgegeben werden kann. Meist ist zusätzlich ein kleiner Lüfter verbaut, der aktiv Luft zuführt.

Mit diesem Wissen können wir nun alle selbst einen Milchkühlschrank oder eine kleine Kühlbox bauen. Ein oft verwendetes Peltier-Modul ist das TEC1-12706, das man im Doppelpack für ca. 10 € bekommt. Ein einfacher PC-Lüfter kostet etwa 10 €. Für rund 50 € kann man sich so ein Ding zusammenbauen.

Warum ist das wichtig? Nun, weil die Dinger für ca. 150 € verkauft werden. Was auch der Grund ist, warum ich mir nicht einfach einen gekauft habe. Denn, mal ehrlich: Wenn ich das für 50 € bauen kann, dann kostet es in der Massenproduktion in China noch weniger. Ja, ich weiß, ich kaufe ja nicht nur das Gerät, sondern auch die Bequemlichkeit – meine Milch bleibt länger frisch, und ich muss mich nicht kümmern. Aber so einfach ist das für mich nicht zu rechtfertigen. Es widerstrebt mir einfach.

Einen gebrauchten zu kaufen, schien mir da eine Option. Was soll ich sagen? Die Technik, die in solchen Geräten verbaut ist, ist oft billig und nicht auf Langlebigkeit ausgelegt. Von den Geräten, die ich bisher in der Hand hatte, hat keines länger als drei Jahre gehalten. Selbst gebraucht werden sie noch für rund 100 € angeboten. Das ist für mich einfach nicht verhältnismäßig.

Jetzt stand bei meinem Arbeitgeber plötzlich ein defekter Milchkühlschrank beim Elektroschrott. Das kam für mich überraschend. Natürlich habe ich nachgefragt, was mit dem Gerät los ist und ob es okay wäre, wenn ich es „entsorge“. Es war kein Problem, und so hatte ich einen neuen alten, kaputten Milchkühlschrank.

Und was hatte das Ding? Nichts Besonderes. Der Lüfter war gestorben, und die passive Kühlung reichte nicht aus, um das Innere des Kühlschranks ausreichend zu kühlen. Verbaut war ein einfacher 80×80 mm 12V PC-Lüfter. Den hatte ich noch in meiner Ersatzteilkiste. Also: Lüfter getauscht, und zack – schon funktionierte der Kühlschrank wieder. Zumindest bis zum Sommer.

Als die Temperaturen stiegen, wurde es im Kühlschrank nicht mehr richtig kühl, obwohl Lüfter und Peltierelement alles gaben. Ich habe das Gerät wieder aufgeschraubt, weil ich vermutete, dass die Wärmeleitpaste inzwischen hart und trocken war und ausgetauscht werden musste. Der Milchkühlschrank war inzwischen vier, knapp fünf Jahre alt – da kann das schon mal passieren.

War es die Wärmeleitpaste? Ja und nein. Die Paste war zwar trocken, aber das allein war nicht das Problem. Wenn ihr euch meine Zeichnung anschaut, sind euch vielleicht die Befestigungsschrauben (3) aufgefallen. Diese Schrauben sind aus Metall und verbinden den kalten Aluminiumblock direkt mit dem Kühlkörper – also eine klassische thermische Brücke. Das heißt: Ein Teil der Kälte wird direkt wieder in Wärme umgewandelt, weil Metall die Wärme gut leitet.

Das ist … naja, sagen wir mal suboptimal. Es funktioniert irgendwie, aber effizient ist das nicht. Ich habe die Löcher im Kühlkörper daher aufgebohrt und mit meinem 3D-Drucker Kunststoffbuchsen für die Schrauben hergestellt. Diese habe ich zusätzlich mit kleinen Federn versehen, die thermische Brücke ist so unterbrochen und die Felder drücken alles noch zusammen, selbst wenn sich das Aluminium durch die unterschiedlichen Temperaturen ausdehnt bzw. zusammen zieht. Danach war der Kühlschrank deutlich effizienter und verbrauchte spürbar weniger Energie. Warum der Hersteller das nicht von Anfang an so gemacht hat? Tja, irgendwie habe ich nur das Wort „Gewinnmaximierung“ im Kopf.

Das verbaute Netzteil war ebenfalls nur gerade so passend für die benötigte Leistung. Das ist okay, aber wenn ein Netzteil immer bei 90 bis 100 % Belastung arbeitet, gibt es irgendwann auf. Es funktionierte zwar noch, aber die Messwerte waren nicht optimal, und man konnte ihm die jahrelange Arbeit ansehen. Ich hatte noch ein HOUHUI-1206 im Regal – ein 12V 6A Gleichstromnetzteil, das ich irgendwann mal bei einem Gerät dabei hatte. Damals wollte ich es nicht einsetzen, weil es so billig aussah. Also lag es herum.

Hätte ich doch mal auf mein früheres Ich gehört! Denn sechs Monate später war der Kühlschrank wieder warm, und die LED am Netzteil war aus. Das Chinanetzteil hatte den Geist aufgegeben.

So langsam bröckelte der WAF (Woman Acceptance Factor). Ich sah mich schon einen neuen Milchkühler kaufen. Also habe ich das Netzteil aufgeschraubt und mal reingeschaut. Überraschung: Die Elektrolytkondensatoren (Elkos) waren aufgebläht – ein klassischer Fehler. Ich habe die Elkos getauscht, und schon funktionierte alles wieder.

Natürlich habe ich den Strombedarf des Kühlschranks gemessen, um sicherzugehen, dass das Netzteil nicht ständig an seiner Leistungsgrenze arbeitet. Ich bin nicht an die Grenze von 6A gekommen, aber trotzdem behalte ich das im Auge. Denn: 12V und 6A bedeuten 72 Watt. Wenn der kleine Milchkühlschrank 24/7 mit 70 Watt läuft, dann ist das auf Dauer auch zu teuer.

So viel also zu meiner Geschichte des Milchkühlschranks. Ob ich am Ende einen neuen kaufe? Vielleicht. Aber bis dahin läuft mein reparierter Milchkühlschrank wieder.

Dual Boot mit Linux und Windows: BitLocker für die Systemplatte auf Passwort umstellen

Die Feiertage sind da, und ich hatte tatsächlich etwas Zeit zum Zocken. Früher hatte ich dafür einen eigenen Rechner, heute reicht ein Dual Boot. Gearbeitet wird unter Linux, gezockt unter Windows. Dafür habe ich mein Windows auf einer gesonderten SSD installiert. Natürlich ist diese ebenfalls verschlüsselt, in diesem Fall mit BitLocker.

Illustration eines Dual-Boot-Systems mit Linux und Windows, dargestellt durch die Logos beider Betriebssysteme. Die Windows-Seite zeigt ein BitLocker-Schloss-Symbol, das auf die Verschlüsselung der Systemplatte hinweist.

Warum erzähle ich das? Na, weil die SSD irgendwann aufgegeben hat und ich mein Windows neu installieren darf. Ein Backup spare ich mir, da es eh nur zum Zocken ist.

Windows 11 war „schnell“ wieder installiert. Dann noch alle Treiber usw. – Gott, ist das noch immer alles aufwendig… Wie auch immer: Windows 11 und die Games sind drauf. Los geht’s!

Nun fragt mich mein BitLocker bei jedem Start der Betriebssystemfestplatte nach dem BitLocker-Wiederherstellungsschlüssel, wenn ich vorher in meinem Linux war. Da zuckt so eine Erinnerung durch mein Hirn: Das gleiche hatte ich schon mal, am gleichen Rechner. Wie hatte ich das damals gelöst? Ich habe nichts darüber geschrieben, also ist es einfach weg. Diesen Fehler mache ich nicht noch mal. Also liest du gerade etwas darüber. 😄

Der Ausgangspunkt: Ein Windows 11 Pro, installiert auf einer SSD, inkl. BitLocker-Verschlüsselung und TPM mit PIN. Warum PIN? Ich fühle mich einfach besser, wenn es noch eine manuelle Hürde zur Entschlüsselung gibt; Ist auch egal, soll ja nun weg.

Terminal als Administrator ausführen und dann:

C:\Windows\System32> manage-bde -status
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.

Datenträgervolumes, die mit BitLocker-Laufwerkverschlüsselung
geschützt werden können:
Volume "C:" [System]
[Betriebssystemvolume]

    Größe:                        465,00 GB
    BitLocker-Version:            2.0
    Konvertierungsstatus:         Nur verwendeter Speicherplatz ist verschlüsselt
    Verschlüsselt (Prozent):      100,0 %
    Verschlüsselungsmethode:      XTS-AES 128
    Schutzstatus:                 Der Schutz ist aktiviert.
    Sperrungsstatus:              Entsperrt
    ID-Feld:                      Unbekannt
    Schlüsselschutzvorrichtungen:
        Numerisches Kennwort
        TPM und PIN
        TPM
C:\Windows\System32>

Schlüsselschutzvorrichtungen sind also numerisches Kennwort, TPM und PIN, sowie TPM. Was fehlt? Richtig, das Password. Da ich nur das Password möchte, kann im Grunde alles weg. Damit Windows 11 mir erlaubt, TPM von meinem Betriebssystemvolume zu entfernen, muss ich vorher noch eine Gruppenrichtlinie anpassen.

Dafür einfach die Tastenkombination Win + S drücken und nach Gruppenrichtlinie bearbeiten suchen.

Editor für lokale Gruppenrichtlinien mit geöffneter Einstellung 'Zusätzliche Authentifizierung beim Start anfordern' unter 'Computerkonfiguration > Administrative Vorlagen > BitLocker-Laufwerkverschlüsselung > Betriebssystemlaufwerke'. Die Option ist aktiviert, um die BitLocker-Verschlüsselung ohne TPM zu ermöglichen.
Detailansicht der Gruppenrichtlinieneinstellung 'Zusätzliche Authentifizierung beim Start anfordern'. Die Option 'BitLocker ohne kompatibles TPM zulassen' ist aktiviert, und die Konfiguration für TPM-Start, Systemstartschlüssel und PIN wird angezeigt. Die Beschreibung auf der rechten Seite erläutert die Auswirkungen der Richtlinie.

Dann zu:
ComputerkonfigurationAdministrative VorlagenBitLocker-LaufwerkverschlüsselungBetriebssystemlaufwerkeZusätzliche Authentifizierung beim Start anfordern.

Hier die Einstellung so ändern, dass der Haken bei „BitLocker ohne kompatibles TPM zulassen“ gesetzt ist.

Im Anschluss sicherstellen, dass die neue Gruppenrichtlinie auch angewendet wird. Dazu im Administrator-Terminal einfach ein kurzes:

PS C:\WINDOWS\system32> gpupdate /force
Die Richtlinie wird aktualisiert...

Die Aktualisierung der Computerrichtlinie wurde erfolgreich abgeschlossen.
Die Aktualisierung der Benutzerrichtlinie wurde erfolgreich abgeschlossen.

PS C:\WINDOWS\system32>

So, jetzt wird’s spannend. Erstmal alle Schlüsselschutzvorrichtungen deaktivieren, dann löschen, die neue Schlüsselschutzvorrichtung Password hinzufügen und alles wieder aktivieren. Das Ganze natürlich im Administrator-Terminal. Ich starte damit, alle Schlüsselschutzvorrichtungen zu deaktivieren:

C:\Windows\System32>manage-bde -protectors -disable C:
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.

Die Schlüsselschutzvorrichtungen für Volume "C:" sind deaktiviert.

Als Nächstes schaue ich nach, welche Schlüsselschutzvorrichtungen auf meinem Betriebssystemvolume eingerichtet sind.

C:\Windows\System32>manage-bde -protectors -get C:
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.

Volume "C:" [System]
Alle Schlüsselschutzvorrichtungen

    Numerisches Kennwort:
      ID: {AF6C0AAD-B337-4519-8D66-C06386994D97}
      Kennwort:
        673101-147301-650001-335379-291368-420618-438350-305327
      Sicherungstyp:
        In Datei gespeichert

    TPM und PIN:
      ID: {D5F87162-5556-4C27-82F9-25B389DBAF1B}
      PCR-Validierungsprofil:
        0, 2, 4, 11

    TPM:
      ID: {CA1BF147-2C40-4934-9161-660FBB44BA2C}
      PCR-Validierungsprofil:
        0, 2, 4, 11

Jetzt lösche ich alle Schlüsselschutzvorrichtungen anhand ihrer IDs:

C:\Windows\System32>manage-bde -protectors -delete C: -id {D5F87162-5556-4C27-82F9-25B389DBAF1B}
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.

Volume "C:" [System]
Schlüsselschutzvorrichtung mit ID {D5F87162-5556-4C27-82F9-25B389DBAF1B}

    TPM und PIN:
      ID: {D5F87162-5556-4C27-82F9-25B389DBAF1B}
      PCR-Validierungsprofil:
        0, 2, 4, 11

Die Schlüsselschutzvorrichtung mit der ID "{D5F87162-5556-4C27-82F9-25B389DBAF1B}" wurde gelöscht.

C:\Windows\System32>manage-bde -protectors -delete C: -id {CA1BF147-2C40-4934-9161-660FBB44BA2C}
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.

Volume "C:" [System]
Schlüsselschutzvorrichtung mit ID {CA1BF147-2C40-4934-9161-660FBB44BA2C}

    TPM:
      ID: {CA1BF147-2C40-4934-9161-660FBB44BA2C}
      PCR-Validierungsprofil:
        0, 2, 4, 11

Die Schlüsselschutzvorrichtung mit der ID "{CA1BF147-2C40-4934-9161-660FBB44BA2C}" wurde gelöscht.

C:\Windows\System32>manage-bde -protectors -delete C: -id {AF6C0AAD-B337-4519-8D66-C06386994D97}
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.

Volume "C:" [System]
Schlüsselschutzvorrichtung mit ID {AF6C0AAD-B337-4519-8D66-C06386994D97}

    Numerisches Kennwort:
      ID: {AF6C0AAD-B337-4519-8D66-C06386994D97}
      Kennwort:
        673101-147301-650001-335379-291368-420618-438350-305327
      Sicherungstyp:
        In Datei gespeichert

Die Schlüsselschutzvorrichtung mit der ID "{AF6C0AAD-B337-4519-8D66-C06386994D97}" wurde gelöscht.

Wenn ich jetzt noch einmal kontrolliere, welche Schlüsselschutzvorrichtungen ich habe, sollten dort keine mehr stehen.

C:\Windows\System32>manage-bde -protectors -get C:
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.

Volume "C:" [System]
Alle Schlüsselschutzvorrichtungen

FEHLER: Es wurden keine Schlüsselschutzvorrichtungen gefunden.

Damit kann ich jetzt meine neue, gewünschte Schlüsselschutzvorrichtung Passwort hinzufügen.

C:\Windows\System32>manage-bde -protectors -add C: -password
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.

Geben Sie das Kennwort ein, das zum Schützen des Volumes verwendet werden soll:

Bestätigen Sie das Kennwort durch erneute Eingabe:

Hinzugefügte Schlüsselschutzvorrichtungen:

    Kennwort:
      ID: {4D141862-4C75-4321-AA6D-8BABB89C601C}

Bleibt nur noch, diese auch zu aktivieren.

C:\Windows\System32>manage-bde -protectors -enable C:
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.

Die Schlüsselschutzvorrichtungen für Volume "C:" sind aktiviert.

Wenn ich jetzt den BitLocker-Status prüfe, ist alles aktiv, und es gibt nur noch die Schlüsselschutzvorrichtung Kennwort / Password!

C:\Windows\System32>manage-bde -status
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.

Datenträgervolumes, die mit BitLocker-Laufwerkverschlüsselung
geschützt werden können:
Volume "C:" [System]
[Betriebssystemvolume]

    Größe:                        465,00 GB
    BitLocker-Version:            2.0
    Konvertierungsstatus:         Nur verwendeter Speicherplatz ist verschlüsselt
    Verschlüsselt (Prozent):      100,0 %
    Verschlüsselungsmethode:      XTS-AES 128
    Schutzstatus:                 Der Schutz ist aktiviert.
    Sperrungsstatus:              Entsperrt
    ID-Feld:                      Unbekannt
    Schlüsselschutzvorrichtungen:
        Kennwort

Starte ich meinen Computer und wähle im Grub Windows aus, werde ich danach nach meinem BitLocker-Kennwort gefragt, und das System fährt sauber hoch.

Fragen? Dann fragen 🙂

Lötdampfabsaugung aus Resten: DIY-Projekt für Bastler

Heute mal etwas ganz Einfaches… Beim Löten entstehen Dämpfe, die man besser nicht durch den „Lungenfilter“ aus der Luft ziehen sollte.

3D-gedruckte Lötdampfabsaugung

Hier kommen Lötdampfabsaugung ins Spiel. Es gibt kleine, einfache Modelle für etwa 50 €, die wie ein kleiner Tischventilator in der Nähe stehen, die Dämpfe absaugen und meist durch einen Aktivkohlefilter leiten. Allerdings stehen mir diese Geräte immer im Weg, und die Lüfter sind oft so schwach, dass trotzdem noch ein großer Teil der Dämpfe zu mir gelangt.

Dann gibt es noch Absaugungen mit mehr oder weniger flexiblem Schlauch. Auch hier erfolgt die Filterung ähnlich, aber diese Modelle kosten dann schnell ein paar Hundert Euro.

Da bei Projekten öfter mal Reste übrig bleiben, liegen in meinem Keller eigentlich schon alle Einzelteile für eine selbstgebaute Lötdampfabsaugung bereit. Man müsste sie nur noch zusammenbauen.

Ich habe noch einen 100-mm-Lüftungsschlauch aus Aluminium, der einigermaßen flexibel ist, einen 120-mm-12V-Lüfter, der für ordentlich Luftstrom sorgt, und ein paar 130-mm-Aktivkohlefilterplatten. Wenn ich davon einfach zwei doppelt nehme, geht mehr als genug Luft durch, und sie filtern die Dämpfe recht gut.

Mit FreeCAD habe ich dann ein Gehäuse für die Teile entworfen, das ich einfach unter meine Werkbank schrauben kann. So liegt nur der Schlauch in einer Ecke und kann bei Bedarf zur richtigen Stelle bewegt werden, um die Löt-Dämpfe direkt an der Quelle abzusaugen.

Hier ein paar Bilder für euch – die Druckdateien findet ihr bei Maker World.

Ob die Teile auch zu euren „Resten“ passen, müsst ihr selbst kurz prüfen.

Oh, Schlauch und Filter findet ihr bei Amazon.

VueScan: Die beste Scannersoftware für vielseitige und alte Scanner

Einen guten Dokumentenscanner zu finden, der auch noch bezahlbar ist, kann schnell zu einer Herausforderung werden. Viele ältere Geräte verlieren nach kurzer Zeit den Support für das nächste Betriebssystem und funktionieren dann nicht mehr. Wenn der Scanner zusätzlich unter Linux reibungslos laufen soll, wird es noch spannender.

Vor vielen Jahren konnte ich mir günstig einen Fujitsu ScanSnap S1500 zulegen. Dieser Dokumentenscanner erfüllt genau meine Anforderungen: Er zieht mehrere Seiten über den automatischen Dokumenteneinzug (ADF) ein, scannt beidseitig, ist schnell und liefert eine gute Auflösung. Wenn ich ihn nicht brauche, lässt er sich genauso schnell zusammenklappen, wie er sich aufstellen lässt, und nimmt kaum Platz auf meinem ohnehin schon überladenen Schreibtisch ein. Ich nutze den Scanner, um meine Post, Rechnungen und andere wichtige Unterlagen zu digitalisieren. Anfangs lief dies noch über eine Windows-VM, da es lange keine wirklich einfache Software für Linux gab, die auf Knopfdruck Dokumente scannt, Texterkennung (OCR) anwendet und alles als durchsuchbares PDF abspeichert. Dieses PDF wandert dann automatisch in meine Nextcloud und hilft mir, Ordnung in meinen Unterlagen zu halten.

Vor etwa anderthalb Jahren stieß ich auf die Software VueScan. Zwar kostet sie etwas, aber für mich ist sie jeden Cent wert. Sie läuft nativ oder als Flatpak auf meinem Linux-System, bietet mehr Funktionen, als ich tatsächlich benötige, und unterstützt eine beeindruckend große Anzahl an Scannern. Sie scannt sogar mein Netzwerk nach anderen Geräten – so läuft auch mein Samsung-Multifunktionsdrucker problemlos damit. Was mich jedoch wirklich beeindruckt, sind die Menschen hinter der Software.

Soweit ich weiß, wird VueScan nur von zwei Leuten entwickelt. Sie reagieren extrem schnell auf E-Mail-Anfragen und bieten hervorragenden Support. Gestern ist die Anwendung zum ersten Mal abgestürzt. Ich konnte sie direkt wieder öffnen, und alles war in Ordnung. Da VueScan den Absturz jedoch selbst erkannte, öffnete sich sofort ein Dialog für einen Fehlerbericht. Das kennt man ja. Ich füllte den Bericht aus und schickte ihn ab – und heute hatte ich bereits eine E-Mail vom Entwickler im Postfach, der mir Unterstützung anbot und weitere Fragen zum Absturz stellte. Diese schnelle, persönliche Reaktion hat mich sehr positiv überrascht.

Klar, mir war bereits aufgefallen, dass VueScan sehr häufig und regelmäßig Updates erhält, aber dass der Entwickler so engagiert dahintersteht, beeindruckt mich wirklich. Das gibt mir ein gutes Gefühl. Die Software ist klasse, der Preis ist in Ordnung (ich habe die Professional-Version), und der Support sowie die Reaktionszeit sind erstklassig. Außerdem unterstützen sie gefühlt jeden Scanner auf diesem Planeten. Und ja, die Software gibt es natürlich auch für Windows und Mac. 😉

Ich muss also nur einmal lernen, wie eine Software funktioniert, und bin dann in der Lage, auf verschiedenen Betriebssystemen und mit verschiedenen Geräten zu arbeiten. Ich möchte ja nicht Experte für x verschiedene Softwarelösungen werden, sondern einfach nur schnell meine Dokumente digitalisieren.

Ich bekomme für diesen Beitrag keinerlei Vergütung oder Ähnliches – ich bin einfach wirklich überzeugt von VueScan. Probiert es doch einfach mal aus, und ich bin gespannt, ob ihr meine Meinung teilt.

« Ältere Beiträge

© 2025 -=Kernel-Error=-

Theme von Anders NorénHoch ↑