Datenhaufen zu IT und Elektronik.

Schlagwort: Security (Seite 2 von 4)

Keine RSA-Zertifikate mehr: Was du jetzt wissen musst

….. naja, fast :-/

Wir sind alle in 2020 angekommen und so laaaannngggsssaaammmm könnte man von 4096 bit RSA Zertifikaten mal auf >= 256 bit EC Zertifikate wechseln, oder? Bringt mehr Sicherheit, die Schlüssel sind kleiner und so schneller gerechnet und alle gängigen Browser machen es ebenfalls schon ein paar Jahre.

Vor knapp 6 Monaten habe ich daher einen Satz neuer Schlüssel erstellt und diese schon mal in mein HPKP Header eingebunden, damit der Key-Rollover gut funktioniert. Heute habe ich zu den Schlüsseln Zertifikate gebaut, diese von einer CA signieren lassen und alles eingebunden.

Bei meinem nginx vollkommen schmerzfrei. Einfach die neuen Schlüssel hinterlegt und die Cipherliste von allem RSA-Zeug befreit:

ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256;

Restart vom nginx und zack, schon läuft alles!

Bei den Webseiten also überhaupt kein Problem. Etwas anders ist es bei E-Mail! Postfix macht es natürlich schon, ach LANGE.. Aber ein Microsoft Exchange 2016 in der (weiter weiter fertigstellen) Installation natürlich nicht. Wenn ich also von so einem System weiterhin E-Mails erhalten möchte (ja will ich und per RSA kann so ein System es auch in ~sicher~), muss ich weiterhin etwas auf RSA Basis anbieten.

Jetzt haben sich die Entwickler(innen) bei Postfix schon so etwas gedacht und bieten dieses in der Konfiguration an. Also RSA Keys/Zertifikate? Richtig… OK, das ist nichts besonders aber das es in Kombination mit ECD Keys/Zertifikaten möglich ist. Ach schaut einfach mal die Konfiguration:

smtpd_tls_eckey_file = /usr/local/etc/postfix/ec-postfix.key
smtpd_tls_eccert_file = /usr/local/etc/postfix/ec-postfix.pem
smtpd_tls_key_file = /usr/local/etc/postfix/postfix.key
smtpd_tls_cert_file = /usr/local/etc/postfix/postfix.pem

Ha, ist das nicht schön? smtpd_tls_eckey_ und smtpd_tls_key_?!? Der Server wirft jedem Client nun also zwei Serverzertifikate entgegen. Einmal EC und einmal RSA (ok man braucht also nun ebenfalls zwei Zertifikate).

Schaut mal:

➜  ~ testssl.sh -t smtp smtp.kernel-error.de:25
[....]
  Server Certificate #1
   Signature Algorithm          SHA256 with RSA
   Server key size              RSA 4096 bits
   Server key usage             Digital Signature, Key Encipherment
   Server extended key usage    TLS Web Server Authentication, TLS Web Client Authentication
   Serial / Fingerprints        4F7A9159AEED9414B7D542ED / SHA1 908FD237EF13A6048077082023C4CDE092F55F33
                                SHA256 74E3984BD5F9FAC26375DAEA6F0326229A0F42AC2EE53088A73DFD5F65107FA9
   Common Name (CN)             *.kernel-error.de 
   subjectAltName (SAN)         *.kernel-error.de kernel-error.de 
   Issuer                       AlphaSSL CA - SHA256 - G2 (GlobalSign nv-sa from BE)
   Trust (hostname)             Ok via SAN wildcard (same w/o SNI)
   Chain of trust               Ok   
   EV cert (experimental)       no 
   ETS/"eTLS", visibility info  not present
   Certificate Validity (UTC)   403 >= 60 days (2020-02-26 14:19 --> 2021-04-05 13:58)
   # of certificates provided   2
   Certificate Revocation List  http://crl2.alphassl.com/gs/gsalphasha2g2.crl
   OCSP URI                     http://ocsp2.globalsign.com/gsalphasha2g2
   OCSP stapling                not offered
   OCSP must staple extension   --
   DNS CAA RR (experimental)    available - please check for match with "Issuer" above
                                iodef=mailto:kernel-erro@kernel-error.de, issue=comodoca.com, issue=geotrust.com, issue=globalsign.com, issue=letsencrypt.org, issue=thawte.com
   Certificate Transparency     yes (certificate extension)

  Server Certificate #2
   Signature Algorithm          SHA256 with RSA
   Server key size              EC 256 bits
   Server key usage             Digital Signature, Key Agreement
   Server extended key usage    TLS Web Server Authentication, TLS Web Client Authentication
   Serial / Fingerprints        24E25E2F3D57B41671392F25 / SHA1 763EE6D52D3CF0237D9858F27EDF42EF4696B1E2
                                SHA256 9C4C0FCE32BA7E8AEAF17210B509D871D6B2EF237E0E887D7190F28F28011143
   Common Name (CN)             *.kernel-error.de 
   subjectAltName (SAN)         *.kernel-error.de kernel-error.de 
   Issuer                       AlphaSSL CA - SHA256 - G2 (GlobalSign nv-sa from BE)
   Trust (hostname)             Ok via SAN wildcard (same w/o SNI)
   Chain of trust               Ok   
   EV cert (experimental)       no 
   ETS/"eTLS", visibility info  not present
   Certificate Validity (UTC)   365 >= 60 days (2020-02-26 13:37 --> 2021-02-26 13:37)
   # of certificates provided   2
   Certificate Revocation List  http://crl2.alphassl.com/gs/gsalphasha2g2.crl
   OCSP URI                     http://ocsp2.globalsign.com/gsalphasha2g2
   OCSP stapling                not offered
   OCSP must staple extension   --
   DNS CAA RR (experimental)    available - please check for match with "Issuer" above
                                iodef=mailto:kernel-erro@kernel-error.de, issue=comodoca.com, issue=geotrust.com, issue=globalsign.com, issue=letsencrypt.org, issue=thawte.com
   Certificate Transparency     yes (certificate extension)
