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

Schlagwort: Encryption (Seite 4 von 8)

Firefox OCSP-Stapling Fehler bei StartSSL beheben

Veraltet: StartSSL wurde 2017 von allen Browsern als nicht mehr vertrauenswürdig eingestuft und hat den Betrieb eingestellt. OCSP Stapling ist weiterhin relevant, aber die hier beschriebene Fehlerursache (StartSSL OCSP-Responder) existiert nicht mehr.

Natürlich ist bei mir OCSP Stapling am Apache 2.4 aktiviert…. Doch plötzlich zeigt mir meine Webseite beim Besuch mit dem Mozilla Firefox folgende Fehlermeldung:

Secure Connection Failed

An error occurred during a connection to www.kernel-error.de. The OCSP server suggests trying again later. (Error code: sec_error_ocsp_try_server_later)

    The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
    Please contact the website owners to inform them of this problem.

Im Error Log des Webservers finden sich zur gleichen Zeit Logmeldungen wie:

[Mon Aug 10 07:06:28.572899 2015] [ssl:error] [pid 23648] (70007)The timeout specified has expired: [client 1.2.3.4:23726] AH01977: failed reading line from OCSP server
[Mon Aug 10 07:06:28.572924 2015] [ssl:error] [pid 23648] [client 1.2.3.4:23726] AH01980: bad response from OCSP server: (none)
[Mon Aug 10 07:06:28.572950 2015] [ssl:error] [pid 23648] AH01941: stapling_renew_response: responder error

Ahja… bad response from OCSP Server…. Habe ich nun irgendwo Mist konfiguriert oder hat wirklich der OCSP Server meiner CA StartSSL / StartCOM ein Problem? Mein Verdacht ist natürlich, dass es an der CA liegen muss. ;-P

Am schnellsten Teste ich es einmal von Hand auf meinem Client. Ist hier das gleiche Problem, liegt es sicher an der CA. Wie also manuell per openssl testen ob der OCSP Server tut was er will? Ganz einfach, so:

Als erstes einmal den öffentlichen Teil meines Zertifikates herunterladen und in einer Datei speichern:

# openssl s_client -connect www.kernel-error.de:443 2>&1 < /dev/null | sed -n '/-----BEGIN/,/-----END/p' > www.kernel-error.de.pem

Jetzt das Intermediate besorgen. Dieses sollte ja ebenfalls mein Server senden, also hole ich es von dort. Dabei ist hier nun etwas copy & paste Arbeit nötig. Folgendes wirft mir einiges um die Ohren:

# openssl s_client -connect www.kernel-error.de:443 -showcerts 2>&1 < /dev/null

Hier ist kopiere ich mir nun das Intermediate Zertifikat heraus in das File interm.pem. Spannend ist dabei das Zertifikat zu:

 1 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA
   i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
-----BEGIN CERTIFICATE-----
MIIGNDCCBBygAwIBAgIBGzANBgkqhkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEW

Dabei alles ab —–BEGIN CERTIFICATE—– bis einschließlich —–END CERTIFICATE—–

In meinem Zertifikat sollte der OCSP Server meiner CA hinterlegt sein. Diesen lasse ich mir nun mit folgendem Befehl ausgeben:

# openssl x509 -noout -ocsp_uri -in www.kernel-error.de.pem
http://ocsp.startssl.com/sub/class2/server/ca

Perfekt… Nun habe ich alle Informationen zusammen um einen manuellen Test gegen den OCSP Server meiner CA zu fahren:

# openssl ocsp -issuer interm.pem -cert www.kernel-error.de.pem -text -url http://ocsp.startssl.com/sub/class2/server/ca
OCSP Request Data:
    Version: 1 (0x0)
    Requestor List:
        Certificate ID:
          Hash Algorithm: sha1
          Issuer Name Hash: B9B2D56DB021B36E42F627245806C4A9A6979AEB
          Issuer Key Hash: 11DB2345FD54CC6A716F848A03D7BEF7012F2686
          Serial Number: 06D8F968657B18
    Request Extensions:
        OCSP Nonce: 
            04109228F685EAF4211B1A6D6CCF67AD9CC9
Error querying OCSP responder
34379249832:error:27076072:OCSP routines:PARSE_HTTP_LINE1:server response error:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/ocsp/ocsp_ht.c:255:Code=400,Reason=Bad Request

Hm… Sehr eindeutig, oder? Es scheint also wirklich ein Problem am Server der CA zu geben. Eine kurze E-Mail an die CA später habe ich, auf die Frage ob es ein Problem mit dem OCSP Server gibt, die folgende Antwort in meinem Postfach:

