SSL/TLS-Fehler bei sehr alten Browsern beim Verbinden mit Discourse

Unterstützung
1

Nach der Einrichtung meiner Discourse-Instanz mit der standardmäßigen Let’s Encrypt-Unterstützung erhielten einige meiner Benutzer die Meldung, dass ihr Browser keine sichere Verbindung zu Discourse herstellen kann. Ein von einem Benutzer erhaltenener Screenshot weist eindeutig auf einen SSL/TLS-Fehler hin. Es handelt sich um einen Fehler auf der Browserseite, und die Benutzer sehen überhaupt nichts von Discourse.

Aus dem Kontext lässt sich schließen, dass diese Benutzer über etwas ältere Betriebssysteme oder Browser verfügen. Ich vermutete zunächst, dass die Unterstützung von TLS 1.2 das Problem sei, doch der Benutzer, den ich überprüft habe, verwendet Safari 10.1.2 auf macOS (Version unbekannt). Laut Can I use... Support tables for HTML5, CSS3, etc sollte Safari TLS 1.2 bereits ab Version 7 unterstützen.

Gibt es einen anderen Grund als TLS 1.2, der dazu führen könnte, dass ein Browser oder Betriebssystem keine sichere Verbindung zu einer standardmäßigen Discourse-Installation herstellt, die die standardmäßige TLS-Unterstützung über Let’s Encrypt verwendet? Ich versuche herauszufinden, welche Fragen ich meinen Benutzern stellen sollte, um ihr Problem zu identifizieren und zu bestimmen, wo die Lösung liegen muss.

Als Workaround: Soweit ich das überblicke, wird der Standardverkehr von http auf https umgeleitet. Gibt es eine Möglichkeit, zunächst zu prüfen, ob der Browser TLS 1.2 unterstützt oder ob die Browser-/OS-Version höher als eine bestimmte Version ist, andernfalls bei http zu bleiben?

Hier ist die URL, falls Sie eine Idee haben, wie man prüfen kann, ob etwas falsch konfiguriert ist: https://forum.stadtteilgenossenschaft-wik.de

2

Sie können Ihre Website mit dem SSL Server Test testen. Die Testergebnisse enthalten einen Abschnitt namens „Handshake Simulation“, der Ihnen anzeigt, welche Browser-/Betriebssystemkombinationen funktionieren bzw. nicht funktionieren.

Mit dem neuesten Docker-Image sehe ich folgende TLS-Konfiguration:

image
image1035×597 26.1 KB

image
image1039×1060 95.2 KB

Sie können Ihre Benutzer auf https://www.ssllabs.com/ssltest/viewMyClient.html verweisen, um weitere Informationen über ihre Browser- und Betriebssystemversionen sowie unterstützte TLS-Versionen zu erhalten.

3

Vielen Dank für die ausführliche Antwort!

Ich habe den SSL-Server-Test durchgeführt und kann im Ergebnis nichts Falsches finden:

Die Ergebnisse sind, soweit ich das übersehe, identisch mit denen in deinem Beitrag.

Die einzigen Fehler traten bei alten Betriebssystemen mit Safari-Versionen (Safari 8+9) sowie bei alten Windows-Versionen mit IE 11 auf. Letzteres macht mir ein wenig Sorgen: Sollte IE 11 nicht von Discourse unterstützt werden und standardmäßig TLS 1.2 unterstützen?

Der Test enthält zudem keinen Test für Safari 10 auf dem ältesten noch unterstützten Betriebssystem, sodass auch dort möglicherweise Fehler auftreten…

4

Für Benutzer mit älteren Windows-Versionen müssen Sie wahrscheinlich die CBC-Verschlüsselungsverfahren aktivieren:

image
image792×252 60 KB

Als Nächstes sollten Sie diese Benutzer zu

schicken, um Informationen darüber zu erhalten, was ihr Browser unterstützt. Der einfachste Weg, ihr Ergebnis zu teilen, besteht wahrscheinlich darin, dass sie es als PDF drucken und Ihnen senden.

5

Vielen Dank, ich habe eine Antwort von meinem Benutzer erhalten. Er verwendet einen sehr alten iPod Touch:

