-=Kernel-Error=-

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 6 von 9)

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

6. Februar 2015 / / Keine Kommentare

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

2. Februar 2015 / / Keine Kommentare

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

16. Januar 2015 / / Keine Kommentare

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​

17. Dezember 2014 / / Keine Kommentare

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.

Postfix: EECDH mit 2048-Bit DH und spezifischen Kurven konfigurieren​

17. Dezember 2014 / / Keine Kommentare

Kex exchange basierend auf EECDH (diese elliptischen Kurven nach DH Diffie-Hellmann), sollte ja inzwischen ein alter Hut sein. Ich gehe also mal von einer aktivieten und funktionsfähigen Konfiguration aus (irgendwo habe ich das wohl auch schon mal beschrieben).

Im Standard läuft dieses nun bei 1024bit also EECDH mit ca. 128bit (smtpd_tls_eecdh_grade=strong). Möchte man alles auf 2048bit EECDH mit ca. 192bit aufbohren… Was ca. die doppelte „Sicherheit“ zu EECDH mit 128bit bedeutet, dann ist folgendes zu erledigen.

Zuerst benötigen für eine große prime group:

$ cd /etc/postfix
$ openssl dhparam -out dh_2048.tmp 2048 && mv dh_2048.tmp dh_2048.pem
$ chmod 644 dh_2048.pem

Dann Postifix mitteilen, dass er sie bitte nutzten soll (ist kein Typo, gehört zur Option „smtpd_tls_dh1024_param_file„). 

/etc/postfix/main.cf:
    smtpd_tls_dh1024_param_file = /etc/postfix/dh2048.pem
    smtpd_tls_dh512_param_file = /etc/postfix/dh512.pem

Nun wechselt smtpd_tls_eecdh_grade von strong zu ultra und ich setzte noch die zu verwendende „Kurve“ fest.

/etc/postfix/main.cf:
    smtpd_tls_eecdh_grade = ultra
    tls_eecdh_strong_curve = prime256v1
    tls_eecdh_ultra_curve = secp384r1

Diese Aktion könne nicht ganz Schmerzfrei sein. Für privat und mein Testsystem sicher zu verantworten. Manche MSA (Mail SUbmission Agent) könnten damit Probleme bekommen. Hat also jemand ein Problem mit E-Mail zu senden, bitte melden.

So long….

Siehe auch: Perfect Forward Secrecy

Fragen? Einfach melden.

TLS_FALLBACK_SCSV Debian 7 Wheezy OpenSSL 1.0.1e to 1.0.1j Upgrade

9. Dezember 2014 / / Keine Kommentare

Veraltet: Debian 7 (Wheezy) hat seit 2018 keinerlei Support mehr. TLS_FALLBACK_SCSV ist seit Jahren in allen aktuellen OpenSSL-Versionen enthalten und muss nicht mehr manuell kompiliert werden.

Wer bei seinem Debian TLS_FALLBACK_SCSV im Apache nutzen möchte, muss im Grunde nur auf eine OpenSSL Version >=1.0.1j wechseln.

Einen direkten Backport gibt es dafür leider nicht, also selbst übersetzten. Dazu nutzt man einfachsten direkt den „Debian-Weg“.

Vorbereiten fürs Kompilieren:

$ cd /usr/src
$ apt-get install build-essential fakeroot
$ apt-get build-dep openssl

Herunterladen der aktuellen Version:

$ wget http://ftp.de.debian.org/debian/pool/main/o/openssl/openssl_1.0.1j-1.dsc
$ wget http://ftp.de.debian.org/debian/pool/main/o/openssl/openssl_1.0.1j.orig.tar.gz
$ wget http://ftp.de.debian.org/debian/pool/main/o/openssl/openssl_1.0.1j-1.debian.tar.xz

Auspacken des Archives und mit den Patchen „verknüpfen“:

$ dpkg-source -x openssl_1.0.1j-1.dsc

Ins neue Verzeichnis wechseln:

$ cd openssl-1.0.1j

Kompilieren und deb Pakete erstellen:

$ dpkg-buildpackage -us -uc -rfakeroot

Die neuen Pakete installieren:

$ cd ..
$ dpkg -i libssl1.0.0_1.0.1j-1_amd64.deb libssl1.0.0-dbg_1.0.1j-1_amd64.deb libssl-dev_1.0.1j-1_amd64.deb libssl-doc_1.0.1j-1_all.deb openssl_1.0.1j-1_amd64.deb

Kontrolle der Version:

$ openssl version
OpenSSL 1.0.1j 15 Oct 2014

ACHTUNG… Ab diesem Moment ist man natürlich selbst dafür verantwortlich Pachte zu installieren.