Yes. It would be fixed asap.

-- 
Regards
 
Signer:  	Kirill Ivanov, VO
  	StartCom Ltd.

Na wunderbar… Damit schalte ich also OCSP Stapling mal wieder aus, bis meine CA wieder korrekt arbeitet!

SSLUseStapling Off

Bis spööööter 😀

Apache 2.4 und Diffie-Hellman DHE mit 4096bit

Kaum geht mein Artikel zur erweiterten Sicherheit meiner Webseite online >>TLS Sicherheit weiter verschärft….<< schon kommen Fragen. Eine habe ich nun schon vier mal bekomme, daher hier direkt die Antwort. Ach ja, die Frage:

Wie habe ich meinen Apache dazu überredet DHE-Keys mit 4096bit zu benutzen?

Also… Der Apache beherrscht seit Version 2.4 Diffie Hellman mit mehr als 1024bit. Um dieses nutzen zu können, muss der Apache die passenden dh-params haben. Der Apache nutzt dabei automatisch die ihm gegebene Key stärke.

Ich generiere den DH Teil gerne direkt mit dem jeweiligen Zertifikat und verbinde dieses. Beschrieben habe ich es hier: >>Sicheres SSL / TLS Zertifikat<<

Wer gerne nachträglich generieren möchte macht es mir:

$ openssl gendh 4096 > dh_4096.pem

Dieses lässt sich nun einfach wie ein normales Zertifikat mit in die Konfiguration des Apachen einbinden. Im Grunde nichts besonders und nachdem man es gelesen und absolut einleuchtend, man sucht aber dann doch zuerst etwas.

Viele andere Dienste (Postfix usw…) bringen ja meist einen eigenen Konfigurationspunkt dafür mit. Im Apache liegt es ohne große Konfiguration in Zertifikatsnähe.

easy

So long….

Fragen? Einfach melden.

FreeBSD: Verschlüsseltes ZFS-Backup auf USB-Platte mit geli

FreeBSD-Notebook erstellt per ZFS-Snapshot und zfs send ein verschlüsseltes Backup auf eine USB-Platte mit geli, Schlüsseldatei, Passphrase und sicherem Aushängen.

Ein Notebook mit Full-Disk-Encryption verdient auch ein verschlüsseltes Backup. Plan: ZFS-Snapshots per zfs send auf eine USB-Platte schieben, die komplett mit geli verschlüsselt ist. Schlüssel und Passphrase sicher aufbewahren, fertig.

Hinweis: Seit OpenZFS 2.0 (FreeBSD 13+) gibt es native ZFS-Verschlüsselung (zfs create -o encryption=aes-256-gcm). Damit entfällt geli als Zwischenschicht. Auf älteren Systemen oder wenn man die gesamte Platte unabhängig vom Dateisystem verschlüsseln will, bleibt geli die richtige Wahl.

USB-Platte verschlüsseln

Platte einstecken und per dmesg das Device identifizieren, in diesem Fall da0. Dann mit gpart eine neue GPT-Partitionstabelle anlegen und eine Partition erstellen.

geli braucht einen Schlüssel aus Zufallsdaten:

dd if=/dev/random of=./backup-key bs=256 count=1

Mit diesem Schlüssel die verschlüsselte Partition einrichten:

geli init -s 4096 -K ./backup-key -l 256 /dev/da0s1
Enter new passphrase:
Reenter new passphrase:

Metadata backup can be found in /var/backups/da0s1.eli and
can be restored with the following command:

    # geli restore /var/backups/da0s1.eli /dev/da0s1

Partition öffnen:

geli attach -k ./backup-key /dev/da0s1
Enter passphrase:

ZFS-Pool anlegen

Auf der geöffneten geli-Partition (da0s1.eli) den ZFS-Pool erstellen:

zpool create usb-backup /dev/da0s1.eli

zpool list
NAME         SIZE  ALLOC   FREE  CAP  HEALTH
zroot        460G   184G   276G  40%  ONLINE
usb-backup   928G   296K   928G   0%  ONLINE

Backup starten

Initiales Vollbackup per zfs send -R (rekursiv, alle Datasets und Snapshots):

zfs send -R zroot@auto-2015-05-23-21-00-00 | zfs recv -u usb-backup/notebook

Die Option -R sendet alles rekursiv. Die Option -u beim Empfänger verhindert, dass die Datasets auf der USB-Platte gemountet werden. Bei allen folgenden Backups muss nur noch die Differenz zwischen zwei Snapshots übertragen werden.

