-=Kernel-Error=-

IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Seite 5 von 47

HTTPS RR und SVCB: Moderne DNS-Records für schnellere und sicherere Verbindungen

30. September 2025 / / Keine Kommentare
HTTPS RR und SVCB DNS-Records – schnellere Verbindungen mit HTTP/3, QUIC und DNSSEC

Wenn ein Browser eine HTTPS-Verbindung aufbaut, braucht er normalerweise mehrere DNS-Lookups und Round-Trips, bevor er überhaupt weiß, welche Protokolle der Server unterstützt. Erst A/AAAA-Record abfragen, dann TCP-Verbindung, dann TLS-Handshake, dann Alt-Svc-Header parsen für HTTP/3. Das ist ineffizient und seit November 2023 gibt es mit RFC 9460 eine saubere Lösung dafür: den HTTPS Resource Record.

Die großen Browser Hersteller unterstützen das ebenfalls schon, eigentlich mehr aus Eigeninteresse, denn viele Vorschläge kommen sogar direkt von ihnen. Oh, natürlich sollte die jeweilige Zone auch per DNSSec geschützt sein, denn wir wollen uns hier ja auf´s DNS verlassen können. Richtig?! Wenn ihr also noch kein DNSsec für eure Domain aktiviert habt (warum nicht?) dann bitte jetzt, wir haben bald 2026!

Ich habe das jetzt auf meiner DNS-Infrastruktur (BIND 9.20, FreeBSD, Master-Slave-Setup) für alle relevanten Dienste ausgerollt und dabei auch gleich SVCB-Records für die DNS-Server selbst gesetzt. Hier die Details.

Was ist der HTTPS RR?

Der HTTPS Resource Record (Typ 65) ist in RFC 9460 definiert („Service Binding and Parameter Specification via the DNS“, November 2023). Die Idee ist simpel: ein einziger DNS-Lookup liefert dem Client alles, was er für den Verbindungsaufbau braucht. IP-Adressen, unterstützte Protokolle wie HTTP/2 oder HTTP/3, Ports, und perspektivisch auch die ECH-Konfiguration für verschlüsselten SNI.

Ohne HTTPS RR sieht der Ablauf so aus: Der Client fragt A und AAAA ab, baut eine TCP-Verbindung auf, macht den TLS-Handshake, und erfährt erst aus dem Alt-Svc-Header oder durch ALPN im TLS, dass der Server auch HTTP/3 kann. Beim nächsten Request kann er dann QUIC probieren. Das sind mindestens zwei Verbindungsversuche, bis er auf dem optimalen Protokoll landet.

Mit HTTPS RR weiß der Client schon nach dem DNS-Lookup: „Dieser Server spricht h3 und h2, ist unter diesen IPs erreichbar, und hier ist die ECH-Config.“ Er kann direkt mit QUIC/HTTP/3 starten, ohne vorher TCP probiert zu haben.

Die SvcParams im Detail

Ein HTTPS RR besteht aus einer Priorität (SvcPriority), einem Zielnamen (TargetName) und einer Reihe von Service Parameters (SvcParams). Hier ein Überblick über alle definierten Parameter:

alpn (Application-Layer Protocol Negotiation): Signalisiert welche Protokolle der Server unterstützt. Typische Werte sind h2 (HTTP/2 über TLS), h3 (HTTP/3 über QUIC) oder dot (DNS over TLS). Der Client weiß damit vor dem Verbindungsaufbau, welche Protokolle zur Verfügung stehen.

ipv4hint / ipv6hint: IP-Adressen als Hint. Der Client kann diese nutzen, statt einen separaten A/AAAA-Lookup zu machen. Das spart einen Round-Trip. Wichtig: das sind Hints, keine autoritativen Antworten. Der Client darf und sollte trotzdem den normalen A/AAAA-Record prüfen.

