HTTPS/SSL/TLS-Verbindungen werden nicht mehr korrekt aufgebaut mit 10.40-RC1

Forum zum Thema allgemeinen Fragen zu VPN

Moderator: Lancom-Systems Moderatoren

Antworten
cpuprofi
Beiträge: 1330
Registriert: 12 Jun 2009, 12:44
Wohnort: Bremen

HTTPS/SSL/TLS-Verbindungen werden nicht mehr korrekt aufgebaut mit 10.40-RC1

Beitrag von cpuprofi »

Hallo an Alle,

ich habe festgestellt, dass sich die VPN's nach dem Update auf LCOS 10.40RC1 nicht mehr aufbauen.

Im Trace [VPN-Debug] fehlt "+Exchange created"

VPN geht nicht (10.40.103 RC1):

Code: Alles auswählen

[VPN-Debug] 2019/12/11 19:03:35,396  Devicetime: 2019/12/11 19:03:38,372
Peer LANCOM1781EW+ [responder]: Received an INFORMATIONAL-RESPONSE of 57 bytes (encrypted)
Gateways: 79.192.XXX.123:500<--77.20.XXX.456:500
SPIs: 0x16AFFF19FB8424A3926A444B169C1283, Message-ID 22
Payloads: ENCR
QUB-DATA: 79.192.XXX.123:500<---77.20.XXX.456:500 rtg_tag 0 physical-channel WAN(1) vpn-channel 28
transport: [id: 6343506, UDP (17) {incoming unicast, fixed source address}, dst: 77.20.XXX.456, tag 0 (U), src: 79.192.XXX.123, hop limit: 64, DSCP: CS6, ECN: Not-ECT, pmtu: 1492, iface: T-COM (7), mac address: ff:ff:ff:ff:ff:ff, port 0], local port: 500, remote port: 500
+IKE_SA found and assigned
Message verified and decrypted successfully
Payloads: ENCR
VPN geht noch (10.32.0156 RU4):

Code: Alles auswählen

[VPN-Debug] 2019/12/11 19:03:47,377  Devicetime: 2019/12/11 19:03:50,350
Peer LANCOM1781VAW [responder]: Received an INFORMATIONAL-REQUEST of 57 bytes (encrypted)
Gateways: 79.192.XXX.123:500<--79.201.XXX.789:500
SPIs: 0xAE5ABB7F55F202AEF8698D692BD004FD, Message-ID 925
Payloads: ENCR
QUB-DATA: 79.192.XXX.123:500<---79.201.XXX.789:500 rtg_tag 0 physical-channel WAN(1) vpn-channel 29
transport: [id: 4770185, UDP (17) {incoming unicast, fixed source address}, dst: 79.201.XXX.789, tag 0 (U), src: 79.192.xxx.123, hop limit: 64, DSCP: CS6, ECN: Not-ECT, pmtu: 1492, iface: T-COM (7), mac address: ff:ff:ff:ff:ff:ff, port 0], local port: 500, remote port: 500
+IKE_SA found and assigned
+Exchange created (flags: 0x00000040)
Message verified and decrypted successfully
Payloads: ENCR
Woran liegt's? Tip?

Grüße
Cpuprofi
Zuletzt geändert von cpuprofi am 05 Jan 2020, 09:07, insgesamt 1-mal geändert.
GrandDixence
Beiträge: 1054
Registriert: 19 Aug 2014, 22:41

Re: VPN baut sich nach Update auf LCOS 10.40RC1 nicht mehr auf.

Beitrag von GrandDixence »

Ohne den genauen Inhalt des IKE-Telegramms zu kennen, kann man nur Vermutungen anstellen. Handelt es sich um ein IKE_DELETE-Telegramm zur Trennung des VPN-Tunnels (mit DELETE-Payload) oder um ein (leeres) IKE_INFORMATIONAL-Telegramm für die Dead Peer Detection (DPD)?

Hier sollte zusätzlich "trace vpn-Ike" verwendet werden. Siehe auch:
fragen-zum-thema-vpn-f14/fast-kein-traf ... tml#p92918