SSL/TLS-Fähigkeiten Ihres Browsers
User Agent: Mozilla/5.0 (iPod; CPU iPhone OS 6_1_6 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10B500 Safari/8536.25

Protokollunterstützung

Ihr User Agent bietet eine gute Protokollunterstützung.

Ihr User Agent unterstützt TLS 1.2, was derzeit die empfohlene Protokollversion ist.

Obwohl das Gerät alt ist (und mir bewusst ist, dass es weit entfernt von den von Discourse minimal unterstützten Betriebssystem- und Browser-Versionen liegt), möchte ich ihm ermöglichen, zumindest eine Verbindung zur Website herzustellen und zu sehen, wie sein Browser mit modernem HTML und JavaScript zurechtkommt.

Dies ist der detaillierte TLS-Unterstützungsbericht:

Protokollfunktionen

130×100 755 Bytes

Protokolle

TLS 1.3 Nein
TLS 1.2 Ja
TLS 1.1 Ja
TLS 1.0 Ja
SSL 3 Ja
SSL 2 Nein

130×100 709 Bytes

Cipher Suites (in Reihenfolge der Präferenz)

TLS_EMPTY_RENEGOTIATION_INFO_SCSV ( 0xff ) -
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 ( 0xc024 ) SCHWACH 256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 ( 0xc023 ) SCHWACH 128
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA ( 0xc00a ) SCHWACH 256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA ( 0xc009 ) SCHWACH 128
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA ( 0xc007 ) UNSICHER 128
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA ( 0xc008 ) SCHWACH 112
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ( 0xc028 ) SCHWACH 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 ( 0xc027 ) SCHWACH 128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA ( 0xc014 ) SCHWACH 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA ( 0xc013 ) SCHWACH 128
TLS_ECDHE_RSA_WITH_RC4_128_SHA ( 0xc011 ) UNSICHER 128
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA ( 0xc012 ) SCHWACH 112
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 ( 0xc026 ) SCHWACH 256
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 ( 0xc025 ) SCHWACH 128
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 ( 0xc02a ) SCHWACH 256
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 ( 0xc029 ) SCHWACH 128
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA ( 0xc004 ) SCHWACH 128
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA ( 0xc005 ) SCHWACH 256
TLS_ECDH_ECDSA_WITH_RC4_128_SHA ( 0xc002 ) UNSICHER 128
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA ( 0xc003 ) SCHWACH 112
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA ( 0xc00e ) SCHWACH 128
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA ( 0xc00f ) SCHWACH 256
TLS_ECDH_RSA_WITH_RC4_128_SHA ( 0xc00c ) UNSICHER 128
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA ( 0xc00d ) SCHWACH 112
TLS_RSA_WITH_AES_256_CBC_SHA256 ( 0x3d ) SCHWACH 256
TLS_RSA_WITH_AES_128_CBC_SHA256 ( 0x3c ) SCHWACH 128
TLS_RSA_WITH_AES_128_CBC_SHA ( 0x2f ) SCHWACH 128
TLS_RSA_WITH_RC4_128_SHA ( 0x5 ) UNSICHER 128
TLS_RSA_WITH_RC4_128_MD5 ( 0x4 ) UNSICHER 128
TLS_RSA_WITH_AES_256_CBC_SHA ( 0x35 ) SCHWACH 256
TLS_RSA_WITH_3DES_EDE_CBC_SHA ( 0xa ) SCHWACH 112
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 ( 0x67 ) SCHWACH 128
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 ( 0x6b ) SCHWACH 256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA ( 0x33 ) SCHWACH 128
TLS_DHE_RSA_WITH_AES_256_CBC_SHA ( 0x39 ) SCHWACH 256
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA ( 0x16 ) SCHWACH 112
TLS_ECDHE_ECDSA_WITH_NULL_SHA ( 0xc006 ) UNSICHER 0
TLS_ECDHE_RSA_WITH_NULL_SHA ( 0xc010 ) UNSICHER 0
TLS_ECDH_ECDSA_WITH_NULL_SHA ( 0xc001 ) UNSICHER 0
TLS_ECDH_RSA_WITH_NULL_SHA ( 0xc00b ) UNSICHER 0
TLS_RSA_WITH_NULL_SHA256 ( 0x3b ) UNSICHER 0
TLS_RSA_WITH_NULL_SHA ( 0x2 ) UNSICHER 0
TLS_RSA_WITH_NULL_MD5 ( 0x1 ) UNSICHER 0
(1) Wenn ein Browser SSL 2 unterstützt, werden die nur für SSL 2 verfügbaren Cipher Suites nur bei der allerersten Verbindung zu dieser Site angezeigt. Um die Suites zu sehen, schließen Sie alle Browserfenster und öffnen Sie dann direkt diese exakte Seite. Nicht neu laden.

130×100 511 Bytes

Protokoll-Details

Server Name Indication (SNI) Ja
Sichere Neuverhandlung Ja
TLS-Komprimierung Nein
Sitzungstickets Nein
OCSP-Stapling Nein
Signaturalgorithmen SHA384/RSA, SHA256/RSA, SHA1/RSA, SHA256/ECDSA, SHA1/ECDSA
Benannte Gruppen secp256r1, secp384r1, secp521r1
Next Protocol Negotiation Nein
Application Layer Protocol Negotiation Nein
SSL 2-Handshake-Kompatibilität Nein

Behandlung von gemischten Inhalten

130×100 529 Bytes

Tests für gemischte Inhalte
Bilder Passiv Ja
CSS Aktiv Ja
Skripte Aktiv Ja
XMLHttpRequest Aktiv Ja
WebSockets Aktiv Ja
Frames Aktiv Ja
(1) Diese Tests können eine Warnung für gemischte Inhalte in Ihrem Browser auslösen. Das ist zu erwarten.
(2) Wenn Sie einen fehlgeschlagenen Test sehen, versuchen Sie, die Seite neu zu laden. Wenn der Fehler weiterhin besteht, setzen Sie sich bitte mit uns in Verbindung.

Entschuldigen Sie das Formatierungsproblem; der Benutzer hat den rich-text-HTML-Inhalt für mich kopiert und eingefügt, wobei beim Einfügen in Discourse einige Informationen verloren gingen. Ich werde später versuchen, herauszufinden, wie ich das Format beheben kann.

Wie bereits erwähnt, möchte ich ihm ermöglichen, zumindest eine sichere Verbindung herzustellen, damit er etwas sieht. Das sollte möglich sein, da der Browser TLS 1.2 unterstützt. Ich vermute jedoch, dass ich einige weniger sichere Konfigurationen für TLS 1.2 aktivieren müsste, damit sein Browser unterstützt wird. Ich kenne mich mit TLS-Konfigurationen nicht gut genug aus, um die Ausgabe dieses Berichts mit dem abzugleichen, was der Server unterstützt, und um zu wissen, was ich ändern müsste. Können Sie mir sagen, was fehlt und was ich ändern müsste?

6

Ich habe eine grobe Vorstellung davon, was du meinst, aber ich habe keine Ahnung, wie das geht. Kannst du mir auf eine Dokumentation verweisen, die erklärt, wie man die TLS-Konfiguration des Discourse-Docker-Containers ändert, um diese zu aktivieren?

7

Ich glaube nicht, dass Safari 6 funktioniert, selbst wenn Sie die TLS-Probleme durch Hinzufügen zusätzlicher Cipher-Suites lösen.

Sie können fehlende Cipher-Suites hinzufügen, indem Sie die nginx-Konfigurationsdatei überschreiben. Fügen Sie den folgenden Codeabschnitt (nicht getestet, sollte aber funktionieren) in den Abschnitt hooks von app.yml ein und passen Sie den Wert von ssl_ciphers nach Ihren Wünschen an.

  after_ssl:
    - replace:
        filename: "/etc/nginx/conf.d/discourse.conf"
        from: /ssl_ciphers .*/
        to: ssl_ciphers <ihre_vollständige_Cipher-Liste>;

Übrigens: Ich versuche, Unterstützung für Elliptic-Curve-Zertifikate für Discourse hinzuzufügen, damit es mit IE11 sofort funktioniert.

8

iOS 6?! Die letzte Version davon wurde Anfang 2014 veröffentlicht! Das ist mehr als 5 Jahre her!

9

Ich weiß, ich war genauso überrascht wie du. Ich erwarte nicht, dass du es unterstützt, aber ich möchte, dass der Benutzer zumindest etwas HTML erhält und sieht, was funktioniert und was nicht.

10

Danke @gerhard, ich habe die von dir beschriebene Änderung in /var/discourse/containers/app.yml vorgenommen (ich hoffe, das war die richtige app.yml-Datei) und anschließend /var/discourse/launcher rebuild app ausgeführt, wie in den Kommentaren von app.yml beschrieben.

Anschließend habe ich den Test auf ssllabs.com erneut durchgeführt, aber es scheint, als habe sich das Ergebnis nicht geändert: https://www.ssllabs.com/ssltest/analyze.html?d=forum.stadtteilgenossenschaft-wik.de&s=68.183.214.228&hideResults=on

Ich bin mir nicht sicher, wie ich überprüfen kann, ob die Konfigurationsänderung tatsächlich gewirkt hat (sie hatte jedoch keinen Einfluss auf das Testergebnis) oder ob die Änderung gar nicht funktioniert hat.

11

Oh, ich habe deinen Beitrag nicht richtig gelesen, @gerhard. Wenn ich es richtig verstehe, macht die von dir bereitgestellte Konfiguration die verwendeten Chiffren explizit, aber der von dir verwendete Wert ist im Grunde derselbe wie der Standard, oder? Ich müsste ihn also trotzdem um weitere Chiffren erweitern, die möglicherweise von älteren Browsern unterstützt werden.

12

Ja, genau. Ich wollte keine Lösung zum Hinzufügen schwacher Cipher zur Konfiguration veröffentlichen. Das müsst ihr selbst herausfinden. :wink:

Aber wenn ihr diese Änderungen vornimmt, solltet ihr den Pull Request, den ich zuvor erwähnt habe, im Auge behalten. Wenn er gemergt wird, funktioniert IE11 sofort.

13

Ich verstehe, du möchtest es jemandem nicht zu einfach machen, die Einrichtung unsicher zu gestalten. Das respektiere ich, und ich werde auch den vollständigen Code nicht posten.

Hier ist mein aktueller Stand: Ich habe die fehlenden Cipher Suites identifiziert, die benötigt werden, um ältere Browser und Betriebssysteme zu unterstützen, indem ich beispielsweise Qualys SSL Labs - Projects / User Agent Capabilities: Safari 6 / iOS 6.0.1 (und ähnliche Seiten für andere Browser) geprüft habe. Da die Cipher Suites des Clients nach Priorität aufgelistet sind, habe ich einfach jeweils die oberste ausgewählt und sichergestellt, dass sie unterstützt wird. Ich gehe davon aus, dass es ausreicht, wenn der Server mindestens eine aus der Liste unterstützt. Hier sind die von mir identifizierten Ciphers:

  • ECDHE-ECDSA-AES256-CBC-SHA384 für Safari 6–8
  • ECDHE-RSA-AES256-CBC-SHA384 für IE 11 unter Windows 7/8.1/Phone 8.1 Update (laut @supermathie)
  • ECDHE-RSA-AES128-CBC-SHA256 für IE 11 unter Windows Phone 8.1

Ich habe diese Werte ans Ende der Liste der ssl_ciphers hinzugefügt, durch Doppelpunkte getrennt, in der Annahme, dass „Ende der Liste

14

Nach genauerer Betrachtung des SSLLab-Ergebnisses glaube ich, dass dies nicht funktioniert.

Das ist das Ergebnis, das ich auf SSLLabs für meinen Server nach der Anwendung der Konfiguration und dem Neuaufbau sehe:

33
331730×234 48.1 KB

Meines Wissens nach sollten hier deutlich mehr Einträge aufgeführt sein, da die Konfiguration viele weitere Optionen enthält. Bedeutet das, dass diese Konfigurationsänderung nicht funktioniert hat?

15

Ich denke, die von Ihnen gewählten Ciphers haben die falschen Namen. Mapping OpenSSL cipher suite names to IANA names ist eine gute Ressource, um die vom SSL Server Test aufgelisteten Ciphers den von OpenSSL (nginx) verwendeten Namen zuzuordnen.

In meinen Tests habe ich :ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA angehängt, und nach einem Neuaufbau sieht der Test so aus:

image
image955×362 15.3 KB

image
image899×1270 114 KB

Vielleicht liegt ein Fehler im Test vor? :man_shrugging: Ich habe keinen so alten Safari zum Testen. Wir unterstützen nur Safari 10+. Sind Sie sicher, dass es immer noch aufgrund eines TLS-Fehlers fehlschlägt?

16

Danke, ich werde es versuchen!

Ich habe die Discourse-Konfigurationsdateien etwas genauer durchgesehen und templates/web.ssl.template.yml gefunden. Was ist der Unterschied zwischen dieser Änderung der Cipher-Listen über die app.yml-Datei und dem direkten Ändern der ssl_ciphers-Liste in templates/web.ssl.template.yml?

17

Die Vorlage ist versioniert, während app.yml nicht versioniert ist. Wenn Sie die Vorlage bearbeiten, werden Sie Probleme beim Aktualisieren des Repositorys haben.

18

Danke, das war das Problem. Durch die Korrektur der Namen funktioniert der Handshake für alle im SSLLabs-Liste getesteten Browser. Vielen Dank für deine Geduld!

Jetzt bin ich neugierig, was meine Benutzer sehen, sobald sie den HTTPS-Fehler mit ihren alten Browsern überwunden haben. :smiley: