Keine RSA Zertifikate mehr \o/ ....
- Details
- Erstellt: Mittwoch, 26. Februar 2020 15:37
..... 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?
