nginx - ssl_ciphers und ssl_protocols modernisieren

[tkurbad]

Hallo,

derzeit muss ich nach jedem 3CX-Update die ssl_ciphers und ssl_protocols in bin/nginx/conf/snippets/50-ssl-protocols.conf wie folgt anpassen, um die Weboberfläche von modernen Browsern aus zu erreichen:

ssl_protocols TLSv1.2 TLSv1.3;

ssl_ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA;

Kann das eventuell bei einem der nächsten Updates angepasst werden, um diese Handarbeit - und den dann fehlenden Support - überflüssig zu machen?

Vielen Dank
Torsten

 

[bitn2]

Das ist mir noch bei keiner 3CX untergekommen... Wie werden die Anlagen denn installiert?

 

[tkurbad]

Mittels Updste über die Administrationsoberfläche. Nach jedem Update, bei dem eine nginx-Aktualisierung dabei ist, wird die 50-ssl-protocols.conf wieder überschrieben mit:

ssl_protocols TLSv1.2;

sowie einer veralteten Cipherlist. Hinterher meckern dann Chrome, Edge usw. "No common SSL ciphers". Wundert mich etwas, dass das nur bei uns so sein soll.

PS: Serverplattform ist Windows, da wir die AD-Anbindung brauchen.

 

[bitn2]

Mittels Updste über die Administrationsoberfläche. Nach jedem Update, bei dem eine nginx-Aktualisierung dabei ist, wird die 50-ssl-protocols.conf wieder überschrieben mit:

ssl_protocols TLSv1.2;

sowie einer veralteten Cipherlist. Hinterher meckern dann Chrome, Edge usw. "No common SSL ciphers". Wundert mich etwas, dass das nur bei uns so sein soll.

Ich kenne niemanden der das Problem hat. Macht die Firewall davor SSL Inspection? Reverse Proxy davor?

 

[tkurbad]

Nein, keine Reverse Proxies und keine Packet inspection. Wie gesagt: Wenn ich das Problem direkt auf dem Server behebe (durch Anpassen der genannten Datei), funktioniert es.

Letztlich würde es vermutlich reichen, die ssl_ciphers um die o.g. zu ergänzen. Das täte niemandem weh...

 

[bitn2]

Es muss ja aber einen Grund haben warum du den Fehler bekommst, sonst hat den ja kaum einer. Ich kenne nur einen Thread aus dem englischen Forum wo das auch war, da kam aber keine Rückmeldung vom Threadersteller mehr.

EDIT: wenn du magst schick mir den Link zu deiner 3CX mal per PN und ich schaue mal ob ich den Fehler hier auch bekomme.

 

[tkurbad]

Den Fehler bekomme nicht nur ich, sondern auch alle meine 200 Kollegen. Möglicherweise liegt es an Gruppenrichtlinien unserer Windows-Domain, da habe ich aber derzeit keinen Überblick.

Angesichts der stetig wachsenden Gefahr durch Crypto-Trojaner werden wir Security-Einstellungen aber auch nicht zurückfahren.

 

[bitn2]

Das kann durchaus sein, auch ein Virenscanner der SSL Insepction macht kann den Fehler verursachen. Gib sonst mal deine Domain hier ein und schau mal was da raus kommt: https://www.ssllabs.com/ssltest

 

[bitn2]

Das ist der Stand jeder 3cx und zeigt bei niemandem Fehler an. Dann ist das ein Problem eures Netzwerks:

 

[tkurbad]

Ich werde das nach dem nächsten Update, das unsere Telefonie lahmlegt, nochmal gegenchecken.

Ist halt eigenartig, dass es bei uns dann auch funktioniert, sobald ich die cypher_list auf einen etwas gehobeneren Sicherheitsstandard anpasse. Außer dem Defender läuft auf der Kiste kein Virenscanner, und außer unserer SonicWall mit deaktivierter DPI steht auch nichts zwischen Server und Internet.

Einzige Unbekannte für mich sind die Windows GPOs. Unser Windows-Admin liegt gerade flach, den kann ich erst später fragen.

Danke erstmal soweit.

