hannes/hannes.robur.coop
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

.

Browse source
This commit is contained in:
Hannes Mehnert 2016-05-06 22:30:20 +01:00
parent 177a266ffe
commit 6ce1f73a95
1 changed files with 2 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
Posts/BadRecordMac
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)