Ist TLS 1.3 noch Draft? {erledigt}

[GwenDragon]

TLS 1.3 ist doch offiziell 2018 eingeführt worden, oder täusch ich mich.

Ich frage auch, weil Browser eine völlig kaputte Implementation von TLS 1.3 bei Client Auth (Post-Handshake Authentication, PHA) mit SSL-Zertifikaten haben. Liegt das an BoringSSL und NSS?
/edit: Seit 2–3 Jahren ignorieren Mozilla & Chromium das Problem obwohl Bugs gemeldet wurden.

Interessanterweise ist das bei Perls IO::Socket::SSL et. al. nicht defekt, da klappt PHA ohne murren bei TLS 1.3.
Bei Python hab ich das noch nicht getestet.

 

[Joe User]

TLS 1.3 ist doch offiziell 2018 eingeführt worden, oder täusch ich mich.

https://datatracker.ietf.org/doc/html/rfc8446 (August 2018)

https://bugzilla.mozilla.org/show_bug.cgi?id=1611521 habe ich gefunden, wobei dort noch eine Smartcard im Spiel ist und das Clientcert vermutlich in einem veralteten/inkompatiblen Format vorliegt.

Zumindest liegt es nicht an Apache, denn der hat es (wie auch cUrl) korrekt implementiert.

 

[GwenDragon]

Am erzeugten Cert liegt es nicht. Mit Nitrokey, Yubikey, OpenSSL oder XCA erzeugte Client-Certs laufen bei TLS 1.2 korrekt, aber nicht mit TLS 1.3. Und runterstufen auf 1.2 kann ich nicht, Vorgabe des Kunden ist 1.3.

Und ich hab gerade auf Windows 11 noch mit Python 3.10 getestet, es kann PHA mit Client-Cert auch korrekt mit TLS 1.3.

Also ist das doch Browsermurks. Mist. Also kann man derzeit TLS 1.3 + Client-Certs vergessen und muss auf eine andere Auth umsteigen. Es nervt.

Nur Firefox nehmen, der lässt sich per about:config breit schlagen, um mit PHA zu laufen?
Oder doch noch eine Idee zur Lösung?

 

[Joe User]

RFC 8740: Using TLS 1.3 with HTTP/2

This document updates RFC 7540 by forbidding TLS 1.3 post-handshake authentication, as an analog to the existing TLS 1.2 renegotiation restriction.

datatracker.ietf.org

1511989 - consider enabling TLS 1.3 post-handshake authentication if/when NSS implements it

RESOLVED (dueno) in Core - Security: PSM. Last updated 2023-10-30.

bugzilla.mozilla.org

1637754 - Implement RFC 8740 "Using TLS 1.3 with HTTP/2"

UNCONFIRMED (nobody) in Core - Security: PSM. Last updated 2024-06-05.

bugzilla.mozilla.org

911653 - chromium - An open-source project to help move the web forward. - Monorail

bugs.chromium.org

 

[GwenDragon]

@Joe User Danke.
Ist mir aber bekannt. Hätte ich in der Zwischenzeit mal sagen sollen. Entschuldige.

HTTP/2 ist auf den Servern nicht aktiviert, bei denen PHA mit TLS 1.3 streikt ist.

Muss ich wohl abwarten bis die Chromium-Entwickler das beheben und Firefox security.tls.enable_post_handshake_auth auf true (ob per Default oder User-Änderung) gesetzt hat.

In der Zwischenzeit empfehle ich Firefox zu nehmen und in about:config security.tls.enable_post_handshake_auth auf true zu setzen.
Für Chromium sehe ich bislang im Bugtracker über die Jahre keinerlei Absicht was zu ändern.

 

[Joe User]

Für Chromium sehe ich bislang im Bugtracker über die Jahre keinerlei Absicht was zu ändern.

Ich vermute mal, dass das für alle Browser gilt, da PHA ab HTTP/2 ohnehin nicht mehr erlaubt ist (RFC 8740) und HTTP/2 bzw. HTTP/3 bereits jetzt auf den meisten Servern eingesetzt wird und HTTP/1.1 immer unbedeutender wird. Somit lohnt sich der Aufwand für die Browser-Devs nicht wirklich und sie widmen sich verständlicherweise lieber wichtigeren Problemen.

Vielleicht wird dieses Problem ja noch für HTTP/3 gelöst...

 

[GwenDragon]

Somit lohnt sich der Aufwand für die Browser-Devs nicht wirklich und sie widmen sich verständlicherweise lieber wichtigeren Problemen.

Missversteh ich da was? Post-Handshake Authentication über TLS 1.3 und HTTP/1.1 ist unwichtig?
Du bist nicht der Meinung das sowas gelöst gehört in Browsern?

Wie machst du das denn dann bei Browsern und Client-Auth per SSL-Zertifikat auf nem Apache?

 

[Joe User]

Missversteh ich da was? Post-Handshake Authentication über TLS 1.3 und HTTP/1.1 ist unwichtig?

IMHO Ja, da HTTP/1.1 ein Auslaufmodell ist und die Ressourcen eher in HTTP/2 und HTTP/3 fliessen sollten.
Wer Client-Cert-Auth wirklich zwingend benötigt, der muss halt ganz auf HTTP/1.1+TLS1.2 zurückgehen, was aber nur in internen Netzen (z.B. Auth zwischen Proxy und Backend) Sinn macht, extern sind HTTP/2+TLS1.3 mit anderen Auth-Mechanismen oder VPN praktikabler.
Zugegeben, das ist eine extreme Sichtweise, aber der Fortschritt überholt sich hier gerade selbst, so dass derartige Sichtweisen nötig sind

Wie machst du das denn dann bei Browsern und Client-Auth per SSL-Zertifikat auf nem Apache?

Ich nutze es schlicht nicht und wenn ich die extrem wenigen Bugreports und sonstigen Ressourcen zu dem Problem betrachte, dann scheint die Zahl der Betroffenen doch sehr gering zu sein.


BTW: Ich plane derzeit möglichst ab nächstem Jahr nach und nach bei meinen Projekten HTTP/1.1 abzuschalten und nur noch HTTP/2 bzw. HTTP/3 einzusetzen. Und ab 2024 möchte ich auch gerne weitestgehend auf TLS1.2 verzichten, mal schauen...

 

[GwenDragon]

Ja, da HTTP/1.1 ein Auslaufmodell ist und die Ressourcen eher in HTTP/2 und HTTP/3 fliessen sollten.

Ah, so meinst du das. Kann ich teilweise verstehen, vom Standpunkt der Weiterentwicklung der Standards auch richtig so.

wenn ich die extrem wenigen Bugreports und sonstigen Ressourcen zu dem Problem betrachte, dann scheint die Zahl der Betroffenen doch sehr gering zu sein.

Ja, von dem Problem scheinen sehr selten Anwender bzw. root Admins betroffen zu sein.

Ich plane derzeit möglichst ab nächstem Jahr nach und nach bei meinen Projekten HTTP/1.1 abzuschalten und nur noch HTTP/2 bzw. HTTP/3 einzusetzen. Und ab 2024 möchte ich auch gerne weitestgehend auf TLS1.2 verzichten, mal schauen...

Ich werde das auch überlegen, nur noch die modernen HTTP-Protokolle zuzulassen, wo es geht.

extern sind HTTP/2+TLS1.3 mit anderen Auth-Mechanismen oder VPN praktikabler

Ja, so ausweichen ist auch möglich. Den Kunden kann eine:r ja nahe bringen, dass alles andere veraltet ist.



Danke für deine Ausführungen.