IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.
Sicher ist es schon aufgefallen…. Ich habe die Einstellung meiner Webseite so verändert dass nun SSL/TLS gesicherte Verbindung „erzwungen“ ist.
Nun hoffen wir mal dass ich damit keinen „abhänge“. Sollte es also Probleme geben, einfach mal melden!
Fragen? Einfach melden.
Meine Domain ist per DNSSEC gesichert, der Webserver bietet TLS an. Mit DANE (DNS-based Authentication of Named Entities) lässt sich beides verbinden: Die Checksumme des TLS-Zertifikats wird als TLSA-Record im DNS veröffentlicht — DNSSEC schützt diesen Record vor Manipulation.
Das klassische CA-System hat ein grundsätzliches Problem: Jede der hunderten Certificate Authorities kann ein Zertifikat für jede Domain ausstellen. Wird eine CA kompromittiert oder handelt fahrlässig, können gefälschte Zertifikate im Umlauf sein — der Browser merkt nichts. DANE löst das, indem der Domaininhaber selbst festlegt, welches Zertifikat gültig ist. Der Hash steht im DNS, DNSSEC garantiert die Integrität. Keine CA kann das unterlaufen.
Unterstützt ein Client DANE, prüft er beim TLS-Handshake, ob der TLSA-Record zum angebotenen Zertifikat passt. Das funktioniert auch mit selbstsignierten Zertifikaten — solange der Hash stimmt und DNSSEC aktiv ist, wird dem Zertifikat vertraut. Die Spezifikation steht in RFC 6698.
Der TLSA-Record enthält einen Hash des Public Keys (SPKI) aus dem Zertifikat. Mit OpenSSL erzeugt:
openssl x509 -in server.pem -noout -pubkey \ | openssl pkey -pubin -outform DER \ | openssl dgst -sha256
Den Hash trägt man als TLSA-Record in die DNS-Zone ein. Für den Webserver (Port 443):
_443._tcp.www.kernel-error.de. 3600 IN TLSA 3 1 1 a321...f7
Die drei Zahlen 3 1 1 bedeuten:
Der TTL von 3600 Sekunden ist bewusst kurz gewählt — bei einem Zertifikatswechsel mit neuem Key soll der alte Record schnell ablaufen.
Mit dig lässt sich der TLSA-Record abfragen:
dig TLSA _443._tcp.www.kernel-error.de +short 3 1 1 a321...f7
Ob der Record auch zum tatsächlich ausgelieferten Zertifikat passt, prüft man mit OpenSSL — Hash vom Server-Zertifikat erzeugen und mit dem DNS-Record vergleichen:
echo | openssl s_client -connect www.kernel-error.de:443 2>/dev/null \ | openssl x509 -noout -pubkey \ | openssl pkey -pubin -outform DER \ | openssl dgst -sha256
Stimmen die Hashes überein, ist alles korrekt. Komfortabler geht es mit posttls-finger (Teil von Postfix) — das Tool prüft TLSA-Record und Zertifikat in einem Schritt.
DANE funktioniert nicht nur für Webserver. Für E-Mail ist es sogar wichtiger — SMTP hat kein Vertrauensmodell wie Browser, opportunistisches TLS kann trivial per Downgrade-Angriff ausgehebelt werden. Mit DANE und TLSA-Records auf Port 25 wird die Verschlüsselung kryptographisch verifizierbar. Wie man das mit Postfix einrichtet, steht im Beitrag Postfix mit DANE und DNSSEC absichern. Zur Visualisierung des DANE-Anteils im Mailverkehr habe ich damals Mailgraph um DANE-Graphen erweitert.
Siehe auch: DNSSEC einrichten
Fragen? Einfach melden.
Verschlüsselte E-Mail-Übertragungen sind meist ganz gut. Zumindest hält sie einem lästige Lauscher vom Hals. Besonders wichtig ist dabei der verschlüsselte Austausch zwischen Mail-Server und Mail-Client. Denn die User sitzen mit ihren Mail-Clients sehr schnell in einem „unsicheren“ Netzwerk. Daher wird inzwischen sehr oft und gut darauf geachtet diese Verbindungen zu sichern.
Die Verbindungen zwischen den Servern werden oft als nicht SO wichtig empfunden. Denn die Kisten stehen ja meist in gesicherten Bereichen (Serverraum, DMZ, Rechenzentrum) und dort zu lauschen ist schon aufwendiger – nicht unmöglich.
Es macht also Sinn seinem Postfix zu ermöglichen seine Server zu Server Verbindungen kryptisch zu gestalten.
Mit folgender Änderung sagt man seinem Postfix dass bei ausgehenden Verbindungen TLS benutzt werden kann, wenn möglich.
$ postconf -e smtp_tls_security_level=may
Wird Postfix nun ein Zertifikat gereicht, welches von Postfix mangels der Root-Zertifikate nicht geprüft werden kann… Ja, dann ist hier schon wieder Ende.
Sep 25 10:38:07 rootserver postfix/qmgr[2069]: D69471A2026: from=<kernel-error@kernel-error.com>;, size=38273, nrcpt=1 (queue active) Sep 25 10:38:07 rootserver postfix/smtp[9454]: certificate verification failed for gmail-smtp-in.l.google.com[2a00:1450:400c:c05::1b]:25: untrusted issuer /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
Auf Debian Systemen finden sich eine recht gepflegte Ansammlung im Paket: ca-certificates. Nachdem dieses installiert ist:
$ apt-get install ca-certificates
Sagt man Postfix noch wie er es findet:
$ postconf -e smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
Schon sollte Postfix in der Lage sein, ausgehende Serververbindungen zu prüfen und zu verschlüsseln.
Siehe auch: Client-Initiated Renegotiation deaktivieren
Fragen? Einfach melden.
Jabber, offiziell XMPP, ist ein offenes Messaging-Protokoll. Kein zentraler Betreiber, kein Vendor Lock-in, kein Unternehmen das die Nutzungsbedingungen diktiert. Jeder kann einen eigenen Server betreiben, und die Server sprechen untereinander. Wie E-Mail, nur für Messaging.
Bei kommerziellen Messengern gibt man mit der Nutzung Rechte an seinen Inhalten ab. Die AGBs von AIM, ICQ, MSN und Co. erlaubten dem Betreiber die Verwertung aller Inhalte die über den Dienst liefen. Die Dienste gibt es größtenteils nicht mehr, aber das Muster ist geblieben. Ein eigener Server bedeutet: Eigene Regeln, eigene Daten, eigene Entscheidung welche Module aktiv sind.
Die Vorteile von XMPP: Open Source, Verschlüsselung per TLS, kein Single Point of Failure, und eine riesige Auswahl an Clients für jede Plattform.
Nach Tests mit jabberd, ejabberd und Openfire bin ich bei Openfire hängengeblieben. Für einen kleinen Server mit Familie und Freunden bringt Openfire alles mit: Weboberfläche zur Administration, Plugin-System, IPv6-Support und einfache Installation unter Debian. Für einen großen öffentlichen Server würde ich anders entscheiden, aber für meinen Zweck passt es.
Die Installation unter Debian ist schnell erledigt. Die TLS-Konfiguration braucht etwas Handarbeit, dazu gibt es eigene Beiträge: Unsichere Cipher deaktivieren und S2S-Verbindungen mit fehlenden Intermediate-Zertifikaten.
Um zu zeigen wie flexibel XMPP ist: Mein Siemens Gigaset C470IP hat ein Mobilteil C47H mit eingebautem Messenger. Das Telefon verbindet sich mit dem Jabber-Server und kann Nachrichten empfangen und verschicken. Ohne App, ohne Smartphone, direkt auf dem DECT-Telefon.
 |  |  |