Jedenfalls steht der VPN-Tunnel für den Steuerkanal (IKE). Wie der Zustand des Datenkanal des VPN-Tunnels aussieht (ESP/IPSec), verrät die entsprechende VPN-Status-Seite des LANCOM-Routers.
ittk
Beiträge: 1244
Registriert: 27 Apr 2006, 09:56

Re: VPN baut sich nach Update auf LCOS 10.40RC1 nicht mehr auf.

Beitrag von ittk »

Kann es noch sein, dass Du ein IKEv1 VPN mit AH und / oder IPcomp Proposals nutzt?

Dann ist zu beachten, dass LCOS 10.40RC1 folgendes nicht mehr supported:

Code: Alles auswählen

- Entfall von IPCOMP für IKEv1
- Entfall von AH für IPsec
Auf jeden Fall sind hier die VPN Traces sehr sinnvoll einzusetzen.... alles Andere fuehrt wohl zu nichts und entspricht eher der Methode Kaffeesatzlesen ;) ....
12x 1621 Anx. B-21x 1711 VPN-3x 1722 Anx. B-7x 1723 VoIP-1x 1811 DSL, 1x 7011 VPN-1 x 7111 VPN-1x 8011 VPN-10er Pack Adv. VPN Client (2x V1.3-3x 2.0)-Hotspot Option-Adv. VoIP Client/P250 Handset-Adv.VoIP Option-4x VPN-Option-2x L-54 dual-2x L54ag-2x O-18a
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: VPN baut sich nach Update auf LCOS 10.40RC1 nicht mehr auf.

Beitrag von Jirka »

Hallo zusammen,

ich habe mir das Problem heute mal angeschaut. Ursache ist, dass die DynDNS-Aktualisierungen per https unter Umständen mit der 10.40.103-RC1 nicht mehr funktionieren. Da ist irgendein Bug drin. Richtig müsste der Thread demnach heißen: HTTPS/SSL/TLS-Verbindungen werden nicht mehr korrekt aufgebaut mit 10.40-RC1.
Mit der 10.40 unterstützt der LANCOM TLS v 1.3:

Code: Alles auswählen

root@LANCOM1781EW+_Test:/Setup/WAN/SSL-for-Action-Table
> set ver ?

Possible values in menu 'SSL-for-Action-Table' with prefix 'ver':
[  1] Versions : Bitmask: SSLv3 (1), TLSv1 (2), TLSv1.1 (4), TLSv1.2 (8), TLSv1.3 (16)
Durch die Einführung von TLS v 1.3 wird die Konfig offensichtlich derart geändert, dass Version TLS v 1.3 hinzugefügt wird. War Versions vorher also z. B. auf TLSv1 eingestellt, so sieht es nach Update auf die 10.40 offensichtlich derart aus:

Code: Alles auswählen

root@LANCOM1781EW+_Test:/Setup/WAN/SSL-for-Action-Table
> ls ver

Versions  VALUE:   TLSv1,TLSv1.3
Es zeigte sich, dass wenn der Parameter
/Setup/WAN/SSL-for-Action-Table/Versions
auf TLSv1,TLSv1.3
oder nur auf TLSv1.3
steht, dass dann im CONNACT-Trace bei den verschiedensten DynDNS-Providern SSL-Fehler stehen, z. B. SSL-Protocol-Error oder SSL-Version-Error. Updates gehen jedenfalls nicht durch.
Stellt man Versions auf default (alle TLS-Versionen sind zugelassen) oder nur auf TLSv1, so gibt es keine Probleme.

Viele Grüße,
Jirka
GrandDixence
Beiträge: 1054
Registriert: 19 Aug 2014, 22:41

Re: HTTPS/SSL/TLS-Verbindungen werden nicht mehr korrekt aufgebaut mit 10.40-RC1

Beitrag von GrandDixence »

Wahrscheinlich ein Konfigurationsfehler: Wenn ein Client beim Aufbau der verschlüsselten Netzwerkverbindung (TLS) dem Server angibt, er spreche TLS 1.3, dann aber in der Liste der vom Client unterstützten Ciphers keinen TLS 1.3-kompatiblen Cipher angibt, kommt logischerweise bei einem TLS1.3-fähigen Server keine verschlüsselte Verbindung (TLS) zustande.
https://wiki.mozilla.org/Security/Server_Side_TLS