ech (Encrypted Client Hello): Enthält den öffentlichen Schlüssel und die Parameter für ECH. Damit verschlüsselt der Client den SNI (Server Name Indication) im TLS-Handshake, sodass ein Beobachter auf dem Netzwerkpfad nicht sehen kann, welche Domain angefragt wird. Das ist der größte Privacy-Gewinn, den HTTPS RR bieten kann. Dazu später mehr.

port: Falls der Service auf einem nicht-Standard-Port läuft. Bei normalen Webservern auf 443 nicht nötig.

no-default-alpn: Signalisiert, dass die Standard-ALPNs (die sich aus dem Schema ergeben) nicht gelten. Wird benötigt wenn ein Server z.B. nur h3, aber nicht h2 unterstützt.

mandatory: Listet Parameter auf, die ein Client zwingend verstehen muss, um den Record nutzen zu können. Ein Client, der einen mandatory-Parameter nicht kennt, muss den ganzen Record ignorieren.

SvcPriority: Die Priorität des Records. 0 bedeutet AliasMode (Weiterleitung auf einen anderen Namen, ähnlich CNAME), Werte größer 0 sind ServiceMode. Mehrere Records mit unterschiedlichen Prioritäten ermöglichen Fallback-Ketten.

TargetName: Der Zielserver. Wenn er sich vom abgefragten Namen unterscheidet, leitet der Client die Anfrage an diesen Host weiter. Das ermöglicht Indirektion, ähnlich wie bei SRV-Records.

SVCB: Das generische Pendant

Der SVCB Resource Record (Typ 64) kommt aus demselben RFC 9460, ist aber nicht auf HTTPS beschränkt. HTTPS RR ist technisch gesehen nur eine spezialisierte Variante von SVCB für das HTTPS-Schema. SVCB kann für beliebige Protokolle genutzt werden.

Besonders interessant wird SVCB für die DNS Service Discovery nach RFC 9461 („Service Binding Mapping for DNS Servers“, ebenfalls 2023). Damit kann ein DNS-Server per DNS-Record signalisieren, dass er DoT (DNS over TLS) und DoH (DNS over HTTPS, RFC 8484) unterstützt. Der Record liegt unter dem Prefix _dns. vor dem Servernamen.

Der dohpath-Parameter aus RFC 9461 teilt dem Client direkt den URI-Pfad zum DoH-Endpoint mit, z.B. /dns-query{?dns}. Damit braucht der Client keine separate Konfiguration mehr, wo der DoH-Endpoint liegt. Zusammen mit RFC 9462 („Discovery of Designated Resolvers“, DDR) kann ein Client damit automatisch erkennen, dass sein Resolver verschlüsselte Protokolle unterstützt, und automatisch upgraden.

Was ich konkret deployt habe

Insgesamt 5 neue Records in zwei Zonen. Für www.kernel-error.de und cloud.kernel-error.com existierten bereits HTTPS RRs.

Zone kernel-error.de:

Apex HTTPS RR für kernel-error.de selbst:

dig HTTPS kernel-error.de +short
1 kernel-error.de. alpn="h3,h2" ipv4hint=148.251.30.200 ipv6hint=2a01:4f8:262:4716::443

HTTPS RR für den DoH-Endpoint dns.kernel-error.de:

dig HTTPS dns.kernel-error.de +short
1 dns.kernel-error.de. alpn="h3,h2" ipv4hint=37.120.183.220 ipv6hint=2a03:4000:38:20e::853

SVCB Records für DNS Service Discovery nach RFC 9461. Zwei Records mit unterschiedlichen Prioritäten, DoH bevorzugt vor DoT:

dig SVCB _dns.dns.kernel-error.de +short
1 dns.kernel-error.de. alpn="h2,dot" dohpath=/dns-query{?dns} port=443
2 dns.kernel-error.de. alpn="dot" port=853

