R884VA SSL Fehler

[sw2090]

Hiho,

seit heute hat unser Nagios auf einmal bei etlichen unserer R884VA SSL Fehler wenn es versucht per https zuzugreifen:

CRITICAL - Cannot make SSL connection.
22753958097344:error:0407E068:rsa routines:RSA_verify_PKCS1_PSS_mgf1:bad signature:../crypto/rsa/rsa_pss.c:124:
22753958097344:error:1417B07B:SSL routines:tls_process_cert_verify:bad signature:../ssl/statem/statem_lib.c:492:

hat wer nen Tipp woran das liegen könnte?
Firmware ist hauptsächlich Telekom LCOS 10.32 aber ich habe es auch mit einem der schon auf 10.34 ist...

Gruß
Sebastian

[GrandDixence]

Entweder ist der Nagios nicht TLS 1.3 kompatibel.
fragen-zum-thema-vpn-f14/vpn-baut-sich- ... 17846.html

Oder das X.509-Zertifikat des R884VA wurde ausgewechselt und verwendet neu ein neues Signaturverfahren, welches vom Nagios nicht unterstützt wird.
https://timtaubert.de/blog/2016/07/the- ... es-in-tls/

Mit Wireshark den TLS-Verbindungsaufbau aufzeichnen, auswerten oder hier die *.pcap/*.pcapng-Datei veröffentlichen.
viewtopic.php?f=31&t=17621&p=99943#p99943

[sw2090]

hi

ein paar Details:

gerade im Browser mal geprüft:

R884VA mit 10.32 (funktioniert noch im nagios/icinga) und einen mti 10.34 (ssl Fehler).
Es trifft nur Lancoms mit 10.34.

Laut meinem Browser verwernden aber beide Versionen die selben Algorithmen und TLS Version (TLS_AES_128_GCM_SHA256, 128-Bit-Schlüssel, TLS 1.3)
und auch im Zertifikat selber sehe ich im Gui keine Unterschiede.
Demnach muss das Nagios/icinga bzw dei (open)ssl lib dad runter offensichtlich tls 1.3 unterstützen. Sonst dürfte garkein Lancom mehr per ssl monitorbar sein.
Demnach muss das an etwas anderem liegen...

[sw2090]

So mal auch noch mit Openssl extrahiert und vergliechen:

1. unterschied:

v10.32:

X509v3 extensions:
X509v3 Subject Key Identifier:
8E:AA:7B:7F:40:9D:A7:B5:BC:C9:C7:1A:AB:9B:9D:A4:59:F8:29:89
X509v3 Authority Key Identifier:
keyid:8E:AA:7B:7F:40:9D:A7:B5:BC:C9:C7:1A:AB:9B:9D:A4:59:F8:29:89

X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Key Usage: critical
Certificate Sign, CRL Sign

v.10.34:

X509v3 extensions:
X509v3 Subject Alternative Name:
IP Address:10.17.254.41

Außerdem steht bei 10.34 einmal die IP als CN im Zertifikat Subjet und bei 10.32 beidemal die Seriennr des Zertifikates.

[sw2090]

noch ein Fakt:

connection test mit openssl s_client -showcerts -connect <ip:port>

Openssl 1.0.1e:

lan ip: n/a (kann ich von da nicht erreichen da intern und der Server steht extern)
wan ip: keine ssl Fehler

Openssl 1.1.1
lan ip: ssl Fehler
wan ip: ssl Fehler

[sw2090]

weitere Details:

es sieht für mich so aus als wenn tls 1.3 in dem Zertifikat von oder sogar ab 10.34 broken ist.
mit openssl 1.0.1 treten die ssl Fehler nicht auf weil das kein tls 1.3 kann. Es macht dann halt 1.2 und das geht ohne Fehler.
mit openssl 1.1.1 handshaked es wenn man nichts erzwingt auf tsl 1.3 und das wirft besagte Fehler.
Zwingt man openssl 1.1.1 tls 1.2 zu machen treten die Fehler auch hier nicht auf.

Lancom/Telekom please fix.

[alf29]

Moin,

mit dem Zertifikat hat das überhaupt nichts zu tun, im Zertifikat wird gar keine TLS-Protokollversion kodiert. Es hatte damit zu tun, daß in der 10.34 beim Signieren die Hashes unter bestimmten Bedingungen durcheinander gingen. Wenn Du's genau wissen willst: Es sollte eine RSA-PSS-SHA256-Signatur eines SHA384-Digests gebildet werden, es wurde stattdessen eine RSA-PSS-SHA256-Signatur eines SHA256-Digests gebildet.

Wann eine 10.34 mit dem Fix kommen wird, insbesondere für Telekom-Geräte, kann ich leider nicht abschätzen. Schalte als Workaround unter Setup/HTTP/SSL/Hash-Algorithms SHA-384 aus, dann sollte auch mit der 10.34 TLS 1.3 gehen.

Viele Grüße

Alfred