[....]

Jetzt kann noch ein 2016 Microsoft Exchangeserver einliefern und auch die „coolen Kinder“. Was mache ich wohl 2021? Exchange 2016 ignorieren?!?!


Kleines Update, da es Fragen gab..

Natürlich sollte man seine ciphers in einer sinnigen Reihenfolge für seinen Postifx konfigurieren. Kommen sie in der Reihe erst nach den RSA ciphern wird es natürlich fast nie benutzt *kopfschüttel*. Leute bitte kein copy & paste, mitdenken!

Ein Beispiel für die cipherliste wäre:

tls_high_cipherlist = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256

TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256 sind dabei für TLS1.3

ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256 sind für den gewünschten ECD-Key

ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256 sind dann für TLS 1.2 RSA Verbindungen.

Kommt nun ein Client/einliefernder Mailserver, dann wird dieser dank:

tls_preempt_cipherlist = yes

Die vom Server übermittelte cipherliste durchgehen und die erste für beide funktionierende Kombination benutzen.

RSA Verbindungen sehen dann so aus:

Mar  3 08:24:13 smtp postfix/smtpd[49650]: Anonymous TLS connection established from RSA-mailserver[1.2.3.4]: TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)

ECD Verbindungen so:

Mar  3 08:23:53 smtp postfix/smtpd[49650]: Anonymous TLS connection established from EDC-mailserver[5.6.7.8]: TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)

Einfach, oder?

DNS over HTTPS (DoH) mit BIND: So richtest du es ein

Meine Tests mit DoT (DNS over TLS) habe ich bereits vor einiger Zeit gestartet.  DoT DNS over TLS mit Bind, stunnel und Android 9 Dieses arbeitet noch immer ganz fein auf meinem Smartphone. DoT gefällt mir noch immer um einiges besser als DoH aber auch hier wollte ich nun einmal einen Versuch starten. Zusammen mit nginx und einem etwas angepassten doh-proxy läuft dieses nun auf dem gleichen System.

Im Firefox ist es schnell aktiviert https://ns1.kernel-error.de/dns-query…

DoH DNS over HTTPS Firefox

Es funktioniert auch, so richtig glücklich macht es mich aber nicht! Natürlich ist die Umsetzung nur etwas für einen kleinen privaten Test. „Schnell“ genug ist es ebenfalls! Zumindest zum Surfen im Internet, dennoch wäre mir eine saubere Implementierung von DoT im resolver vom OS viel lieber. So wie bereits ab Android 9 zu sehen. Vielleicht ändert sich mein Gefühl ja etwas zusammen mit QUIC (HTTP/3)?!?

Postfix: Verschleierung nur für SASL-Benutzer einrichten