TLS1.3 lässt aus Sicherheitsgründen kein "Fallback" auf TLS 1.2, TLS 1.1 oder TLS 1.0 zu!
https://www.heise.de/select/ct/2017/4/1487002604809322

=> Mit Wireshark den Aufbau der verschlüsselten Netzwerkverbindung (CLIENT_HELLO, SERVER_HELLO) untersuchen. Oder entsprechenden Trace einsetzen...

https://www.ibm.com/support/knowledgece ... 10660_.htm
Zuletzt geändert von GrandDixence am 11 Jan 2020, 12:11, insgesamt 1-mal geändert.
cpuprofi
Beiträge: 1330
Registriert: 12 Jun 2009, 12:44
Wohnort: Bremen

Re: HTTPS/SSL/TLS-Verbindungen werden nicht mehr korrekt aufgebaut mit 10.40-RC1

Beitrag von cpuprofi »

Hallo GrandDixence,
GrandDixence hat geschrieben: 07 Jan 2020, 22:48 Wahrscheinlich ein Konfigurationsfehler: Wenn ein Client beim Aufbau der verschlüsselten Netzwerkverbindung (TLS) dem Server angibt, er spreche TLS 1.3, dann aber in der Liste der vom Client unterstützten Ciphers keinen TLS 1.3-kompatiblen Cipher angibt, kommt logischerweise bei einem TLS1.3-fähigen Server keine verschlüsselte Verbindung (TLS) zustande. TLS1.3 lässt aus Sicherheitsgründen kein "Fallback" auf TLS 1.2, TLS 1.1 oder TLS 1.0 zu!
der Aufbau der verschlüsselten Netzwerkverbindung war ja mit der FW 10.32 ohne Fehler möglich, nur mit der 10.40 nicht mehr.

Es scheint eher so, dass Lancom da was im Bezug zur TLS geändert hat... vielleicht ist auch ein Bug drin... :G)

Grüße
Cpuprofi
Benutzeravatar
alf29
Moderator
Moderator
Beiträge: 6205
Registriert: 07 Nov 2004, 19:33
Wohnort: Aachen
Kontaktdaten:

Re: HTTPS/SSL/TLS-Verbindungen werden nicht mehr korrekt aufgebaut mit 10.40-RC1

Beitrag von alf29 »

Moin,

Ad 1: ja, mit der 10.40 wird an diversen Stellen automatisch TLS 1.3 ergänzt, nämlich überall da, wo SSL/TLS über TCP im Client-Modus eingesetzt wird. Mit der 10.30 wurde das bereits für TLS im Server-Modus getan, TLS 1.3 im Client-Modus ist eine Neuerung der 10.40. Man kann jetzt lang und breit darüber diskutieren, ob denn jetzt nach einem Firmware-Update das Gerät zu 110% weiter so funktionieren soll wie mit der alten Firmware. Bei TLS 1.2 haben wir das so gehandhabt und das Ergebnis war, daß viele Kunden heute noch in der Konfig den "Uralt-Default" SSLv3+TLSv1 drinstehen haben, obwohl die Server im Internet längst alle TLS 1.2 können und das inzwischen auch der LCOS-Default nach einem Konfig-Reset ist. Bei TLS 1.3 sind wir einen anderen Weg gegangen, und die Entscheidung trage ich auch mit, weil wir nur so einigermaßen zeitnah Rückmeldungen über die Interoperabilität bekommen - bei TLS 1.2 sind seinerzeit einige Fehler erst nach Jahren aufgefallen.