Priorität 1 bietet DoH über HTTP/2 (Port 443), Priorität 2 reines DoT (Port 853). Ein DDR-fähiger Client (RFC 9462) kann damit automatisch erkennen, welche verschlüsselten DNS-Protokolle mein Resolver unterstützt.

Zone kernel-error.com:

Apex HTTPS RR für kernel-error.com (Matrix Federation und Web):

dig HTTPS kernel-error.com +short
1 kernel-error.com. alpn="h3,h2" ipv4hint=148.251.30.204 ipv6hint=2a01:4f8:262:4716::52

HTTPS RR für matrix.kernel-error.com (Synapse Reverse Proxy). Über CNAME-Auflösung deckt dieser Record auch chat.kernel-error.com und admin.kernel-error.com ab:

dig HTTPS matrix.kernel-error.com +short
1 matrix.kernel-error.com. alpn="h3,h2" ipv4hint=148.251.30.204 ipv6hint=2a01:4f8:262:4716::52

CNAME-Interaktion: Ein wichtiges Detail

Laut RFC 9460 können HTTPS RR und CNAME nicht am selben DNS-Namen koexistieren. Das hat direkte Auswirkungen auf mein Setup: chat.kernel-error.com und admin.kernel-error.com sind CNAMEs auf matrix.kernel-error.com. Ein separater HTTPS RR für diese Namen ist also nicht möglich und auch nicht nötig. Der Client folgt dem CNAME und nutzt dann den HTTPS RR des Ziels.

Gleiches gilt für signaling.kernel-error.com, das ein CNAME auf rtc.kernel-error.com ist.

Was bewusst nicht umgesetzt wurde

ECH (Encrypted Client Hello): Wäre der größte Privacy-Gewinn. ECH verschlüsselt den SNI im TLS-Handshake, sodass ein Beobachter nicht sehen kann, welche Domain der Client anfragt. OpenSSL 3.5 hat die API dafür, aber nginx nutzt sie nicht. Selbst in Version 1.29.7 gibt es keine native ECH-Unterstützung. Dafür bräuchte es entweder Patches für nginx oder einen anderen Reverse Proxy. Sobald sich das ändert, kommt der ech-Parameter in die HTTPS RRs.

DoQ (DNS over QUIC, RFC 9250): DoQ ist ein eigenes Protokoll, das DNS direkt über QUIC transportiert, ohne HTTP-Overhead. Das ist nicht dasselbe wie DoH über HTTP/3! BIND 9.20 unterstützt kein DoQ. Dafür müsste man ein separates Frontend wie dnsproxy oder AdGuard DNS davor setzen.

SVCB für SMTP/IMAP: Es gibt IETF-Drafts, die SVCB auf Mail-Protokolle ausweiten wollen (SMTP Submission, IMAPS). Da diese aber noch kein finaler RFC sind und aktuell kein MTA oder Client sie auswertet, habe ich darauf verzichtet. Die bestehenden SRV-Records (_imaps._tcp, _submission._tcp, _submissions._tcp) sind heute das Richtige.

HTTPS RR für turn.kernel-error.com: Der primäre Zweck ist TURN/STUN, nicht Web. Clients bekommen den Server aus der Synapse-Konfiguration, ein HTTPS RR bringt hier keinen Vorteil.

HTTPS RR für rtc.kernel-error.com: Kein HTTP/3 auf diesem Server, da der nginx dort ohne h3-Modul läuft. Ein HTTPS RR mit nur alpn="h2" würde kaum Mehrwert bringen.

Deployment in DNSSEC-signierten Zonen

Beide Zonen sind mit DNSSEC signiert (ECDSAP256SHA256, inline-signing). Der Workflow für Änderungen an signierten Zonen ist immer derselbe:

rndc freeze kernel-error.de
# Zonendatei editieren, Serial hochzählen
named-checkzone kernel-error.de /path/to/zone/file
rndc thaw kernel-error.de

