E-Mail Benachrichtigung geht nicht

[DirkK]

Bei uns funktioniert der E-Mail-Versand über securesmtp.t-online.de nicht mehr.

Zugangsdaten wurden verifiziert. Ein anderer Provider klappt problemlos.

Stimmt, ist seit einigen Tagen bei mir auch so!

VG Dirk

[Hagen2000]

Kann das evtl. mit LCOS 10.80 und der neueren OpenSSL-Library zusammenhängen?

[rotwang]

Das schaut dann so aus:

OK, der Server will TLS 1.3 machen, aber er möchte fürs Key-Agreement eine andere DH-Gruppe machen, als der LANCOM-(TLS-)Client vorgeschlagen hat. Deshalb wird der Client Hello wiederholt, diesmal mit einem DH-Schlüsselpaar aus der vom Server gewünschten Gruppe. Und darauf kommt dann vom Server nichts mehr und nach einer halben Minute bricht da LANCOM den TLS-Verbindungsaufbau ab.

Du kannst versuchen, unter Setup/Mail/SSL auf der CLI mit den TLS-Parametern zu spielen (die Punkte gibt's nicht im LANconfig).

-Probeweise mal TLS 1.3 abschalten (bei TLS 1.2 gibt's keinen solchen Hello Retry Request),
-Probeweise mal secp384r1 bei den Elliptic-Curves rausnehmen, so daß der Server gar nicht auf die Idee kommt, das zu fordern.

[hyperjojo]

hi rotwang,

mit

Code: Alles auswählen

set /Setup/Mail/SSL/Versions TLSv1.2
set /Setup/Mail/SSL/Elliptic-Curves secp256r1,secp521r1,x25519,x448

funktioniert es. Ist TLS1.3 und/oder secp384r1 gesetzt, funktioniert kein Mailversand.

Gruß hyperjojo

[Hagen2000]

Bei mir klappt es ohne TLSv1.3 ebenfalls wieder. Die zweite Variante ohne secp384r1 habe ich nicht probiert, nachdem hyperjojo das ja schon gemacht hat.

Bei einem kurzen Blick in die älteren Konfigurationssicherungen und Release Notes scheint TLSv1.3 mit LCOS 10.40 implementiert worden sein, das war bereits im Jahr 2020.

[rotwang]

Bei mir klappt es auch, wenn ich TLS 1.3 angeschaltet lasse und stattdessen die Einstellung für 'Elliptic Curves' auf nur secp384r1 stelle. Das sorgt dafür, dass der TLS-Client im LCOS direkt im ersten Client Hello ein Schlüsselpaar aus dieser Gruppe anbietet und es zu keinem Hello Retry Request kommt.

Bei einem kurzen Blick in die älteren Konfigurationssicherungen und Release Notes scheint TLSv1.3 mit LCOS 10.40 implementiert worden sein, das war bereits im Jahr 2020.

Ich gehe davon aus, dass auf der Telekom-Seite etwas an der Server-Konfiguration geändert wurde. Es sieht so aus, als wolle der Telekom-Server unbedingt Diffie-Hellman auf Basis der 384 Bit-Kurve machen und akzeptiert nichts kleineres. Das ist etwas ungewöhnlich, werden doch allgemein im Web Key Agreements auf Basis von 256 Bit Kurven (secp256r1, x25519) als hinreichend sicher angesehen.

Was im Falle LCOS<->Telekom bei der 'Extrarunde' mit dem Telekom-Server schief geht, ist noch zu klären, aber nicht ganz einfach, wenn der einfach gar nicht mehr antwortet...

[GrandDixence]

Ich sehe in den Screenshots von mathias.o immer nur die Konfiguration des Serverports TCP 587 (STARTTLS) für den E-Mailversand (SMTP).
Für den sicheren, verschlüsselten E-Mailversand ist Serverport TCP 465 zu verwenden (implizites TLS). Die Nutzung von STARTTLS sollte aus Sicherheitsgründen nach Möglichkeit vermieden werden! Siehe dazu:
https://www.golem.de/news/verschluessel ... 58714.html

https://de.wikipedia.org/wiki/STARTTLS

Und wenn der Mailserver keinen E-Mailversand über den Serverport TCP 465 unterstützt, wäre wohl der Wechsel zu einem sicheren E-Mailanbieter angebracht. Zum Beispiel: Posteo.de oder Mailbox.org

[rotwang]

Das hat mit diesem Problem eher wenig zu tun, das tritt unabhängig davon auf, ob man STARTTLS benutzt oder nicht. Der Telekom-Server unterstützt beides, man kann sich die Gegenstelle ja nicht immer aussuchen...

[Hagen2000]

So ist es bei mir auch konfiguriert: Port 465 und Verschlüsselung/TLS steht auf Verschlüsselt (SMTPS).
Das Problem tritt aber unabhängig vom Port auf.
Edit: rotwang war schneller.

[GrandDixence]

Wurde die "signature_algorithms extension" im Zusammenspiel mit dem Mailserver "securesmtp.t-online.de" schon kontrolliert?
https://timtaubert.de/blog/2016/07/the- ... es-in-tls/
In Wireshark ist diese Erweiterung sicher ersichtlich.

[rotwang]

Zum Signieren von irgendwelchen Daten kommt es hier im Fehlerfall erst gar nicht. Der von mir zuletzt genannte Workaround (TLS 1.3 angeschaltet lassen und Abschalten aller Elliptic-Curves bis auf secp384r1) beeinflusst die supported_groups Extension im Client Hello und indirekt auch den initial im Key Share angebotenen ECDHE-Schlüssel.

[Jirka]

Interessanter Thread...

Den [Trace] bitte nicht über den LANtracer machen, sondern direkt auf der CLI, weil der LANtracer selber per Telnet über SSL/TLS auf die LCOS-CLI zugreift, und man einen Schneeballeffekt kriegt.

Der User "Dr.Einstein", der sich selber hier leider derzeit nicht mehr äußern kann, weil er sich nicht mehr einloggen kann, weswegen ich hier gerade mal ins Forum geschaut habe und das hier zufällig lese, hatte mir hier mal mitgeteilt, dass LANtracer inzwischen auch SSH nutzt. Sofern also der Zugang über SSH in den Geräteeigenschaften in LANconfig korrekt hinterlegt ist und funktioniert, wird dieser bevorzugt verwendet. In dem Fall hätte man das Problem dann nicht, aber ansonsten ist das natürlich völlig richtig (von der zweiten Ausnahme abgesehen, wenn nur unverschlüsseltes Telnet im LANCOM-Router zugelassen wurde).

Zu dem eigentlichen Thema dieses Threads: Wäre ja mal interessant, was die Telekom dazu sagt (also insbesondere zu den Sachen die rotwang heute um 9:01 Uhr geschrieben hat). Ich habe derartige Änderungen bei den SSL/TLS-Verschlüsselungen jetzt schon mehrfach unangekündigt erlebt, das letzte war der Provider ALL-INKL. Alte Software/alte Geräte können da nicht mehr mithalten und E-Mails können (plötzlich) nicht mehr abgesetzt werden, die Funktionalität ist also nicht mehr gegeben. Da bleibt dann nur die Verschlüsselung ganz auszustellen und unverschlüsselt zu senden - schöne neue Welt! (Natürlich mit einem extra dafür hergerichteten E-Mail-Konto nur zum Versenden.)

Viele Grüße
Jirka

[MoinMoin]

Moin Jirka,

da kannst du froh sein, wenn der Provider überjaupt noch unverschlüsselte Verbindungen erlaubt. Normal dürfte mittlerweile sein, daß auf einer unverschlüsselten Verbindung zwingend erst STARTTLS gemacht werden muß, ehe man sich anmelden kann.

Ciao, Georg

[rotwang]

Zu dem eigentlichen Thema dieses Threads: Wäre ja mal interessant, was die Telekom dazu sagt (also insbesondere zu den Sachen die rotwang heute um 9:01 Uhr geschrieben hat).

Da wird man vermutlich keine Antwort bekommen. Ich vermute aber mal, dass neue BSI-Richtlinien reinspielen, die die Sicherheit von 2K RSA-Schlüsseln in Frage stellen. Was umstritten ist, siehe die aktuelle c't. Schaut man sich den TLS-Handshake mal ansonsten an, dann sieht man, daß der Server TLS_AES_256_GCM_SHA384 als Cipher-Suite wählt und einen 4K RSA-Schlüssel im Zertifikat hat. Das wäre vor 2,3 Jahren noch unter "Enterprise/Government/Military Grade" Verschlüsselung gelaufen...

[Hagen2000]

Welcher Workaround ist denn nun zu bevorzugen: TLSv1.3 abschalten oder die Elliptic Curves auf den Wert secp384r1 reduzieren?