Wie man bei allen ausgehenden E-Mails dafür sorgt, dass die Client IP Adresse sowie der eingesetzte Mailclient vom Postfix verschleiert wird… Ja dieses habe ich bereits geschrieben. Postfix soll verschleiern…

Nun kann es dennoch Sinn ergeben dieses nicht für jede E-Mail zu tun, welche den Mailserver verlässt. Wenn man dieses nur auf E-Mails anwenden möchte, welche von angemeldeten Benutzern versendet werden, funktioniert es wie folgt.

Man erstellt in der master.cf vom Postfix einen neuen Service:

anonym unix n       -       -       -       0       cleanup
  -o header_checks=pcre:/usr/local/etc/postfix/header_cleanup

Nun sorgt man in der gleichen Konfigurationsdatei noch dafür, dass am Ende vom Submission und smtps Service in diesen neuen Service gesprungen wird:

submission inet n       -       n       -       -       smtpd
[...]
  -o cleanup_service_name=anonym
[...]
smtps     inet  n       -       n       -       -       smtpd
[...]
  -o cleanup_service_name=anonym

Der Inhalt unserer /usr/local/etc/postfix/header_cleanup ist dabei weiterhin gleich:

/^(Received: from)[^\n]*(.*)/ REPLACE $1 ::88 (YOUR MOM [::88])$2
/^X-Originating-IP/ IGNORE
/^User-Agent*(.*)/ REPLACE User-Agent: YOUR MOMS MAILER
/^X-Mailer*(.*)/ REPLACE X-Mailer: YOUR MOMS MAILER

Nach einem Restart vom Postifx hat man nun den gewünschten Zustand. Natürlich dürfen nun die smtp_header_checks nicht mehr in der main.cf sein:

#smtp_header_checks = pcre:/usr/local/etc/postfix/header_cleanup

Viel Spaß

FreeBSD OpenSSH: OS-Banner sicher entfernen

Im Standard ist der OpenSSH Server auf einem FreeBSD so konfiguriert, dass er jeweils die aktuelle Betriebssystemversion mit ausliefert.

Dieses sieht dann im Beispiel so aus:

telnet bsd01.testsystem 22
Trying 1.2.3.4...
Connected to bsd01.testsystem.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.8 FreeBSD-20180909

Um hier zumindest die genaue OS Version zu verstecken reicht folgendes in der /etc/sshd_config:

#VersionAddendum FreeBSD-20180909
VersionAddendum DemMeisterSeinRennAuto

Testet man nun noch mal sieht man nur noch die Version:

telnet bsd01.testsystem 22
Trying 1.2.3.4...
Connected to bsd01.testsystem.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.8 DemMeisterSeinRennAuto

Auf einem Debian basierten System wäre es hingegen:

DebianBanner no

DNS over TLS (DoT) mit BIND, Stunnel und Android 9 einrichten

Die eigenen DNS Anfragen über eine Verschlüsselte Verbindung an einen DNS Server zu schicken welchem man vertraut, dieses liest sich schon gut oder? Keiner verfolgt mein Surfverhalten und zusammen mit DNSSEC schiebt mir so schnell keiner falsche Records unter 🙂

Am ehesten vertraue ich meinem eigenen DNS Server (ns1.kernel-error.de). Auf diesem arbeitet ein Bind und vor diesen habe ich für DoT stunnel gestellt. Die Konfiguration vom stunnel sieht dabei grob wie folgt aus:

[dns4]
accept = 853
connect = 127.0.0.1:53
cert = /usr/local/etc/stunnel/ssl/dns.crt
key = /usr/local/etc/stunnel/ssl/dns.key
CAfile = /usr/local/etc/stunnel/ssl/ca.crt
ciphers = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
options = NO_SSLv2
options = NO_SSLv3
options = NO_TLSv1
options = NO_TLSv1.1
options = CIPHER_SERVER_PREFERENCE
options = DONT_INSERT_EMPTY_FRAGMENTS
renegotiation = no
TIMEOUTclose = 0

[dns6]
accept = 2a03:4000:38:20e::53:853 connect = ::1:53 cert = /usr/local/etc/stunnel/ssl/dns.crt key = /usr/local/etc/stunnel/ssl/dns.key CAfile = /usr/local/etc/stunnel/ssl/ca.crt ciphers = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 options = NO_SSLv2 options = NO_SSLv3 options = NO_TLSv1 options = NO_TLSv1.1 options = CIPHER_SERVER_PREFERENCE options = DONT_INSERT_EMPTY_FRAGMENTS renegotiation = no 