Nach dem thaw signiert BIND die neuen Records automatisch und der Slave (ns1) übernimmt die Änderungen sofort per NOTIFY und AXFR. BIND 9.20 unterstützt HTTPS und SVCB Records nativ, es ist also kein TYPE65-Workaround mit generischer Record-Syntax nötig.

Records prüfen

Wer sich die Records anschauen will:

dig HTTPS kernel-error.de +short
dig HTTPS dns.kernel-error.de +short
dig SVCB _dns.dns.kernel-error.de +short
dig HTTPS kernel-error.com +short
dig HTTPS matrix.kernel-error.com +short

Ausblick

Die offensichtlichste Lücke ist ECH. Sobald nginx native Unterstützung bekommt, wird der ech-Parameter in alle HTTPS RRs eingetragen. Das wäre dann echte SNI-Verschlüsselung für alle Dienste.

SVCB für SMTP und IMAP wäre der nächste logische Schritt, sobald die aktuellen IETF-Drafts zu finalen RFCs werden und MTAs/Clients anfangen, sie auszuwerten. Immer mal wieder setzte ich auch IETF-Drafts in meinem Setup oder Labor Setup um. In diesem speziellen Fall sehe ich darin aber keinen Nutzen. Aus irgendeinem Grund schaffen es solche IT Security Themen bei E-Mails nur sehr selten in eine „schnelle“ Umsetzung. Die Browserhersteller machen da bei HTTPS wohl genug selbst. Viele Ideen kommen ja sogar von diesen.

Und DoQ (RFC 9250) steht auf der Liste, sobald BIND oder ein brauchbarer Proxy es unterstützt. Dann würden die SVCB-Records um alpn="doq" ergänzt. Ich möchte nicht wieder etwas vor meinen DNS stellen. Das wird aber bereits von den großen Browsern unterstützt!

Siehe auch:

Bei Fragen oder Anmerkungen, einfach fragen.

Preciva 992D+ im Test: Löt- und Heißluftstation für Hobby & Repaircafé

9. September 2025 / / Keine Kommentare
Picture of Soldering Station Preciva 992D+

Weiter geht es mit einer Lötstation. Wie immer: Das ist ein Werkzeug, das ich selbst einsetze. Es bedeutet nicht, dass es das Beste der Welt ist oder dass man damit sofort eine professionelle SMD-Reparaturwerkstatt eröffnen sollte.

Ende des letzten Jahres war ich auf der Suche nach einer kompakten Lötstation, die eine ordentliche Wattleistung hat und eine Kombination aus Lötstation und Heißluftstation bietet. Sie sollte aber nicht zu teuer sein. Einzelne Geräte hatte ich zwar schon verschiedene, aber gedacht war es eher für den mobilen Einsatz im Repaircafé. Die dortigen Reparaturen sind meist überschaubar.

Dennoch muss ich zugeben, dass mich diese Station tatsächlich überrascht hat. Preis/Leistung sind wirklich gut. Fun Fact: Die FritzBox-Reparatur habe ich mit genau dieser Station gemacht – einfach um zu testen, was geht – und ja, es ging, und das sogar wirklich okay.

Natürlich ist sie nicht mit einer großen professionellen Station von beispielsweise Weller zu vergleichen. Aber das ist auch gar nicht der Anspruch. Das Ding kostet aktuell auf Amazon knapp 130 €. Dafür bekommt man 6 verschiedene Lötspitzen, Lötzinn, Heißluft mit verschiedenen Aufsätzen, ein digitales Display und ach … schaut mal selbst: https://amzn.to/47zAAmr

Ich würde behaupten: Die meisten Hobbyreparaturen – selbst im Bereich SMD – lassen sich damit problemlos durchführen. Aber hey, das ist nur meine Meinung.

Fragen? Einfach melden.

Unbekannte Spinne im Garten: Wolfsspinne oder doch etwas anderes?

8. September 2025 / / 1 Kommentar
Picture of a dead spider.

