[Info] AVM-Firmware ab 07.10 (Labor-Reihe 07.08) und die Umstellung auf TLSv1.2

[PeterPawn]

Wie AVM in der "info.txt" irgendwo ziemlich zum Ende der Änderungen in dieser Version offenlegt, ist man (lobenswerterweise, das wird niemanden aus meiner Tastatur überraschen) dort inzwischen dazu übergegangen, den Vorschlag aus einem Draft bei der IETF umzusetzen (https://tools.ietf.org/id/draft-moriarty-tls-oldversions-diediedie-00.html) und alle Serverdienste im FRITZ!OS auf TLS ab v1.1 umzustellen - würde man dem Vorschlag in Gänze folgen, hätte man TLSv1.1 auch gleich abgeschaltet und böte nur noch TLS v1.2 an.

So weit, so schön ... und auch nicht wirklich zu beanstanden.

Nur die Art und Weise der Umsetzung führt (wieder mal) bei den Benutzern (und auch Programmierer von Extensions sind am Ende Benutzer des FRITZ!OS) zu grauen Haaren, weil nunmehr sämtliche Versuche, eine TLS-Verbindung mit TLSv1.0 mit einem FRITZ!OS-Serverdienst aufzubauen, vom FRITZ!OS wortlos beendet werden, obwohl doch die Spezifikation (TLSv1.2 - als die höchste derzeit von der Box unterstützte Version - ist in RFC 5246 spezifiziert) etwas vollkommen anderes vorschreibt:

Seite 5 bei den "Änderungen ggü. TLSv1.1": - Alerts MUST now be sent in many cases.

und ausdrücklich auf Seite 86 in Anhang E.1:

A TLS server can also receive a ClientHello containing a version number smaller than the highest supported version. If the server wishes to negotiate with old clients, it will proceed as appropriate for the highest version supported by the server that is not greater than ClientHello.client_version. For example, if the server supports TLS 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will proceed with a TLS 1.0 ServerHello.

If server supports (or is willing to use) only versions greater than client_version, it MUST send a "protocol_version" alert message and close the connection.
[...]
Note: some server implementations are known to implement version negotiation incorrectly. For example, there are buggy TLS 1.0 servers that simply close the connection when the client offers a version newer than TLS 1.0. Also, it is known that some servers will refuse the connection if any TLS extensions are included in ClientHello. Interoperability with such buggy servers is a complex topic beyond the scope of this document, and may require multiple connection attempts by the client.

Irgendwo in der Mitte steht auch noch der richtige "(fatal) alert code" für diesen "protocol_version"-Fehler, es ist die 70. Ein paar Sätze weiter steht dann (in Abschnitt 7.2.2) etwas wie:

Whenever an implementation encounters a condition which is defined as a fatal alert, it MUST send the appropriate alert prior to closing the connection.

Ich habe keine (wirkliche) Ahnung, auf welchen TLS-Stack sich AVM bei der Implementierung der eigenen Serverdienste stützt ... aber ich kann das problemlos mit einem (korrekt konfigurierten) Apache2-Server (der OpenSSL verwendet) vergleichen und von dem erhalte ich (sofern er darauf konfiguriert wurde, nur noch TLSv1.2 zuzulassen - "SSLProtocol -all +TLSv1.2") die in diesem Screenshot aus Wireshark zu sehende "alert"-Meldung, BEVOR er die Verbindung beendet:

An der generellen Unfähigkeit von OpenSSL kann es also eigentlich nicht liegen, wenn man bei der FRITZ!Box (genauer bei FRITZ!OS ab Version 07.08) so ohne jede Idee leben muß, was dem TLS-Server denn nun an den eigenen Bemühungen, sich mit ihm ins Benehmen zu setzen, nicht gefallen mag.

Bei solchen Verstößen gegen die "Internet-Protokolle" muß sich AVM dann auch nicht wundern, wenn man mal "außer der Reihe" dafür gescholten wird, was man da doch für einen Mist verzapft, selbst wenn man am Ende vielleicht gar nichts dazu kann, weil der TLS-Stack es falsch macht.

Aber wenn ich als Hersteller hingehe und so eine (der Sicherheit durchaus dienliche) Aktion durchziehe, daß ich nur noch moderne Verschlüsselungsverfahren zulassen will (was absolut zu begrüßen ist), dann sollte ich das aber wenigstens auch einmal testen, daß meine Implementierung danach noch dem entspricht, was andere (dafür gibt es die RFC als Internet-Standards ja) von mir erwarten können - da kann ich die Schuld an diesem "Fauxpas" nicht dem Hersteller des TLS-Stacks zuschustern.

Wenn ein Browser am Beginn auch nur mit TLSv1.0 auf den Server in der FRITZ!Box losrennt, kriegt nämlich auch der keinerlei Idee vermittelt, was dem Server denn nun bitte nicht passen könnte:

vidar:~ $ openssl s_client -connect 192.168.178.1:443 -msg -debug -tls1
CONNECTED(00000003)
>>> ??? [length 0005]
    16 03 01 00 61
>>> TLS 1.0Handshake [length 0061], ClientHello
    01 00 00 5d 03 01 34 d3 92 5d a9 5a c3 03 b4 43
    9f 1e d9 22 ee 82 2f 0b bd ad 8e 8a c6 03 b3 46
    25 3c 37 23 c5 ce 00 00 12 c0 0a c0 14 00 39 c0
    09 c0 13 00 33 00 35 00 2f 00 ff 01 00 00 22 00
    0b 00 04 03 00 01 02 00 0a 00 0a 00 08 00 1d 00
    17 00 19 00 18 00 23 00 00 00 16 00 00 00 17 00
    00
write to 0x563281026000 [0x5632810f4b30] (102 bytes => 102 (0x66))
0000 - 16 03 01 00 61 01 00 00-5d 03 01 34 d3 92 5d a9   ....a...]..4..].
0010 - 5a c3 03 b4 43 9f 1e d9-22 ee 82 2f 0b bd ad 8e   Z...C..."../....
0020 - 8a c6 03 b3 46 25 3c 37-23 c5 ce 00 00 12 c0 0a   ....F%<7#.......
0030 - c0 14 00 39 c0 09 c0 13-00 33 00 35 00 2f 00 ff   ...9.....3.5./..
0040 - 01 00 00 22 00 0b 00 04-03 00 01 02 00 0a 00 0a   ..."............
0050 - 00 08 00 1d 00 17 00 19-00 18 00 23 00 00 00 16   ...........#....
0060 - 00 00 00 17 00 00                                 ......
read from 0x563281026000 [0x5632810eb913] (5 bytes => -1 (0xFFFFFFFFFFFFFFFF))
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 102 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1556968799
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---
vidar:~ $