Ad 2: Wenn Kunden eine bezüglich der Versionen alte Default-Konfig haben (SSLv3+TLS 1.0 wie oben oder nur TLS 1.0), dann macht der Konfig-Konverter daraus eine Liste mit diskontinuierlichen Versionen, z.B. TLS 1.0 und 1.3, aber kein TLS 1.1 oder 1.2. Das ist nicht verboten, führt aber im aktuellen 10.40-RC dazu, daß der Verbindungsaufbau gegen Server, die noch kein TLS 1.3 unterstützen, scheitert - sorry, mea culpa und ist im nächsten RC gefixt. Als Workaround für den RC1 könnt Ihr die Versionsnummer wieder zurückdrehen, also nur TLS 1.0 (die sicherheitstechnisch schlechteste Lösung), TLS 1.1/1.2 ergänzen oder gleich auf nur-TLS 1.2+1.3 umstellen (die sinnvollste Lösung). Wenn Ihr auf nur-TLS 1.3 umstellt, dann hängt das Ergebnis natürlich davon ab, ob der Server es schon unterstützt...

Ad 3: Fallbacks in dem Sinne, daß TLS 1.3-fähige Clients auch ältere Versionen sprechen *können*, gibt es selbstverständlich genauso wie bei früheren Versionen. Es ist zwar richtig, daß TLS 1.3 einen anderen Satz Cipher-Suiten benutzt (weil TLS 1.3 bestimmte Aspekte nicht mehr über die Cipher-Suite verhandelt), damit muß man sich als LCOS-Nutzer aber nicht beschäftigen. In der SSL/TLS-Konfig konfiguriert man Verschlüsselungs-, Hash- und Signaturalgorithmen, keine Cipher-Suiten. Das LCOS berechnet automatisch aus der Konfig, welche Cipher-Suiten sich für welche TLS-Protokollversionen daraus ergeben.

Viele Grüße

Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: HTTPS/SSL/TLS-Verbindungen werden nicht mehr korrekt aufgebaut mit 10.40-RC1

Beitrag von Jirka »

Hallo Alfred,

irgendwie habe ich ja schon eine Antwort von Dir erhofft oder vielleicht auch erwartet, und so kam sie denn jetzt auch, wie immer perfekt, irgendwie vermisse ich hier gerade den Daumen nach oben bei den Smilies, wie es ihn in den verschiedensten Messengern gibt. Dann kriegst Du jetzt den hier :) Also wie immer perfekt, allerdings fast ein wenig sehr sachlich...
alf29 hat geschrieben: 08 Jan 2020, 10:57Man kann jetzt lang und breit darüber diskutieren, ob denn jetzt nach einem Firmware-Update das Gerät zu 110% weiter so funktionieren soll wie mit der alten Firmware.
In der Tat.
alf29 hat geschrieben: 08 Jan 2020, 10:57Bei TLS 1.2 haben wir das so gehandhabt und das Ergebnis war, daß viele Kunden heute noch in der Konfig den "Uralt-Default" SSLv3+TLSv1 drinstehen haben, obwohl die Server im Internet längst alle TLS 1.2 können und das inzwischen auch der LCOS-Default nach einem Konfig-Reset ist.
Genau. Das sieht man dann immer schön mit einem 'readscript', wo Parameter abweichen, an denen ja eigentlich nie jemand gestellt hat. Nach ein paar Jahren hat man dann eine Config, die so niemand konfiguriert hatte, sondern die quasi historisch gewachsen ist. Aus ehemaligen Defaultwerten und aus der tatsächlichen Konfiguration. Und ich rede hier nicht nur von TLS-Versionen oder irgendwelchen kryptografischen Verfahren, nein auch im WLAN gab es im Laufe der Zeit den ein oder anderen Defaultwert, der geändert wurde. Insofern stellt sich sogar die Frage, ob es nicht in der Tat sinnvoll ist, Werte die auf dem Default stehen, auch in einen neuen Defaultwert zu konvertieren, sofern damit keine komplette Verhaltensänderung einhergeht.