Mich beschleicht da gerade so eine Ahnung, wo ich dein SSL-Checker-Resultat sehe. Derartige Online-Tools beherrschen normalerweise nur den Standard-Port 443. Bei uns läuft die Instanz aber auf Port 5001. Möglicherweise sind moderne Browser dann strenger bei den Ciphers. Das Zeug, das in deinem Scan mit "Weak" bewertet wurde könnte da stören...

Würde das gern mal testen, aber da wir ein Produktivsystem betreiben, kann ich außerhalb der Wartungsfenster (1. Donnerstag im Monat) nicht einfach mal "spielen".

 

[bitn2]

Mich beschleicht da gerade so eine Ahnung, wo ich dein SSL-Checker-Resultat sehe. Derartige Online-Tools beherrschen normalerweise nur den Standard-Port 443. Bei uns läuft die Instanz aber auf Port 5001. Möglicherweise sind moderne Browser dann strenger bei den Ciphers. Das Zeug, das in deinem Scan mit "Weak" bewertet wurde könnte da stören...

Die getestete Anlage läuft auch auf Port 5001

 

[bitn2]

Sorry, war doch eine Anlage mit 443.

 

[tkurbad]

So, da bin ich wieder, wie versprochen.

Beim heutigen Update auf 18.0 Update 9 (Build 31) wurde mal wieder die 50-ssl-protocols.conf überschrieben. Fünf Minuten später rief mich der erste Kollege an, er käme nicht mehr auf das Webinterface.

In besagter Datei die Zeile

ssl_protocols TLSv1.2;

geändert in

ssl_protocols TLSv1.2 TLSv1.3;

und den nginx neu gestartet, schon ist Zugriff möglich.

Hier mal ein Screenshot dazu, wie sich die Anlage nach dem Update präsentiert:


Wie kommen wir hier weiter? Der Ist-Zustand ist nicht wirklich befriedigend.

 

[fxbastler]

Beim heutigen Update auf 18.0 Update 9 (Build 31) wurde mal wieder die 50-ssl-protocols.conf überschrieben.

Das war zu erwarten.

Die Ursache wird sein:

liegt es an Gruppenrichtlinien unserer Windows-Domain

Browser, die TLS 1.3 only haben, wurden speziell so konfiguriert. Aktuell ist immer noch 1.2 und das noch eine Weile. Damit kommen alle aktuellen Systeme, Anwendungen und Browser zurecht.

Wenn du dir selber hilfst / helfen kannst und damit keines eurer Geräte ausgesperrt wird, dann ist das muss das wohl i.O. sein.

 

[tkurbad]

Browser, die TLS 1.3 only haben, wurden speziell so konfiguriert. Aktuell ist immer noch 1.2 und das noch eine Weile. Damit kommen alle aktuellen Systeme, Anwendungen und Browser zurecht.

Bei mir greifen keine GPOs, ich verwende Linux. Ich vermute immer noch, dass es an Port 5001 vs. 443 liegt.

Webseiten, die nur <= TLS 1.2 anbieten, das aber auf Port 443, funktionieren nämlich.

 

[fxbastler]

Ich vermute immer noch, dass es an Port 5001 vs. 443 liegt.

Kann ich nicht bestätigen, Debian 12 mit Chrome und eine 3CX mit eigenem Zertifikat:

 

[bitn2]

Bei mir greifen keine GPOs, ich verwende Linux.

Warum sollten da keine GPOs greifen? Auch in Linux System kann in eine AD Domäne integriert sein.

 

[fxbastler]

zumal:

PS: Serverplattform ist Windows, da wir die AD-Anbindung brauchen.

 

[tkurbad]

Ohje, ich glaube, wir brechen an dieser Stelle ab und ich kläre das über unseren Servicepartner...

Was die Serverplattform mit dem Browser auf meinem Linux-Client zu tun haben soll, bzw. auf Grund welcher Magie mir ein beliebiger Windows-Server seine GPOs clientseitig unterschieben sollte, erschließt sich mir jedenfalls nicht. Ich mach den Kram aber auch erst seit 30 Jahren. Wahrscheinlich fehlt es mir an Ahnung.

 

[bitn2]

Hin oder her... Fakt ist, das Problem liegt an eurer Konfiguration und nicht an 3cx. Von 3cx brauchst du dir da keine Änderung in deine Richtung erhoffen, da müsst ihr selber schauen was ihr da verbastelt habt.