Platte sicher aushängen

Drei Schritte in der richtigen Reihenfolge:

  • Sync erzwingen, alle Daten sicher auf die Platte schreiben
  • ZFS-Pool exportieren
  • geli-Partition schließen
sync
zpool export usb-backup
geli detach /dev/da0s1

Wichtig: Den Schlüssel (backup-key) an einem dritten Ort aufbewahren, weder auf dem Notebook noch auf der Backup-Platte. Ohne Schlüssel und Passphrase sind die Daten nicht wiederherstellbar.

Mehr zu ZFS-Backups: Automatische ZFS-Snapshots und ZFS send/recv Fehler beheben. Fragen? Einfach melden.

Neues StartSSL S/MIME Zertifikat

Veraltet: StartSSL wurde 2017 von allen Browsern als nicht vertrauenswürdig eingestuft und eingestellt. Kostenlose S/MIME-Zertifikate gibt es bei Actalis.

Zwei Jahre sind schon wieder um. Das bedeutet es gibt ein neues S/MIME Zertifikat, da mein altes bald ungültig wird. Hier nun die Daten für interessierte zum Abgleich!

So long

ALT
Zertifikat-Fingerabdruck
SHA1:	7F 8B 92 19 FF 07 BF EB 8E E0 18 D4 98 B8 48 DF E3 0E 4A 85
Läuft ab: 16.05.2015
Signatur-Algorithmus:	SHA1 mit RSA 2048 Bit

 

NEU
Zertifikat-Fingerabdruck
SHA1:	F6 00 F9 B0 DB BF B9 C5 C1 58 03 B2 78 11 84 A7 F1 E8 96 6D
Läuft ab: 08.05.2017
Signatur-Algorithmus:	SHA256 mit RSA 4096 Bit

 

Fragen? Einfach melden.

OPENPGPKEY: GPG-Schlüssel direkt im DNS veröffentlichen

OPENPGPKEY-Record für einen GPG-Schlüssel im DNS mit Hash des E-Mail-Localparts, DNSSEC-Schutz, Base64-kodiertem Public Key und automatischem Abruf per GnuPG.

Schon länger kann man GPG-Schlüssel per CERT-Record im DNS hinterlegen, allerdings nur als Verweis auf einen Ort, an dem der Schlüssel liegt. Mit dem OPENPGPKEY Resource Record (RFC 7929) geht es einen Schritt weiter: Der komplette öffentliche Schlüssel steckt direkt im DNS-Record. Ist die Zone per DNSSEC gesichert, kann der Schlüssel nicht gefälscht werden, unabhängig von Keyservern und den dort möglicherweise kursierenden Fake-Keys.

Aufbau des Records

Der Hostname des OPENPGPKEY-Records wird aus der E-Mail-Adresse abgeleitet. Aus dem Localpart (alles vor dem @) wird ein SHA-256-Hash gebildet und die ersten 56 Zeichen davon als Subdomain unter _openpgpkey.domain verwendet. Für user@example.de:

echo -n "user" | sha256sum
# Ergebnis: 04f8996da763b7a969b1028ee3007569eaf3a635486ddab211d512c85b9df8fb
# Die ersten 56 Zeichen des Hashes werden zum Hostnamen:
04f8996da763b7a969b1028ee3007569eaf3a635486ddab211d512c85b._openpgpkey.example.de. IN OPENPGPKEY <base64-encoded-key>

Der Wert des Records ist der GPG Public Key im Binärformat, Base64-kodiert.

Record erzeugen

Den Hash des Localparts berechnen:

echo -n "kernel-error" | sha256sum | cut -c1-56
# 4e1543e4c2a42754aa23025a940a30d0d3d106025c9e03be8e525ac4

Den Public Key exportieren und Base64-kodieren:

gpg --export --export-options export-minimal kernel-error@kernel-error.com \
  | base64 -w 0

Beides zusammen ergibt den Zoneneintrag:

4e1543e4c2a42754aa23025a940a30d0d3d106025c9e03be8e525ac4._openpgpkey.kernel-error.com. IN OPENPGPKEY mQINBF...==

Zugegeben, der Record sprengt etwas die Zonenlesbarkeit. Ein GPG-Schlüssel hat schnell mehrere Kilobyte, das wird im Zonefile eine lange Zeile. BIND kommt damit problemlos klar.

Schlüssel automatisch aus dem DNS holen

GnuPG ab Version 2.1 kann OPENPGPKEY-Records direkt abfragen. Will man eine E-Mail verschlüsseln und hat den Schlüssel des Empfängers noch nicht, reicht:

gpg --auto-key-locate dane --locate-keys kernel-error@kernel-error.com

GnuPG sucht den OPENPGPKEY-Record im DNS, prüft die DNSSEC-Signatur und importiert den Schlüssel automatisch. Kein Keyserver nötig, kein manueller Import.

Testen

Ob der Record korrekt im DNS steht, lässt sich online prüfen: openpgpkey.info, E-Mail-Adresse eingeben, der Dienst fragt den OPENPGPKEY-Record ab und zeigt den gefundenen Schlüssel an.

OPENPGPKEY vs. CERT-Record

Der ältere CERT-Record enthält nur eine URL zum Schlüssel, der Client muss den Schlüssel dann von dort herunterladen. OPENPGPKEY packt den kompletten Schlüssel ins DNS. Vorteil: Ein einziger DNS-Lookup genügt, kein zusätzlicher HTTP-Request nötig. Nachteil: Große DNS-Antworten, die bei UDP-Transport fragmentiert werden können, aber mit passender EDNS-Konfiguration kein Problem.

Siehe auch: GPG-Schlüssel per PKA im DNS, GPG: E-Mails signieren und verschlüsseln mit GnuPG, Der sichere GPG-Schlüssel

Fragen? Einfach melden.

Neues Zertifikat

Einige haben es ja schon gesehen, ich habe nun doch vorzeitig mein Zertifikat von SHA1 auf SHA2 (SHA256) gehoben. Nein, ich habe nicht für das Widerrufen bezahlt. Wer ins Zertifikat schaut, wird schon sehen wie ich es gemacht habe. Damit bin ich dann wohl erst einmal wieder A+…. Fragt sich für wie lange. OCSP stört mich noch etwas, nicht unbedingt nötig, denn noch finde ich es ~unschön~! Jetzt nicht so unschön, dass ich es unbedingt sofort angehen muss; dennoch ist es irgendwie unschön!

 

So long.

Fragen? Einfach melden.

Openfire: Unsichere TLS-Cipher und Protokolle über Java deaktivieren

Openfire bringt in der Stable-Version keine Möglichkeit mit, schwache TLS-Cipher oder veraltete Protokolle wie SSLv3 zu deaktivieren. Die Nightly Builds haben das bereits im Default behoben, die Stable hinkt hinterher. Da Openfire auf Java läuft, lässt sich das Problem über die Java-Security-Konfiguration lösen.

Openfire Logo

java.security anpassen

Die Datei /usr/lib/jvm/java-8-oracle/jre/lib/security/java.security (Pfad je nach Distribution und Java-Version) enthält zwei relevante Einstellungen. Beide dürfen nur einmal in der Datei vorkommen.

Schwache Algorithmen für Zertifikatsketten deaktivieren:

jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024

Unsichere TLS-Cipher und Protokolle deaktivieren. Die Liste verbietet SSLv3, alle RC4-Cipher, alle Export-Cipher, alle anonymen DH-Cipher und veraltete 3DES-Varianten:

jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, DESede, \
  SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA, \
  SSL_DH_anon_EXPORT_WITH_RC4_40_MD5, \
  SSL_DH_anon_WITH_3DES_EDE_CBC_SHA, \
  SSL_DH_anon_WITH_DES_CBC_SHA, \
  SSL_DH_anon_WITH_RC4_128_MD5, \
  SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, \
  SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5, \
  SSL_RSA_EXPORT_WITH_RC4_40_MD5, \
  SSL_RSA_WITH_NULL_MD5, \
  SSL_RSA_WITH_NULL_SHA, \
  TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, \
  TLS_ECDH_anon_WITH_RC4_128_SHA

Das ist eine gekürzte Liste der wichtigsten Einträge. Je nach Sicherheitsanforderung kann man weitere Cipher hinzufügen. Oracle dokumentiert die Optionen unter den Stichworten "Java Algorithm restrictions for SSL/TLS" und "certification path processing".

JCE Unlimited Strength

Standardmäßig begrenzt Java die Schlüssellänge auf 128 Bit. Für AES-256 braucht man die JCE Unlimited Strength Jurisdiction Policy Files. Bei neueren Java-Versionen (ab 8u161) ist das per Default aktiv, bei älteren müssen die Policy-Dateien manuell installiert werden.

Aktivieren

Openfire neu starten. Die Änderungen in java.security wirken sofort beim nächsten Java-Start. Danach sollte ein TLS-Test nur noch aktuelle Cipher und Protokolle zeigen.

XMPP IM Observatory Score A

Wer zusätzlich Probleme mit S2S-Verbindungen hat: Im Beitrag zum 404 Remote Server Not Found ist das Thema fehlende Intermediate-Zertifikate beschrieben.

Fragen? Einfach melden.

Postfix und DANE: „Server certificate not verified“ debuggen

Eine Mail kommt als unzustellbar zurück. Im Bounce steht Server certificate not verified, im Postfix-Log sieht es so aus:

smtp[1520]: Trusted TLS connection established to example.de[...]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384
smtp[1520]: 30E4E7461347: Server certificate not verified
smtp[1520]: 30E4E7461347: to=, dsn=4.7.5, status=deferred (Server certificate not verified)

Erst „Trusted TLS connection“, dann „Server certificate not verified“. Das klingt widersprüchlich, hat aber eine klare Ursache.

Ursache: DANE/TLSA-Prüfung fehlgeschlagen

Ohne DANE würde Postfix die Mail trotzdem zustellen, auch wenn das Zertifikat nicht verifizierbar ist. Aber wenn der Empfänger einen TLSA-Record im DNS veröffentlicht hat, prüft Postfix das Zertifikat gegen diesen Record. Stimmt der Hash nicht überein, verweigert Postfix die Zustellung. Das ist gewolltes Verhalten: Entweder der Empfänger hat seinen TLSA-Record nicht aktualisiert (z.B. nach einem Zertifikatstausch), oder jemand versucht sich dazwischen zu drängen.

Debugging mit posttls-finger

posttls-finger (Teil von Postfix) prüft den kompletten DANE-Ablauf für eine Domain:

posttls-finger -t30 -T180 -c -L verbose,summary example.de

In der Ausgabe steht am Ende entweder Verified TLS connection established (alles OK) oder Untrusted TLS connection established (TLSA-Prüfung fehlgeschlagen). Zusätzlich zeigt das Tool den TLSA-Record aus dem DNS und den Fingerprint des Zertifikats. Stimmen die beiden nicht überein, liegt das Problem beim Empfänger.

Was Postfix dann macht

Eine fehlgeschlagene DANE-Prüfung erzeugt einen temporären Fehler (4.7.5). Postfix behält die Mail in der Queue und versucht es über mehrere Tage erneut. Wenn der Empfänger seinen TLSA-Record in der Zwischenzeit korrigiert, geht die Mail durch. Passiert das nicht, kommt die Mail als Bounce zurück.

Das ist genau das richtige Verhalten. Lieber eine Mail verzögern als sie über eine möglicherweise kompromittierte Verbindung zuzustellen. Wer TLSA-Records manuell prüfen will, findet dazu eine Anleitung mit OpenSSL. Die Grundlagen zu DANE und Postfix stehen im Beitrag Postfix mit DANE und DNSSEC absichern. Fragen? Einfach melden.

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

Seit ein paar Tagen scheint das Thema DNSSEC, DANE und TLSA im Zusammenhang mit Postfix im Internet besonders aktiv zu sein. Ich bekomme täglich Anfragen dazu und einige scheinen zu testen — E-Mails mit Random-Empfängern an meine Domains. Gegen Tests habe ich nichts, aber grob abgesprochen wäre schön, mein Monitoring wird sonst immer so wuschig.

Kurz zusammengefasst:

  1. Basis von allem ist DNSSEC.
  2. TLSA-Records sind DANE.
  3. Postfix kann TLSA-Records auswerten, ohne selbst welche für sein System zu haben.

Weiterführend:

Fragen? Einfach melden.

Postfix: TLS-Protokoll und Cipher-Infos im E-Mail-Header anzeigen​

Als kleiner Postfix Tipp am Rande…. Wenn man gerade mit seinen TLS Einstellungen „herumspielt“, kann es helfen die groben Informationen für jede E-Mail nicht immer aus dem Logfile sammeln zu müssen.

Postfix bietet die schnelle Möglichkeit, genau diese Informationen einfach mit in den Mail Header zu packen.

Folgende Konfigurationserweiterung ist dafür nötig:

/etc/postfix/main.cf:
smtpd_tls_received_header = yes

Ab diesem Moment finden sich Informationen wie die unten stehende in eingehenden E-Mails.

So long….

Received: from mx01.domain.de (mx01.domain.de [1.2.3.4])
    (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits))
    (No client certificate requested)
    by smtp.kernel-error.de (Postfix) with ESMTPS id 245478112D9
    for <kernel-error@kernel-error.com>; Wed, 17 Dec 2014 05:15:10 +0100 (CET)

Siehe auch: Client-Initiated Renegotiation deaktivieren

Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