alf29 hat geschrieben: 08 Jan 2020, 10:57Bei TLS 1.3 sind wir einen anderen Weg gegangen, und die Entscheidung trage ich auch mit,
Ich bin auch dafür,
alf29 hat geschrieben: 08 Jan 2020, 10:57weil wir nur so einigermaßen zeitnah Rückmeldungen über die Interoperabilität bekommen
aber natürlich nicht aus diesem Grund... (Ich sage nur die Bananen reifen beim Kunden... :wink: )
Sondern eher aus dem Grund, diese sichere und damit bessere Sache auch freizuschalten.
Obwohl es ehrlich gesagt natürlich auch ein Gewinn ist, wenn die Fehler recht bald gefixt sind - mir tun da immer die alten Geräte leid, die mit fehlerbehafteten Versionen in Rente gehen müssen.
alf29 hat geschrieben: 08 Jan 2020, 10:57Das ist nicht verboten, führt aber im aktuellen 10.40-RC dazu, daß der Verbindungsaufbau gegen Server, die noch kein TLS 1.3 unterstützen, scheitert
...wie Du jetzt anhand dieses Threads hier gemerkt hast??? (Das meinte ich mit dem "sachlich" oben.)
alf29 hat geschrieben: 08 Jan 2020, 10:57oder gleich auf nur-TLS 1.2+1.3 umstellen (die sinnvollste Lösung).
Ist es aber nicht genauso sinnvoll, wenn ich auf TLS 1.1+1.2+1.3 stelle, weil er dann das höchstmögliche TLS-Level nimmt und trotzdem höchstmögliche Abwärtskompatibilität hat? Ok, jetzt kommt vermutlich das Thema Man-in-the-Middle-Attack. Wenn man natürlich weiß, dass der (oder die) DynDNS-Provider ein gewisses Level kann (können), dann ist es vermutlich sinnvoll, dieses Level auch nicht auf ein unsicheres Niveau abfallen zu lassen.
P. S.: Ach bei der letzten Sache hatte ich jetzt übersehen, dass Du ja explizit vom fehlerbehafteten RC1 geschrieben hast, da geht ja dann TLS 1.1+1.2+1.3 möglicherweise gar nicht, ich hatte jetzt nicht alle Kombinationen durchgetestet, das war mir zu aufwändig.

Vielen Dank und viele Grüße,
Jirka
GrandDixence
Beiträge: 1054
Registriert: 19 Aug 2014, 22:41

Re: HTTPS/SSL/TLS-Verbindungen werden nicht mehr korrekt aufgebaut mit 10.40-RC1

Beitrag von GrandDixence »

Jirka hat geschrieben: 08 Jan 2020, 17:52
Ist es aber nicht genauso sinnvoll, wenn ich auf TLS 1.1+1.2+1.3 stelle, weil er dann das höchstmögliche TLS-Level nimmt und trotzdem höchstmögliche Abwärtskompatibilität hat?
Wenn der Kommunikationspartner der verschlüsselten Kommunikation immer der gleiche ist, empfehle ich folgendes Vorgehen:

- Mit einer Verschlüsselungs-Test-Webseite die "TLS-Parameter" des (Web-)Servers "abklopfen":
https://www.ssllabs.com/ssltest/

https://observatory.mozilla.org/ => TLS Observatory

https://de.ssl-tools.net/

https://certlogik.com/ssl-checker/ => Zur Kontrolle der PKI/X.509-Zertifikate

Soll der "TLS-Scan" nicht auf den Server-Port TCP 443 (HTTPS) durchgeführt werden, kann der gewünschte TCP-Port bei einigen Verschlüsselungs-Test-Webseiten angeben werden. Zum Beispiel: posteo.de:465 => TCP Port 465 => SMTPS

Danach den LANCOM-Router so konfigurieren, dass zu diesem Kommunikationspartner die sichersten, von Client UND Server unterstützten "TLS-Parameter" eingesetzt werden.

Für den im Webbrowser integrierten TLS-Client eignet sich die Test-Verschlüsselungs-Webseite:
https://www.howsmyssl.com/

https://www.ssllabs.com/ssltest/viewMyClient.html
Benutzeravatar
alf29
Moderator
Moderator
Beiträge: 6205
Registriert: 07 Nov 2004, 19:33
Wohnort: Aachen
Kontaktdaten:

Re: HTTPS/SSL/TLS-Verbindungen werden nicht mehr korrekt aufgebaut mit 10.40-RC1

Beitrag von alf29 »

