This commit is contained in:
Hannes Mehnert 2016-05-06 22:30:20 +01:00
parent 177a266ffe
commit 6ce1f73a95

View file

@ -21,7 +21,7 @@ I tried hard, but could not reproduce, but was very worried and was eager to fin
![encrypted alert](https://www.cl.cam.ac.uk/~hm519/encrypted-alert.png) ![encrypted alert](https://www.cl.cam.ac.uk/~hm519/encrypted-alert.png)
What is happening on the wire? After some data is successfully transferred, at some point the client sends an encrypted alert (see above). The TLS session used a RSA key exchange and I could decrypt the TLS stream with wireshark, which revealed that the alert was indeed a bad record MAC. Wireshark's "follow SSL stream" showed all client requests, but not all server responses. The TLS level trace from the server showed properly encrypted data. I tried to spot the TCP payload which caused the bad record MAC, starting from the alert in the client capture (the offending TCP frame should be closely before the alert). What is happening on the wire? After some data is successfully transferred, at some point the client sends an encrypted alert (see above). The TLS session used a RSA key exchange and I could decrypt the TLS stream with Wireshark, which revealed that the alert was indeed a bad record MAC. Wireshark's "follow SSL stream" showed all client requests, but not all server responses. The TLS level trace from the server showed properly encrypted data. I tried to spot the TCP payload which caused the bad record MAC, starting from the alert in the client capture (the offending TCP frame should be closely before the alert).
![client TCP frame](https://www.cl.cam.ac.uk/~hm519/tcp-frame-client.png) ![client TCP frame](https://www.cl.cam.ac.uk/~hm519/tcp-frame-client.png)