Die Nachricht "SSL handshake has read 0 bytes ..." beschreibt hier auch sehr schön, wie das FRITZ!OS reagiert - es schließt eben einfach die, der TLS-Verbindung zugrundeliegende, TCP-Verbindung und der TLS-Client darf sich jetzt aussuchen, warum die FRITZ!Box wohl eingeschnappt ist.

Nicht jeder Programmierer, der über das GUI und/oder TR-064 zugreifen will, muß sich parallel dazu auch noch mit Protokollen im Allgemeinen und TLS im Speziellen auskennen und sich dem Problem durch eine Paketanalyse nähern können.

Für all diejenigen, sollte zumindest auch irgendwo in den TR-064-Beschreibungen (wenn man die schon gerade erst überarbeitet hat) nachzulesen sein, welche TLS-Version AVM hier unbedingt voraussetzt und daß man nicht damit rechnen sollte, daß die Umsetzung der TLS-Kommunikation immer den "offiziellen" Internet-Standards entspricht. Selbst wenn man letzteres gedenkt zu ändern und sich der Hinweis damit erledigt haben könnte, wäre ein Hinweis bzgl. der minimalen TLS-Version sicherlich trotzdem hilfreich (und man bricht sich dabei auch nichts ab - nur noch "gute Verschlüsselung" zu verwenden, ist ja eigentlich ein positiver Aspekt).

 

[Kopeng]

Hast du das gemeldet? Ich vielleicht auch einfach nur ein Bug. AFAIK wird nämlich OpenSSL verwendet.