TLS v1.0 Client finished

[Ralf_C (Gast)]

Ich habe bereits einige Jahre eine Anwendung auf einem Mikrocontroller 
am laufen, welche alle 30 Minuten eine Webseite aufruft. Daten dieser 
Webseite werden dann auf einem Display dargestellt. Jetzt wurde diese 
Webseite von HTTP auf HTTPS umgestellt und nichts funktioniert mehr.
Um die Anwendung wieder zum Laufen zu bekommen, habe ich begonnen das 
Programm um SSL/TLS zu erweitern.

Der verwendete Mikrocontroller: PIC24FJ128GA204 mit Cryptographic Engine
Das gewählte TLS Protocol: TLS v1.0
Die gewählte Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)

Der Verbindungsaufbau bis "Change Cipher Specification" funktioniert 
bereits.
Beim Senden der Handshake-Nachricht "Client finished" erhalte ich aber
die Fehlermeldung "Bad Record MAC".

Meine Berechnungen Hash-MD5, Hash-SHA1, HMAC-SHA1, PRF, Master-Secret, 
Key-Block habe ich entweder mit Testdaten aus dem Internet oder dem 
Vergleich mit Online-Tools überprüft, so dass diese funktionieren 
sollten.
Das Problem vermute ich vielmehr bei den Eingangsdaten der Berechnungen 
oder in dem Zusammenbau der "Client finished"-Nachricht. Hier sind mir 
einige Formulierungen nicht ausreichen verständlich.

Der Zusammenbau der "Client finished"-Nachricht erfolgt in folgenden 
Schritten:

----------------------------
Hash-MD5 und Hash-SHA1 über alle Handshake Messages

Sind dies??? in der folgenden Reihenfolge???
   - Client Hello
  - Server Hello
   - Server Certificate
  - Server Hello Done
   - Client Key Exchange
   - Client Change Cipher Spec --> gehört nicht dazu???

Laut RFC 2246: This is only data visible at the handshake layer
and does not include record layer headers.
Was ist mit "record layer header" genau gemeint???

Sind das die nur ersten 5 Byte "16 03 01 00 5A"??? aber die folgenden
4 Byte "01 00 00 56" des Handshake Type dürfen nicht entfallen???
Entsprechend folgendem Beispiel:

TLSv1 Record Layer: Handshake Protocol: Client Hello
                   Handshake Type: Client Hello (1)
                        ssl.handshake.length 86
                                |-> data
16 03 01 00 5A     01 00 00 56   03 01 57 31 1C.....
| record header |  |--> Message-Daten für Hash-Funktionen???
  entfällt???

----------------------------

Berechnen der "verify_data" mit der Funktion
 PRF (master_secret, finished_label, MD5-Hash [16 Byte] + SHA1-Hash [20 
Byte])
Die PRF liefert beliebig viele Bytes, wovon die ersten 12 Byte als Daten 
für die "Client finished"-Nachricht verwendet werden???

----------------------------

Diese 12 Byte "verify_data" werden ergänzt durch???
   - 8 Byte sequence number 00 00 00 00 00 00 00 00
  - 5 Byte record header   16 03 01 00 30 ???
  - 4 Byte message header  14 00 00 0C

so dass folgende Daten entstehen???

00 00 00 00 00 00 00 00    16 03 01 00 30   14 00 00 0C   +
PRF "verify_data" [12 Byte]

Über diese 29 Byte??? wird dann die MAC berechnet mit der Funktion 
HMAC-SHA1 unter der Verwendung des "client_write_MAC_secret" aus dem 
Key-Block???

----------------------------

Mit der berechneten MAC [20 Byte] werden 48 Byte Daten für die 
Eingangsdaten für die AES 128-Encryption wie folgt gebildet???

14 00 00 0C   + PRF "verify_data" [12 Byte]  + MAC [20 Byte] +
0B ... 0B [12 Byte Padding]

----------------------------

Diese 48 Byte Chipertext aus der AES 128-Encryption werden dann mit den
5 Byte record header   "16 03 01 00 30" als "Client finished"-Nachricht
verschickt.

----------------------------

Immer dort, wo ich ??? eingefügt habe, bin ich mir nicht sicher, ob ich 
richtig liege.

MfG

[Jim M. (turboj)]

Ralf_C schrieb:
> TLS v1.0
> Die gewählte Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)

Dieses veraltete Zeuchs würde im SSL Test negativ bewertet und ist daher 
bei moderen Servern oft deaktiviert. Ebenso MD5 und SHA-1 Hash, auch 
diese betrachtet man nicht mehr als sicher.

Und nein, SSL will man nicht selbst auf nem µC implementieren, man will 
da OpenSSL oder ähnliches haben.

Ralf_C schrieb:
> Daten dieser
> Webseite werden dann auf einem Display dargestellt.

Wenn das kein passives LCD ist, würde ein Raspberry Pi den 
Stromverbrauch nicht ernsthaft erhöhen und wäre dick genug für SSL.