Ich selbst habe kein Problem mit Spinnen – das ist aber beim Rest meiner Familie nicht immer gegeben. Wie auch immer: Ich bilde mir ein, die meisten Spinnenarten, die hier in NRW so im Garten vorkommen, schon mal irgendwann gesehen zu haben. In den letzten Wochen finde ich aber immer mal wieder ein paar – für meinen Eindruck – recht große Exemplare, wenn auch bisher immer nur tot.

Eines habe ich mal fotografiert und zum Größenvergleich neben eine 10-Cent-Münze gelegt. Die AI sagt, dass es eine Wolfsspinne ist. Da würde ich aber spontan eher nach Nordamerika schielen. Kurz: Ich habe keine Ahnung. Fällt jemandem von euch etwas ein? Was ist das für eine Spinne?!

Fragen? Einfach melden.

Volksverschlüsselung wird eingestellt

7. September 2025 / / 2 Kommentare

An mir flog gerade die Information vorbei, dass die Volksverschlüsselung zum 31.01.2026 eingestellt wird. Ich habe mir dort vor ein paar Jahren mal ein S/MIME-Zertifikat für meine E-Mails geholt. Mir hat der Ansatz gefallen, dass man sich mit seinem neuen Personalausweis und dessen Online-Funktion dort legitimieren kann und im Anschluss sein Zertifikat bekommt. Für mich hat diese Abhängigkeit absolut Sinn ergeben. Wir haben ja schon alle einen Perso mit Online-Funktion und PIN und was weiß ich alles. Also warum nicht auch einfach und schnell Zertifikate darüber erstellen?

Screenshot der Meldung zur Einstellung des Dienstes Volksverschlüsselung.

Funktioniert hat das alles wirklich gut – leider mit dem gleichen Problemchen wie auch bei cacert.org: Die Root-Zertifikate sind nicht in den Trust Stores der Betriebssysteme, Browser, Mailclients usw. Signiert man also etwas damit, wird es beim Empfänger als ungültig und unsicher angezeigt, es sei denn, dieser installiert manuell die Root-Zertifikate. Das macht natürlich niemand. Damit war die Volksverschlüsselung für mich genauso raus wie leider auch cacert.org.

Nun hing hinter der Volksverschlüsselung ebenfalls das Fraunhofer-Institut. Meine Hoffnung war, dass über diesen Weg am Ende doch mal die Root-Zertifikate in die Trust Stores kommen. Aber leider nicht.

Die Diskussion, ob man Trust Stores wirklich braucht, ob man sie vor allem vorgefüllt braucht, mache ich genauso wenig auf wie DNSSEC und TLSA, ok? Denn uns allen ist ja inzwischen klar, dass wir es „sicher“ haben könnten – wenn man nur nicht so scheiß viel Geld mit den CAs verdienen könnte. Denn die ganzen CAs zahlen ja schon ein paar Euro, um in die Trust Stores zu kommen.

Soviel dann also zur Volksverschlüsselung.

Siehe auch: S/MIME per DNS mit SMIMEA

Fragen? Einfach melden.

USB-Kabeltester: Kabelbrüche & Datenfähigkeiten schnell prüfen

1. September 2025 / / Keine Kommentare

Das hier ist zugleich der Auftakt einer kleinen Beitragsserie unter dem Titel „Was hast du in deiner Elektronikwerkstatt?“. Vor allem nach dem Beitrag zur FritzBox wurde diese Frage mehrfach an mich herangetragen.

USB Kabeltester mit leuchtenden LEDs und eingestecktem USB-C Kabel.

Um gleich Klarheit zu schaffen: Von einer „Elektronikwerkstatt“ kann bei mir keine Rede sein. Was du hier siehst, ist meine kleine „Healing-Bench“, ganz sicher keine vollwertige Werkstatt und ohne entsprechenden Anspruch. Ich repariere und bastle Elektronik aus reinem Hobby, und man kann sich daran vermutlich nicht unbedingt ein Beispiel nehmen. Aber hey, ihr habt gefragt und ich hab was zu erzählen.