Die TLS Konfiguration ergibt dabei nun folgendes Bild: https://tls.imirhil.fr/tls/ns1.kernel-error.de:853

Auf einem Android 9 Gerät kann ich also nun unter den Einstellungen ==> Netzwerk & Internet ==> Erweitert ==> Privates DNS meinen Nameserver eintragen.

Screenshot der Konfigurationseinstellungen für DoT auf einem Android 9.

Jetzt sieht mir keiner mehr beim meinen DNS Abfragen zu 😀

Postfix: Client-Initiated Renegotiation sicher deaktivieren

client-initiated renegotiation beim SMTPD Server kann für DDoS Angriffe ausgenutzt werden. Die einzelnen TLS/SSL Optionen lassen sich über die recht gleichnamige Option im Postfix ein und ausschalten. Gibt es noch keinen mappenden Namen kann die jeweilige Option auch ein/ausgeschaltet werden mit dem jeweiligen Hexwert. Genau Infos findet man hier: http://www.postfix.org/postconf.5.html#tls_ssl_options

If the value of the parameter is a hexadecimal long integer starting with "0x", the options corresponding to the bits specified in its value are enabled (see openssl/ssl.h and SSL_CTX_set_options(3))

Für ein Postfix  3.3 und einem OpenSSL ab Version 1.1.1 ist der passende Hexwert 0x40000000.

Die Option setzt man wie so oft in der main.cf:

root@smtp:/ # postconf  tls_ssl_options
tls_ssl_options = 0x40000000

Ab Postfix >=3.4 gibt es: NO_RENEGOTIATION

Fragen? Dann fragen 🙂

Postfix: E-Mail-Verschleierung gezielt einrichten

Um sich vor Angreifern zu schützen ist ein ganz gutes Mittel, dem Angreifer nicht direkt zu erzählen welche Software genau und in welcher Version man diese einsetzte. Bei Webservern ist dieses fast überall gängige Praxis, meist bekommt man nur noch das Produkt angezeigt. Oder wie bei einem Kollegen nur YOUR MUM. Warum ist das nun ggf. hilfreich? Ganz simples Beispiel. Man setzt einen verwundbaren Mailclient auf seinem Desktop ein, oder hat einen phpmailer (*würk*) in seiner Webseite eingebaut. Versendet man über diesen nun eine E-Mail schreibt er meist seinen eigenen Namen mit der eingesetzten Version in die E-Mail Header. Copy & Paste fertig für einen möglichen Angreifer, damit er die „Bugzilla Page“ nach den brauchbarsten Löchern durchwühlen kann. Dann muss er nur noch eine passende präparierte E-Mail schreiben und der Client wird leiden.

Ähnlich ist es mit den IP Adressen. Die IP Adresse des Clients landet ebenfalls in den Mail Headern. So hat der Angreifer schon mal eine Idee über die Netztopologie oder es gibt ihm ggf. eine Möglichkeit den Benutzer durch verschiedene Netze zu „tracken“.

Beides lässt sich über die smtp_header_checks etwas entschärfen. Über diesen Weg kann man per RegEx bestimmte Mail Header heraussuchen und löschen oder nach eigenem Ermessen ersetzten.

Hier der Eintrag für die main.cf:

root@smtp:/usr/local/etc/postfix # postconf smtp_header_checks
smtp_header_checks = pcre:/usr/local/etc/postfix/header_cleanup

Hier das Beispiel für die /usr/local/etc/postfix/header_cleanup:

/^(Received: from)[^\n]*(.*)/ REPLACE $1 ::88 (YOUR MOM [::88])$2
/^X-Originating-IP/ IGNORE
/^User-Agent*(.*)/ REPLACE User-Agent: YOUR MOMS MAILER
/^X-Mailer*(.*)/ REPLACE X-Mailer: YOUR MOMS MAILER

Im Ergebnis sieht es dann wie folgt aus:

[...]
Received: from ::88 (YOUR MOM [::88])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.kernel-error.de (Postfix) with ESMTPSA id 7458E7B802
	for <wurst@example.com>; Wed, 27 Mar 2019 21:44:10 +0100 (CET)
[...]
X-Mailer: YOUR MOMS MAILER
[...]

Ganz wichtig ist natürlich die Frage ob dabei Signaturen gebrochen werden; das werden sie nicht. Auch DKIM usw. nicht.