| Der Jabber Messenger des Gigaset C47H ist online und mit dem Server verbunden. | Am Gigaset C47H ist eine neue Jabber-Nachricht angekommen. | Die Nachricht wird am Mobilteil gelesen. Antworten funktioniert genauso. |
Fragen? Einfach melden.
Veraltet: CAcert-Zertifikate wurden nie in die Standard-Truststores der Browser aufgenommen. Kostenlose TLS-Zertifikate gibt es bei Let’s Encrypt.
CAcert ist eine feine Sache. Leider sind deren Root-Zertifikate noch nicht in allen Browsern und Programmen integrieret.
Ich habe mir nun Gedanken dazu gemacht:
Wie schaffe ich es die CAcert-Root-Zertifikate in Anwendungen von Microsoft (Word, Outlook, Internetexplorer..) und Mozilla (Thunderbird, Firefox…) so zu integrieren das sie immer als vertrauenswürdig erkannt werden? Auch bei allen anderen Usern auf dem System und denen die später noch ein neues Konto bekommen…
Natürlich könnte ich bei jedem User die Zertifikate einzeln mit der Hand importieren und als vertrauenswürdig einstufen. Es ist aber sehr aufwändig und bestimmte User haben damit ein, nennen wir es Problem! Es muss also automatisch gehen.
Für die Microsoftprodukte habe ich eine einfache Lösung gefunden. Mit >>dieser<< Regestrierungsdatei werden die CAcert-Root-Zertifikate automatisch ins System übernommen. Ab diesem Moment sind in allen Microsoftanwendungen, bei allen Usern (vorhandenen und neuen) eines Systems die Zertifikate gültig.
Bei Mozilla ist es nicht ganz so einfach. Hier geht es am einfachsten so:
!!Firefox sollte noch nicht auf dem System installiert sein!!
Zuerst besorgt man sich die Installationsdatei für den Firefox. Am einfachsten wohl hier: http://www.mozilla-europe.org/de/firefox/
Dann installiert man den Firefox wie gewohnt, startet ihn und importiert die CAcert-Root-Zertifikate als vertrauenswürdig. Jetzt Firefox zu machen und lassen! Bisher alles klar und einfach. Aber nun…
Jetzt sucht man unter: Dokumente und Einstellungen\seinUsername\Anwendungsdaten\Mozilla\Firefox\Profiles\irgendwas.default\ die Datei cert8.db. Gefunden? Gut… Merken wo!
Jetzt das Firefoxinstallerpacket entpacken. Am einfachsten vielleicht mit WinRAR.
Nun kopiert man die cert8.db in den, gerade entpackten Ordner, Firefox Setup 3.0.1\localized\defaults\profile\
Startet man nun die Firefoxinstallation über die setup.exe sind die CAcert-Root-Zertifikate immer automatisch im Firefox integriert. Da immer wenn ein User das erste mal den Firefox startet, sein default Profile zusammengestellt wird. Es wird also immer die cert8.db mit in sein Profil kopiert. In dieser liegen die Zertifikate. Also auch unserer importierten CAcert-Root-Zertifikate. Dieses Packet könnte man nun immer für seine Installationen nutzen und vielleicht auch weitergeben. Will man allen existierenden Usern die Zertifikate unterschieben, muss man einfach nur die cert8.db in dessen Ordner packen (Dokumente und Einstellungen\seinUsername\Anwendungsdaten\Mozilla\Firefox\Profiles\irgendwas.default\).
So funktioniert es auch unter Thunderbird. Bei Linux funktioniert es auch über diese Datei.
Ich diese Infos helfen dem Einen oder Anderen. Wenn noch jemand Infos dazu hat, freue ich mich natürlich über zuschriften!
Fragen? Einfach melden.
Veraltet: Nokia S40 und S60 gibt es nicht mehr, und CAcert hat es nie in die Browser-Truststores geschafft. Dieser Beitrag ist nur noch als Zeitdokument interessant.
CAcert.org Root Zertifikate unter Nokia S40 und S60 installieren. Ich habe ein Nokia 6300i. Dieses Gerät tut alles genau so wie ich es benötige. Nur eine Kleinigkeit hat mich gestört. Immer wenn ich versuche E-Mails von meinem IMAP-Server zu saugen oder E-Mails über meinen SMTP-Server zu verschicken, wird das jeweilige Zertifikat (SSL / TLS) als ungültig gemeldet. Was daran liegt, das ich diese beiden Zertifikate von CAcert habe unterschreiben lassen. Es müssen also die Root-Zertifikate (http://www.cacert.org/index.php?id=3) ins Mobiltelefon! Natürlich habe ich sofort versucht die Zertifikate ins Gerät zu bekommen. Leider scheiterte es immer an der Meldung: „Dateiformat nicht unterstützt“. Daraufhin habe ich viele und lange sinnlose E-Mails mit dem Nokia-Support getauscht. Leider ohne erfolg. Ich habe das weiter unten mal zusammengeschrieben, hier nun erstmal der genaue Weg die Zertifikate ins Handy zu bekommen: Zuerst auf dem Rechner eine HTML-Datei mit folgendem Namen erstellen: cert.html Der Inhalt sollte ca. so ausschauen: —– HTML-schnipp —– <?xml version=“1.0″?><!DOCTYPE html PUBLIC „-//WAPFORUM//DTD XHTML Mobile 1.0//EN“ „http://www.wapforum.org/DTD/xhtml-mobile10.dtd“><html xmlns=“http://www.w3.org/1999/xhtml“><head><title>Installing CAcerg.org<br>Root Certificate</title></head><body><p><a href=“root.cer“>Installing Class1 PKI Key</a><br><br><a href=“class3.cer“>Installing Class3 PKI Key</a><br><br><a href=“https://www.kernel-error.de“>Und nun testen..</a></p></body></html> —– HTML-schnapp —– Dann die beiden Zertifikate von CAcert.org herunterladen. Einmal das class1 und einmal das class3, jeweils im PEM format. Diese müssen nun konvertiert werden, ich nutze dafür openssl: openssl x509 –in root.crt –inform PEM –out root.cer –outform DER openssl x509 –in class3.crt –inform PEM –out class3.cer –outform DER Jetzt müssen die Dateien (cert.html, root.cer und class3.cer) ins gleiche Verzeichnis ins Mobiltelefon kopiert werden. Dort nun übers das Telefonmenu hinklicken und die cert.html öffnen.
Wenn sich diese geöffnet hat einfach die Links von oben nach unten durchklicken und die jeweiligen Zertifikate speichern.
Das ist dann schon alles…. Fertig!
Hier nun der zusammengeschriebene Teil vom Nokiasupport.
—– NokiaCare schnipp —–
Wir möchten Ihnen mitteilen, dass das X.509 Zertifikat umgewandelt werden muss, bevor Sie es auf Ihr Nokia 6300i übertragen können. Ihr Nokia 6300i unterstützt .p12 Zertifikate.
—– NokiaCare schnapp —–
P12 klang für mich nicht sinnig, probiert habe ich es denn noch… Ohne erfolg! Daher wieder eine E-Mail an den Support, vielleicht muss es ja irgendwo gesondert hin oder sonst was…
—– NokiaCare schnipp —–
Bitte kopieren Sie das *.12 Zertifikat mit der PC Suite auf Ihr Mobiltelefon. Die Datei muß nicht in ein spezielles Verzeichnis kopiert werden. Die Datei wird automatisch von MfE verarbeitet.
—– NokiaCare schnapp —–
Alles klar… geht nicht immer noch die Meldung: „Dateiformat nicht unterstützt“ Lieber noch einmal nachfragen und mein Problem deutlicher erklären!
—– NokiaCare schnipp —–
Übertragen Sie die Datei auf das Mobiltelefon, gehen Sie in den Dateimanager und rufen Sie die Datei auf, dies installiert sich dann automatisch.
—– NokiaCare schnapp —–
Das funktioniert so nicht… Zu dem brauche ich kein Benutzerzertifikat sonder das einer CA…. Noch eine E-Mail an Nokia!
—– NokiaCare schnipp —–
Um private Schlüssel importieren zu können, erstellen Sie bitte eine *.p12-Datei. Diese enthält Ihren privaten Schlüssel und das Benutzerzertifikat. Diese Datei importieren Sie bitte in Ihr NOKIA Mobiltelefon. Dort wird das Zertifikat automatisch erkannt. Zur Speicherung folgen Sie bitte den Hinweisen des Telefons. Nun werden Sie zur Eingabe eines Sicherheitscodes aufgefordert. Beachten Sie bitte dabei, dass die geforderte Sicherheitseingabe ausschließlich aus Ziffern bestehen darf. Das geforderte Passwort wird durch die Zertifizierungsstelle erstellt.
—– NokiaCare schnapp —–
Ich scheine nicht im Stande zu sein mein Problem verständlich in eine E-Mail zu packen! Ich beschließe eine weitere E-Mail zusammen mit meiner Frau zu schreiben (diese entspricht dem durchschnittlichen PC-User)! Und hier ist Nokias Antwort:
—– NokiaCare schnipp —–
Scheinbar haben wir uns bei Ihrem angegebenen Telefonmodell verlesen.Ihr NOKIA 6300i ist ein Gerät der Serie 40. Die Angaben die wir Ihnen gemacht haben, beziehen sich auf S60 Geräte.Dafür möchten wir uns entschuldigen. Sie sollten das entsprechende Zertifikat im Format DER konvertieren und erneut wie angegeben auf Ihr NOKIA Mobiltelefon übertragen.Es sollte sich nun installieren lassen. Wir wünschen Ihnen viel Freude mit den Produkten aus unserem Haus.
—– NokiaCare schnapp —–
Verlesen? Was habe ich denn noch gleich geschrieben *nachschau*
—– Meine Mail schnipp —–
[Country: Germany]
[Language: German]
[Permission to Email: ]
[Permission to SMS: ]
[Permission to Letter: ]
[Permission to Phone: ]
[First name: van de Meer ]
[Last name: Sebastian]
[Street address: Alte Bergstr. 12]
[ZIP: 45549]
[City: Sprockhövel]
[Email address: kernel-error@kernel-error.de]
[Landline: +49 02324 6858622
]
[Mobile: +49 0177 5995900] ]
[Phone model: Nokia 6300]
[IMEI: ]
[Shop number: ]
[CID: ]
[Contact topic: Nokia Mobiltelefone und Zubehör]
[Message: Sehr geehrte Damen und Herren, wie lassen sich weitere X.509 Root Zertifikate einer CA in meinem 6300i importieren? Mit besten Grüßen S. van de Meer]
[Operator: E-plus]
[Operating system: Linux]
—– Meine Mail schnapp —–
Öhm… egal! Ich probiere es mal (auch wenn ich das natürlich schon probiert habe)!
Komisch immer noch die gleiche Meldung: „Dateiformat nicht unterstützt“
—– NokiaCare schnipp —–
Bezüglich Ihrer Anfrage möchten wir Ihnen mitteilen, dass Sie das DER-typ X509v3 Zertifikat für Ihr S40 Handy benötigen. Sie müssen das CER (Base64) Zertifikat ins DER (binary Format) konvertieren.
—– NokiaCare schnapp —–
Da ich genau das schon probierte habe ich an diesem Punkt die Zusammenarbeit mit dem Nokia Support aufgegeben! Ich habe nun begonnen herumzubasteln und zu testen! Der installierte Opera wird auf dem Gerät zum Browsen benutzt, scheint aber nicht wirklich etwas mit der Systemeigenen CA-Liste zutun zu haben (wie sein großes Vorbild halt). Daher bringt es mir auch nichts mit dem Teil auf irgendwelchen Webseiten herumzufummeln. Irgendwann habe ich mal probiert welche Formate unterstützt werden. Interessanterweise ging bei HTML nicht der Opera auf, sondern der „systemeigene“ Browser. An dieser Stelle ist mir dann die oben stehende Idee gekommen!
Veraltet: CAcert hat es nie in die Browser-Truststores geschafft. Die CA existiert zwar noch, spielt aber keine praktische Rolle mehr. Dieser Beitrag ist nur noch als Zeitdokument interessant.
Genau um solche Dinge sicher zu stellen, gibt es Zertifikate. Eine gute Möglichkeit für Privatleute oder kleine Firmen ist da CAcert.
CAcert ist eine gemeinschaftsbetriebene nicht kommerzielle Zertifizierungsstelle (Root CA), die kostenfrei X.509-Zertifikate für verschiedene Einsatzgebiete ausstellt. Damit soll eine Alternative zu den kommerziellen Roots CAs geboten werden, die zum Teil recht hohe Gebühren für ihre Zertifikate erheben. Die Dienstleistungen der CAcert sind allgemein. Jeder kann sich Zertifikate auf seinem Namen bzw. auf seinen Server ausstellen lassen, nachdem er seine Identität ausreichend belegt hat.
Zertifikate
Folgende Zertifikate und Signaturen werden angeboten:
Client-Zertifikate
Diese Zertifikate sind personalisiert, sie dienen zum Beispiel zum Verschlüsseln und Signieren von E-Mails und anderen Daten, aber auch Authentifikation an Servern oder zum Signieren von Softwarecode.
Server-Zertifikate
Server-Zertifikate stellen die Identität eines Servers sicher und dienen als Basis für verschlüsselte SSL/TLS-Verbindungen. Es gibt eine Bandbreite von Diensten, bei denen Server-Zertifikate zum Einsatz kommen. Dazu gehören u. a. HTTPS, FTP(S), SMTP(S), POP(S) und IMAP(S).
Signatur des PGP-Schlüssels
Man kann den eigenen PGP-Schlüssel zur Signatur einreichen. Die CAcert bestätigt dann die Identität des Schlüsselbesitzers.
Assurance / Identitätsprüfung
Um ein Zertifikat zu erhalten, muss man sich zunächst auf der Seite https://www.cacert.org/index.php?id=1 als Benutzer anmelden. Jedem Benutzerkonto sind Punkte (Assurance Points) zugeordnet, die auf verschiedenen Wegen von anfänglich 0 bis auf 150 Punkte erhöht werden können. Die Punkte geben an, wie genau die Identität eines Benutzers überprüft wurde (bis 100 Punkte) bzw. wieviele Punkte er beim Überprüfen der Identität eines anderen Benutzers vergeben darf (ab 100 Punkten).
Ich selbst bin auch ein solcher Assurer und kann die begehrten Punkte vergeben.
Interessierte schicken mir bitte eine kurze E-Mail. Dann können wir ein Treffen absprechen!
© 2026 -=Kernel-Error=- — RSS
Theme von Anders Norén — Hoch ↑