Mein Werkzeug soll eins sein: funktionieren. Ich will mich nicht darüber ärgern, es soll mich nicht umbringen und bitte auch nicht die Welt kosten. Ja, vieles davon stammt tatsächlich von AliExpress.

USB-Kabeltester: mein Einstieg

Heute stelle ich dir einen USB-Kabeltester vor. Mittlerweile kommt fast jedes Gerät mit einem USB-Kabel, zum Laden oder für den Datenaustausch. Besonders mit USB-C hat sich die Vielfalt der Kabelstandards enorm vergrößert. Ich meine damit nicht nur Lade-Standards, Spannungen und Leistungen, sondern auch verschiedene Datenübertragungsmodi.

Früher, zu Zeiten von USB-A/B, war das noch eindeutig: Ein Kabel konnte so ziemlich alles, Laden oder Daten. Mit Micro-USB begann dann der Wandel: Viele Kabel taugen nur noch zum Laden und übertragen keine Daten mehr.

So oder so hast du sicher auch so eine Schublade zuhause, in der sich unzählige USB-Kabel sammeln. Ständig ziehst du eins heraus und fragst dich: „Kannst du Daten übertragen?“ Das Kabel schweigt. Und bei seltsamem Verhalten fragt man sich: „Hast du einen Kabelbruch?“ Auch hier bleibt das Kabel stumm.

Praktische Hilfe für den Alltag

Hier kommt der USB-Kabeltester ins Spiel: Unter 10 €, betrieben mit einer einzigen CR2032-Knopfzelle, und er passt praktisch auf jede USB-Variante, selbst Lightning.

Link zu AliExpress: https://s.click.aliexpress.com/e/_oBI7lsv

So funktioniert’s

Beide Kabelenden einstecken, Gerät einschalten, und die beschrifteten LEDs zeigen sofort, welche Leitungen im Kabel verbunden sind. Oder auch nicht. Wer einen Kabelbruch sucht, wackelt einfach am Kabel. Wenn eine LED ausgeht, ist der Fehler gefunden. Das Ergebnis wird nicht durch irgendwelche Kondensatoren verfälscht.

Im Lieferumfang ist auch ein kleines, verständliches Handbuch enthalten: Es erklärt übersichtlich, welche Pins und Adern wo liegen und welche Funktion sie jeweils haben.

Fazit

Mit dem USB-Kabeltester machst du dir den Alltag deutlich leichter. Schnelle Kontrolle, einfache Bedienung, preiswert und super praktisch. Perfekt für alle, die einfach Ergebnisse wollen, ohne viel Aufwand.

Fragen? Einfach melden.

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

14. März 2025 / / 2 Kommentare
SMIMEA — S/MIME-Zertifikat per DNS veröffentlichen

Siehe auch: Volksverschlüsselung wird eingestellt, OPENPGPKEY: GPG-Schlüssel direkt im DNS veröffentlichen, Kleiner Nachtrag zum GlobalSign S/MIME Zertifikat…

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
   [... komplettes Zertifikat in Hex ...]
   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)
        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)
        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

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

Warum viele Anleitungen falsch sind

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.

Aufbau des SMIMEA-DNS-Records

Der erste Teil — der SHA256-Hash — 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 nur der SHA256-Hash des Local-Parts (also der Teil vor dem @) genutzt. Wer die genaue E-Mail-Adresse kennt, kann den passenden DNS-Eintrag finden — aber jemand, der blind durch die Zone scannt, sieht nur Hashes.

Der _smimecert-Prefix zeigt an, dass es sich um einen SMIMEA-Record handelt, ähnlich wie bei ._tcp. für SRV-Records oder _acme-challenge. für Let’s Encrypt. Und schließlich kommt die Domain, zu der die E-Mail-Adresse gehört.