Dann mal viel Spaß!

TLS 1.3 für Postfix und Dovecot: So richtest du es ein

Sowohl mein Postfix als auch der Dovecot sprechen nun sauber TLS 1.3.

Wenn Postfix sowie Dovecot sauber gegen OpenSSL 1.1.1 gebaut sind fehlen nur zwei Configänderungen.

Dovecot spricht es meist sofort wenn man hier die minimale TLS Version ind der 10-ssl.conf:

ssl_min_protocol = TLSv1.1

Beim Postfix setzt man einfach die zu nutzenden TLS Versionen in der main.cf:

smtpd_tls_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtp_tls_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtpd_tls_mandatory_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtp_tls_mandatory_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1, !SSLv2, !SSLv3

Schon spricht Postfix TLS 1.3 mit anderen Server und beide Dienste sind in der Lage dieses mit Clients zu sprechen!

Test für smtp:

$ openssl s_client -starttls smtp -crlf -connect smtp.kernel-error.de:25
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3944 bytes and written 404 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

Test für imap:

$ openssl s_client -connect imap.kernel-error.de:993 -crlf
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3944 bytes and written 404 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

So sieht ein Logfile doch schon viel mehr nach 2019 aus, oder?

Feb 15 16:05:43 smtp postfix/smtp[7475]: Verified TLS connection established to mx1.freebsd.org[2610:1c1:1:606c::19:1]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256

Bei Fragen, einfach fragen 🙂

TLS 1.3 ist da!

Im August wurde TLS 1.3 auf der IETFE-Tagung als fertig beschlossen 😀 Damit haben sich aber alle wirklich Zeit gelassen! OpenSSL hat am 11.09.2018 die Version 1.1.1 (LTS) freigegeben. Am 12.09.2018 ist diese in die FreeBSD Ports gekommen und:

root@www:/ # /usr/local/bin/openssl version
OpenSSL 1.1.1 11 Sep 2018

Fehlt also nur noch ein Eintrag in der make.conf und schon lässt sich nginx sauber dagegen bauen und alles automatisch mit portmaster auf dem neusten Stand halten 🙂

/etc/make.conf
DEFAULT_VERSIONS+= ssl=openssl111

Schaut mal nach, die meisten machen wohl jetzt schon TLS 1.3 beim lesen dieser Zeilen ^^

Qualys und SSL Labs hängen leider noch etwas nach, hier wird noch auf/gegen die Draft Version geprüft (For TLS 1.3 tests, we currently support draft version 28.). Aber ich wette das wird nicht mehr lange dauern!

Kleines Update, die HIGH-TECH Bridge Jungs testen sauber auf TLS 1.3.

Ich wurde gerade drauf hingewiesen, dass die Developer Version von ssllabs TLS 1.3 schon sauber testet. Danke Jost 😀

https://dev.ssllabs.com/ssltest/analyze.html?d=www.kernel%2derror.de&s=2a01%3a4f8%3a161%3a3ec%3a0%3a0%3a0%3a443&hideResults=on&latest

Kein TLS 1.0 mehr

Da TLS 1.0 zum 30.06.2018 aus dem PCI Support fliegt (was nach knapp 19 Jahren auch mal ok ist), habe ich bei mir gerade überall den TLSv1.0 Support deaktiviert. Nein ich möchte nicht PCI konform sein… Damit sorge ich nun wieder einmal dafür, dass man mich mit einiger alter Software/Hardware und Betriebssystemen nicht mehr erreicht. Für mich ganz persönlich kann ich damit sehr gut leben 🙂 Wer jetzt noch mit so einer „Kiste“ unterwegs ist…. Na, der ist Kummer gewohnt!

Wen es interessiert der kann mit Qualys SSL Labs alles Mögliche scannen und auch direkt sehen welche Systeme wohl bei einem selbst nicht mehr funktionieren werden.