Moin,
...wie Du jetzt anhand dieses Threads hier gemerkt hast??? (Das meinte ich mit dem "sachlich" oben.)
Kurz vor Weihnachten war über den Support ein Bugreport mit genau diesem Problem reingekommen. Ich bin leider erst im neuen Jahr dazu gekommen, mir das genauer anzuschauen.
Ist es aber nicht genauso sinnvoll, wenn ich auf TLS 1.1+1.2+1.3 stelle, weil er dann das höchstmögliche TLS-Level nimmt und trotzdem höchstmögliche Abwärtskompatibilität hat?
TLS 1.1 hat in der Praxis nie so die große Bedeutung gehabt. Es ist seinerzeit parallel mit DTLS 1.0 herausgekommen, und enthält einige wenige Änderungen, damit TLS-Verbindungen über UDP gehen. TLS 1.2 ist dagegen ein echter Sprung bezüglich Qualität der Kryptographie. Erst ab dieser Version kann man eine Verbindung aufbauen, die nirgendwo mehr MD5 oder SHA-1 als Hashes einsetzt. Die meisten Server haben vor ein paar Jahren direkt von TLS 1.0 auf 1.2 upgegradet. Ob Du TLS 1.0-1.3 oder 1.1-1.3 einschaltest, macht in der Praxis keinen nennenswerten Unterschied.
P. S.: Ach bei der letzten Sache hatte ich jetzt übersehen, dass Du ja explizit vom fehlerbehafteten RC1 geschrieben hast, da geht ja dann TLS 1.1+1.2+1.3 möglicherweise gar nicht, ich hatte jetzt nicht alle Kombinationen durchgetestet, das war mir zu aufwändig.
Das würde wohl schon gehen, das Problem tritt auf bei einer "Lücke" in den unterstützten Versionen. Wenn Du's genau wissen willst: Vor TLS 1.3 konnte ein Client dem Server lediglich eine Maximalversion mitteilen, die er unterstützt - eine explizite Liste der Versionen im ClientHello gibt es erst seit 1.3. Wenn 1.0+1.3 definiert ist, dann "weiß" der TLS-Client im LCOS ja nicht, ob der Server 1.3 unterstützt oder nicht, also schickt er beide Version-Infos. Und der "Knackpunkt" ist: Wenn TLS 1.3 eingeschaltet war, dann hat der Client bei der "Legacy-Maximalversion" immer 1.2 geschickt. Wenn dann ein Server gesagt hat,

"OK, ich weiß ja nicht, was dieses 1.3 ist, aber das 1.2 in der Maximalversion, das kann ich"

, das hat der LCOS-TLS-Client gemeint,

"Äh, wie jetzt, TLS 1.2, habe ich davon etwa was gesagt, das habe ich doch gar nicht eingeschaltet, ich breche mal ab."

und das war's dann...der Fix ist eben, daß bei so einer Konfig eben nur 1.0 als "Legacy-Maximalversion" geschickt wird. Ein TLS 1.3-fähiger Server findet "seine Version" über die neue Liste, alle anderen handeln wie gewollt maximal 1.0 aus.
Ok, jetzt kommt vermutlich das Thema Man-in-the-Middle-Attack. Wenn man natürlich weiß, dass der (oder die) DynDNS-Provider ein gewisses Level kann (können), dann ist es vermutlich sinnvoll, dieses Level auch nicht auf ein unsicheres Niveau abfallen zu lassen.
TLS-Client und -Server führen parallel einen kryptographischen Hash über alle ausgetauschten Handshake-Nachrichten mit und merken das, wenn ein Man-in-the Middle selbige verändert. Downgrade-Attacken funktionieren nur bei Clients, die bei fehlgeschlagenen Verbindungsaufbauten einfach mal auf Verdacht einen neuen Versuch mit einer niedrigeren Maximal-Versionsnummer probieren (ein sogenannter "Downgrade Protocol Dance") - diese Prüfsumme schützt nicht über mehrere TLS-Verbindungen hinweg. Der TLS-Client im LCOS macht aber keinen solchen Downgrade Dance und der TLS-Server im LCOS unterstützt die Gegenmaßnahmen, die vor ein paar Jahren definiert worden sind.

Viele Grüße

Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
GrandDixence
Beiträge: 1054
Registriert: 19 Aug 2014, 22:41