Manuelle Abfrage mit dig

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

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

Anschließend die dig-Abfrage:

dig +dnssec +short 70e1c7d87e825b3aba45e2a478025ea0d91d298038436abde5a4c2d0._smimecert.kernel-error.com. SMIMEA
3 0 0 30820714308204FCA003020102021073C13C478DA7B114B871F00737
F1B0FB300D06092A864886F70D01010B0500304E310B30090603550406
[... Zertifikat in Hex ...]

Was bedeuten die Felder?

  • 3 — Usage: End-Entity-Zertifikat (DANE-EE), also für die tatsächliche E-Mail-Verschlüsselung und Signatur
  • 0 — Selector: Das komplette Zertifikat wird gespeichert (alternativ: 1 für nur den Public Key)
  • 0 — Matching Type: Keine Hash-Funktion, das Zertifikat liegt im Klartext vor (alternativ: 1 für SHA-256, 2 für SHA-512)
  • Hex-Werte — Der eigentliche Zertifikatsinhalt in hexadezimaler Darstellung

Manuelle Prüfung auf der Konsole

Den kompletten DNS-Record abrufen, die SMIMEA-Parameter (3 0 0) entfernen und als Hex-Datei speichern:

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

Hex in eine binäre DER-Datei umwandeln und mit OpenSSL anzeigen:

# Hex → DER
xxd -r -p dns_cert.hex dns_cert.der

# Zertifikat anzeigen
openssl x509 -inform DER -in dns_cert.der -text -noout

Verbreitung und Ausblick

SMIMEA ist leider noch immer nicht besonders weit verbreitet. Das liegt daran, dass das RFC noch immer experimental ist, aber auch daran, dass es auf weiteren Techniken aufbaut, die ebenfalls eher selten genutzt werden. Man braucht SMIMEA nur, wenn man überhaupt ein S/MIME-Zertifikat zur Signatur und Verschlüsselung von E-Mails verwendet. Zusätzlich muss die Domain per DNSSEC geschützt sein — 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.

Die Implementierung ist 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.

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 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.

Das einzig korrekt funktionierende Online-Tool, das ich finden konnte: co.tt/smimea.cgi. Alle anderen sind nicht erreichbar, halten sich nicht ans RFC oder ich war zu blöde, sie zu bedienen. Fragen? Einfach melden.

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

28. Februar 2025 / / Keine Kommentare

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!

Siehe auch: Dallas DS80C400: 8051-Ethernet-Mikrocontroller neu entdeckt, Commodore Floppy Disk Preservation: Firmware-Bug im xum1541 gefunden und gefixt

Fragen? Einfach melden.

Dallas DS80C400: 8051-Ethernet-Mikrocontroller neu entdeckt

18. Februar 2025 / / 2 Kommentare

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.

Dallas TINI400 evaluation board with DS80C400 microcontroller

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-C36 → 1 µF
  • C33 → 10 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!

Siehe auch: PDS OSIcom-Office Box: Retro-PC mit JUMPtec SBC & SUSE Linux​

Sicherheitslücken melden: Mein Umgang mit einem Vulnerability Report

17. Februar 2025 / / 1 Kommentar
Vulnerability Report

Vor Kurzem habe ich einen Vulnerability Report erhalten. Ich freue mich über solche Hinweise. Sie helfen mir, mein Setup zu verbessern, bevor jemand eine Schwachstelle tatsächlich ausnutzt.

Der Report

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

[...]

Best Regards,
Security Team

Erste Einschätzung

Terrapin hatte ich eigentlich schon überall gepatcht. Dann der Hinweis auf openpgpkey.kernel-error.com. Die Domain existiert als CNAME und gehört zur Web Key Directory (WKD), damit GPG-Keys automatisiert abgerufen werden können. Ich habe das als CNAME zu wkd.keys.openpgp.org angelegt, weil dieser Keyserver eine E-Mail-Validierung beim Hochladen durchführt.

