Alright, I have generated logs from my server showing unencrypted outbound packets and iv encryption numbers followed by outbound encrypted packets. I have modified winscp to display the IV when decrypting and the blocksize long encrypted value when the decrypted packet length is garbled.
What I see is that winscp is skipping several packets and thus attempting to decrypt with the wrong IV. I generated a capture using network monitor on the server and found all the packets going out in order. I did notice that several packets are going out in the same TCP frame. The first one in that frame is the last one that winscp successfully decrypts. The rest in that frame get ignored and winscp tries to process the packet in the following frame is if though there had been no intervening packets.
I am attaching a zip with 3 files that show the problem.
-
server2client_tcpstream.txt, a text file containing the TCP payload for the 2 frames in question
-
debug.log, a pruned log showing the relevant outbound data from the server
-
ssh1.log, the modified WinSCP log.
If you want the network capture that file 1 was derived from just let me know. It is too large but I can put it on a webserver and send a url via email.
If you would like to contact me directly via email I can give you an account on this server. the bug is speed dependent. you need be able to upload at faster than about 1400 KB/s for it to happen so you may or may not be able to reproduce it. It varies when it happens, though it almost always happens before 200 MBs have been uploaded.
-
Archive.zip (59.7 KB, Private file)
Description: 1. server2client_tcpstream.txt, a text file containing the tcp payload for the 2 frames in question
2. debug.log, a pruned log showing the relevant outbound data from the server
3. ssh1.log, the modified winscp log.