So long…..

Selbstverständlich profitieren damit alle Anwendungen, die auf OpenSSL aufbauen, so auch Postfix, Dovecot usw:

$ openssl s_client -connect smtp.kernel-error.de:465 -fallback_scsv -no_tls1_2
CONNECTED(00000003)
140410198378152:error:1407743E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert inappropriate fallback:s23_clnt.c:770:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 215 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

U-P-D-A-T-E

Denkt an die Updates.

$ openssl version
OpenSSL 1.0.1k 8 Jan 2015

Openfire: 404 Remote Server Not Found bei S2S-Verbindungen mit TLS

19. November 2014 / / Keine Kommentare

Seit ich für die Server-zu-Server-Verbindungen (S2S) auf meinem Openfire TLS erzwinge, melden sich andere Openfire-Admins: Ihre User bekommen ein „404 remote server not found“. Nachrichten gehen nur in eine Richtung durch. Wenn die Unterhaltung einmal läuft, klappt es für eine Weile. Ein seltsamer Effekt der nicht direkt auf die Ursache schließen lässt.

Das Problem

Das Problem liegt nicht am eigenen Server und nicht am DNS. Es liegt am Java-Keystore auf der Gegenseite. Java 6 und einige Versionen von Java 7 können die Zertifikatskette nicht korrekt aufbauen, wenn das Intermediate-Zertifikat der CA fehlt. Mein Server sendet es zwar mit, aber Java ignoriert es und versucht die Kette allein aus dem lokalen Truststore zu bauen.

Im warn.log des betroffenen Openfire findet man dann:

org.jivesoftware.openfire.server.ServerDialback - Error verifying key of remote server: jabber.kernel-error.de
org.jivesoftware.openfire.server.ServerDialback - ServerDialback: OS - Ignoring unexpected answer in validation

Die Lösung: Intermediate-Zertifikat importieren

Der Admin des betroffenen Openfire muss das Intermediate-Zertifikat der CA in den Java-Truststore importieren. Auf einem Debian-System:

cd /etc/openfire/security/
/etc/init.d/openfire stop

# Intermediate-Zertifikat der CA herunterladen
wget "https://example-ca.com/intermediate.crt"

# In den Truststore importieren
keytool -import -keystore truststore -alias ca-intermediate -file intermediate.crt
# Passwort: changeit (Java-Default)

/etc/init.d/openfire start

Das Prinzip gilt für jede CA. Das Intermediate-Zertifikat von der Webseite der CA herunterladen und mit keytool in den Truststore importieren. Falls das Zertifikat bereits vorhanden ist, meldet keytool das und man kann den Import überspringen.

Prüfen ob die Kette stimmt

Mit openssl lässt sich prüfen ob der Server das Intermediate-Zertifikat korrekt ausliefert:

openssl s_client -showcerts -connect jabber.example.com:5222 -starttls xmpp

Entscheidend ist die letzte Zeile der Ausgabe:

Verify return code: 0 (ok)

Steht dort etwas anderes, fehlt ein Zertifikat in der Kette oder das Intermediate-Zertifikat wird nicht mitgesendet. In dem Fall muss der Serverbetreiber seine Zertifikatskonfiguration in Openfire prüfen.

Wer schon dabei ist die TLS-Konfiguration anzufassen: Im Beitrag zu unsicheren Ciphern und Protokollen in Openfire steht wie man die veralteten Algorithmen loswird.

Fragen? Einfach melden.

Kein Jabber/XMPP mehr ohne Transportverschlüsselung

20. Oktober 2014 / / Keine Kommentare

Hallo zusammen,

wie ja bereits vor einiger Zeit angekündigt, habe ich heute TLS als Transportverschlüsselung zwischen den Server to Server Verbindungen erzwungen. Für die Clients s2c besteht dieser Zwang bereits seit langem, nun also auch für die Verbindungen zwischen der Server.

Ich habe mir natürlich vorher die Mühe gemacht, andere Serverbetreiber anzuschreiben, wenn ich zu ihnen keine verschlüsselte s2s Verbindung aufbauen konnte. Ein paar sind aktiv geworden, ein paar nicht. Die Anzahl der nicht verschlüsselten s2s Verbindungen ist denn noch verschwindend gering! Ich habe diese Verbindungen also hiermit bewusst „abgehängt“.

Sollte ihr also aktuell Probleme mit der Verbindung zu oder von meinem System haben, bitte einfach melden!

So long…

Siehe auch: Openfire: Unsichere TLS-Cipher deaktivieren

Fragen? Einfach melden.

SSLv3 ist tot…

15. Oktober 2014 / / Keine Kommentare