Der betroffene SSH-Server gehört also gar nicht zu meiner Infrastruktur. Ich kann selbst nichts tun.

Vulnerability Type: JavaScript bei einem SSH-Problem auf Port 22? Der Finder hat vermutlich sein Standard-Template benutzt und nicht angepasst. Aber ich wollte trotzdem prüfen, ob seine Einschätzung zum SSH-Server zutrifft:

# ssh-audit openpgpkey.kernel-error.com (gekürzt)
(gen) banner: SSH-2.0-OpenSSH_8.4p1 Debian-5+deb11u3
(gen) software: OpenSSH 8.4p1

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

(kex) ecdh-sha2-nistp256  -- [fail] suspected NSA backdoor
(kex) ecdh-sha2-nistp384  -- [fail] suspected NSA backdoor
(kex) kex-strict-s-v00@openssh.com  -- [info] Terrapin counter-measure present

(key) ssh-rsa (2048-bit)  -- [fail] broken SHA-1 hash algorithm
(key) ecdsa-sha2-nistp256 -- [fail] suspected NSA backdoor

(mac) hmac-sha1-etm@openssh.com  -- [fail] broken SHA-1 hash algorithm
(mac) hmac-sha1                  -- [fail] broken SHA-1

Sieht tatsächlich nicht optimal aus. NIST-Kurven, SHA-1, 2048-Bit RSA. Der Hinweis war also nicht unberechtigt. Ich habe dem Finder freundlich und dankbar geantwortet, aber darauf hingewiesen, dass das System nicht zu meiner Infrastruktur gehört. Die relevanten WHOIS-Informationen zur IP habe ich mitgeschickt.

Die Antwort

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

„Hard efforts“. Ich will das nicht schlechtreden. Im beruflichen Umfeld hätte ich mich vielleicht sogar für eine Kleinigkeit stark gemacht. Aber hier geht es um meine private Infrastruktur, und dann noch mit dem JavaScript-Hinweis und der Meldung zu einem fremden System. Das wirkt oberflächlich. Also habe ich ihn freundlich darauf hingewiesen.

Wie man mit Vulnerability Reports umgehen sollte

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

Macht es den Leuten 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 bewerten kann.

Mehr zum Thema security.txt:
securitytxt.org | Wikipedia | BSI Allianz für Cybersicherheit

Zum Vergleich: Mein eigener SSH-Server

So sieht meine SSH-Konfiguration von außen aus:

# ssh-audit bsd01.kernel-error.de (gekürzt)
(gen) banner: SSH-2.0-OpenSSH_9.7 DemMeisterSeinRennAuto
(gen) software: OpenSSH 9.7

(kex) sntrup761x25519-sha512@openssh.com  -- [info] Post-Quantum Key Exchange
(kex) curve25519-sha256                   -- [info] default since OpenSSH 6.4
(kex) diffie-hellman-group16-sha512       -- [info] available since OpenSSH 7.3
(kex) kex-strict-s-v00@openssh.com        -- [info] Terrapin counter-measure

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

(enc) aes256-gcm@openssh.com              -- [info] available since OpenSSH 6.2
(enc) aes128-gcm@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

Keine NIST-Kurven, kein SHA-1, kein RSA, Post-Quantum Key Exchange mit sntrup761. Nur Ed25519 als Host Key. Der Banner ist übrigens Absicht.

Fragen? Einfach melden.

Magenta SmartHome Lüften: Lösung für Android-Probleme gefunden

23. Januar 2025 / / Keine Kommentare

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.

Siehe auch: Telekom SmartHome Erfahrungen, QIVICON Home Base 2.0: Migration vom Telekom SmartHome und was dabei schiefgeht, Telekom SmartHome: Firmware-Updates für HomeMatic-Geräte über die CCU2

Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