Zusätzlich spiele ich schon länger mit dem Gedanken bei meinem Mailserver Übertragungen ohne Transportverschlüsselung komplett zu verbieten. Für mich selbst kann ich es ja frei entscheiden. Lieber keine E-Mail als eine ohne Krypto! Ich werde mal auswerten wie denn das Verhältnis ist und welche E-Mails mich nicht mehr erreichen würden. Dann sehen wir mal weiter! Ich bin nur deswegen etwas zögerlich, weil mir in der Vergangenheit immer mal wieder Gegenstellen unter die Nase gekommen sind, bei welchen ich fest davon ausgegangen wäre, dass sie TLS einsetzten. Städte, Krankenhäuser, Ärzte, Schulen, IT-Security Dienstleister usw. usw… Hier scheint noch immer Unverständnis darüber zu herrschen, für was man denn wohl bitte dieses TLS braucht. Der Dienstleister meiner Heimatstadt begrüßt mich zumindest inzwischen mit einem Cisco Demo Zertifikat. *kopfschüttel* da hat der Admin nach meinen letzten Fragen zu dem Thema wohl den „security ON Button“ in seiner GUI gefunden O_o

Wobei… Mein Brötchengeber setzt auf einen eigenen Exchange Server bei welchem zuletzt 3DES Cipher abgeschaltet werden mussten. Das macht keinen Spaß und keinen Sinn. Windows-Admins scheinen hier schmerzfrei zu sein, hm?

TLS 1.3, das wäre ja mal was 🙂 ich warte schon mit schwitzigen Fingern. Zumindest sind wir schon mal bei Beta 5 (29.05.2018). Die Beta 1 vom 20.03 habe ich mir zuletzt in einer Jail angesehen und damit sehr zufrieden etwas herumprobiert. Für so etwas bin ich einfach zu ungeduldig. Ist das bei euch anders? Wollt ihr lieber noch TLSv1.0 haben?

TLS 1 ist tot und damit ist es dann jetzt weg, egal ob im stunnel:

;/usr/local/etc/stunnel/conf.d/tls.conf
[...]
options = NO_SSLv3
options = NO_TLSv1
ciphers = ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DHE-RSA-AES256-SHA256
[...]

Oder unter Postfix:

#/usr/local/etc/postfix/main.cf
[...]
smtp_tls_protocols = TLSv1.2, TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtp_tls_ciphers = high
smtp_tls_mandatory_exclude_ciphers = MD5, DES, ADH, RC4, PSD, SRP, 3DES, eNULL, aNULL
smtp_tls_exclude_ciphers = MD5, DES, ADH, RC4, PSD, SRP, 3DES, eNULL, aNULL
smtp_tls_security_level = dane
smtp_dns_support_level = dnssec
smtp_tls_loglevel = 1
smtp_tls_mandatory_protocols = TLSv1.2, TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtp_tls_mandatory_ciphers = high
tls_preempt_cipherlist = yes
tls_random_source = dev:/dev/urandom
smtpd_tls_loglevel = 1 
smtpd_tls_received_header = yes
smtpd_use_tls = yes
smtpd_tls_security_level = may
smtpd_tls_auth_only = yes
smtpd_tls_key_file = /usr/local/etc/postfix/postfix.key
smtpd_tls_cert_file = /usr/local/etc/postfix/postfix.pem
smtpd_tls_session_cache_timeout = 3600s
smtpd_tls_mandatory_exclude_ciphers = MD5, DES, ADH, RC4, PSD, SRP, 3DES, eNULL, aNULL
smtpd_tls_exclude_ciphers = MD5, DES, ADH, RC4, PSD, SRP, 3DES, eNULL, aNULL
smtpd_tls_mandatory_ciphers = high
smtpd_tls_ciphers = high
smtpd_tls_mandatory_protocols = TLSv1.2, TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtpd_tls_protocols = TLSv1.2, TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtpd_tls_dh1024_param_file = /usr/local/etc/postfix/dh2048.pem
[...]

Oder auch im Dovecot:

#/usr/local/etc/dovecot/conf.d/10-ssl.conf
[...]
ssl = required
ssl_dh_parameters_length = 4096
ssl_protocols = !SSLv3 !SSLv2 !TLSv1
ssl_cipher_list = AES128+EECDH:AES128+EDH
ssl_prefer_server_ciphers = yes
[...]

Selbstverständlich auch im Nginx:

#/usr/local/etc/nginx/nginx.conf
[...]
ssl_stapling on;
ssl_stapling_verify on;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
ssl_ecdh_curve secp521r1:secp384r1:secp256k1;
ssl_dhparam /usr/local/etc/nginx/ssl/dhparam.pem;
ssl_protocols TLSv1.1 TLSv1.2;
[...]

Und so weiter und so weiter 🙂

« Ältere Beiträge Neuere Beiträge »

© 2025 -=Kernel-Error=-

Theme von Anders NorénHoch ↑