Veraltet: Dieser Beitrag ist eine Momentaufnahme von 2014. SSLv3 ist seit dem POODLE-Angriff in allen Browsern und Servern deaktiviert. TLS 1.0 und 1.1 wurden ebenfalls inzwischen aus allen Browsern entfernt.

Nein, ich habe es nicht überlesen. SSLv3 ist damit wohl hoffentlich tot!

Es ist ja nicht so als wenn man nicht schon davor gewarnt hätte. Oh was hat diese Meldung bei mir für gute Laune geführt! Wieder mal ein richtiger „Told you so“ Moment für mich.

Oh ja, was zum Lesen gefällig?

http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html

Bäääähhhhmmmm! Das schreit nach einem GIF!

Told you so reaction GIF about SSLv3 deprecation

Auf die schnell böse Dinge deaktivieren…

Postfix:

smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_ciphers=high
tls_high_cipherlist=EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA

Dovecot:

ssl_cipher_list = ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4
ssl_protocols = !SSLv2 !SSLv3

Apache2:

SSLEngine on
SSLProtocol +ALL -SSLv3 -SSLv2
SSLHonorCipherOrder On
SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4
SSLCompression off
Header always set Strict-Transport-Security "max-age=15552000"

mailgraph Graphen um DANE erweitern

9. August 2014 / / Keine Kommentare

Wie sich die grafische Logfile Auswertung für, unter anderem, Postfix um Dinge wie SPF, DKIM und DMARC erweitern lässt, habe ich ja bereits vor kurzem hier gezeigt: mailgraph Graphen um SPF, DMARC und DKIM erweitern

Seit ein paar Monaten ist an meinem Mailserver DANE aktiviert, sprich es lassen sich die TLSA RECORDS für die Zertifikate am Postfix gegen einen DNSSEC gesicherten DNS Server abgleichen.

In diesem Zuge habe ich selbstverständlich die ausgehende Prüfung am Postfix aktiviert. Mein Postfix nutzt nun also auch DANE um die Verbindung zu anderen Mailserver zu prüfen. Dabei gibt es im Grunde nur vier mögliche Ergebnisse einer Prüfung der TLS Verbindung:

Verified

Der bisher seltenste aber beste Fall. Denn die ausgehende Verbindung zum anderen Server ist per DANE gesichert. Das Zertifikat ist also nicht nur gültig sondern konnte auch mit den TLSA-RECORDS abgeglichen werden.

Trusted

Der OK Fall… Das Zertifikat ist gültig.

Anonymous

Na ja… Es gibt ein Zertifikat und dieses ist passend zum Hostname, es konnte aber keine Vertrauenskette gebildet werden.

Untrusted

Schlecht! Es gibt zwar ein Zertifikat und somit auch eine verschlüsselte Verbindung, denn noch stimmt etwas mit dem Zertifikat nicht. Es ist abgelaufen, passt nicht zum Hostname oder ähnliches.

Im Logfile findet es sich wie folgt:

Aug  3 18:34:08 servername postfix/smtp[1234]: Verified TLS connection established to mx01.domain.tld[1.2.3.4]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Aug  9 12:07:28 servername postfix/smtp[1234]: Trusted TLS connection established to mx01.domain.tld[1.2.3.4]:25: TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Aug  8 22:15:34 servername postfix/smtp[1234]: Anonymous TLS connection established to mx01.domain.tld[1.2.3.4]:25: TLSv1 with cipher ADH-AES256-SHA (256/256 bits)

Aug  7 21:48:48 servername postfix/smtp[1234]: Untrusted TLS connection established to mx01.domain.tld[1.2.3.4]:25: TLSv1.2 with cipher DHE-RSA-AES256-SHA256 (256/256 bits)

Was mich nun interessiert, ist die Tendenz der einzelnen Prüfungen. Wie sicher ist die Kommunikation zu anderen Mailservern wirklich, rein bezogen auf die Vertrauenswürdigkeit der eingesetzten Zertifikate. Eine schnelle Übersicht soll mir hier wieder der mailgraph liefern.

Den Mailgraph habe ich also, wie mit SPF, DKIM und DMARC ebenfalls, erweitert. Das nötige Patchset gibt es natürlich wieder unten. Dieses Mal habe ich darauf geachtet für die TLS Auswertung ein eigenes File für die RRD-Daten anzulegen. So kann ein bestehender Mailgraph einfach erweitert werden, ohne die vorhandenen Daten zu verlieren.

Heraus kommt am Ende dieser Graph.

Für interessiere finden sich die beiden nötigen Patchfiles hier:

/usr/sbin/mailgrapht

/usr/lib/cgi-bin/mailgraph.cgi

Viel Spaß! Bei Fragen, fragen.

Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