Re: HTTPS/SSL/TLS-Verbindungen werden nicht mehr korrekt aufgebaut mit 10.40-RC1

Beitrag von GrandDixence »

Zum Erkennen von durch ein Firmware-Update eingeführte, unerwünschte Konfigurationsparameteränderungen erstelle ich direkt vor und nach dem Firmware-Update ein Konfigurationsbackup (*.lcf). Die beiden Konfigurationsbackups (*.lcf) vergleiche ich mit einem Textdateivergleicher (diff).
https://de.wikipedia.org/wiki/Diff

Dabei darf ich mich immer wieder über neue, undokumentierte Konfigurationsparameter freuen. Die undokumentierten Konfigurationsparameter findet man zum Zeitpunkt des Einspielen der neuen Firmware weder in der LCOS-Menüreferenz noch in einem Addenum.

aktuelle-lancom-router-serie-f41/solved ... tml#p98611
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: HTTPS/SSL/TLS-Verbindungen werden nicht mehr korrekt aufgebaut mit 10.40-RC1

Beitrag von Jirka »

Hallo Alfred,
alf29 hat geschrieben: 08 Jan 2020, 23:46Kurz vor Weihnachten war über den Support ein Bugreport mit genau diesem Problem reingekommen.
ok, da waren wir also nicht schnell genug. Das Problem war ja - siehe Threadstart - auch schon eher da (sogar noch einen Monat eher, aber das sollte ich hier lieber nicht sagen), aber der Jahresendstress (oder die Ruhe vor selbigem) hat dann auch - wie bei Dir - dazu geführt, dass das erst Anfang des Jahres genauer begutachtet werden konnte.

Ok, danke für die detaillierte Bug-Schilderung. Das sieht dann aber nach einem relativ logischen Bug aus, also nichts Spektakuläres, die Auswirkungen sind natürlich, wie oft bei Bugs, dann "tödlich".

Was ich noch nicht so ganz verstanden habe, welche (Sicherheits-?)Vorteile habe ich jetzt (unter der Annahme, dass der Bug hier gefixt ist) von einer Reduktion auf TLS 1.2 und 1.3, wenn 1.0, 1.1, 1.2 und 1.3 ja auch dazu führen, dass 1.2 verwendet wird? Ich verhindere also nur, dass alte Versionen verwendet werden können, weil ich der Überzeugung bin, dass die unsicher sind. Dann kommt im Zweifel mit einem alten Server eben keine Verbindung mehr zu Stande. Ein Server nach neuem Stand benutzt aber eh 1.2 oder sogar schon 1.3, insofern ist eine Einschränkung hier in gewisser Weise ohne Auswirkung. Zusammengefasst könnte man sagen, dass ich die maximale Kompatibilität habe, logisch, wenn ich alles erlaube, also evt. sogar noch SSL, verwendet wird sowieso der höchstmögliche Standard. Wenn ich aber verhindern will, dass auch nicht mehr ganz so sichere Versionen verwendet werden, muss ich einschränken und dann auch damit leben, dass es evt. eben keine Verbindung mehr gibt, im konkreten Fall das DynDNS-Update eben nicht durchläuft. Na ja, damit ist die Frage ja eigentlich schon beantwortet.

Vielen Dank und viele Grüße,
Jirka
GrandDixence
Beiträge: 1054
Registriert: 19 Aug 2014, 22:41

Re: HTTPS/SSL/TLS-Verbindungen werden nicht mehr korrekt aufgebaut mit 10.40-RC1

Beitrag von GrandDixence »

Jirka hat geschrieben: 08 Jan 2020, 17:52
Ist es aber nicht genauso sinnvoll, wenn ich auf TLS 1.1+1.2+1.3 stelle, weil er dann das höchstmögliche TLS-Level nimmt und trotzdem höchstmögliche Abwärtskompatibilität hat?
Gemäss der aktuellen Version von BSI TR-02102-2 ist der Einsatz von SSL 3.0, TLS 1.0 und TLS 1.1 aus Sicherheitsgründen nicht zu empfehlen. Siehe Beitrag vom 09 Jan 2016, 21:30 unter:
viewtopic.php?f=14&t=14937&p=82911#p82911
Antworten