Missing TLS/HTTP reassembly of server replies

asked 2020-04-15 10:39:11 +0000

kenofischer gravatar image

I'm looking at a traffic capture for an HTTPS connection that just repeatedly requests the same file from the server. If I follow the HTTP stream, I see all the client requests, but the server replies are missing. E.g. in the HTTP follow window I see:

.zRZI.GET /signals/10737/1574792548712.wav HTTP/1.1 Host: public-test-bucket-quatrix.s3.amazona... User-Agent: HTTP.jl/1.5.0-DEV.623 Content-Length: 0

GET /signals/10737/1574792548712.wav HTTP/1.1 Host: public-test-bucket-quatrix.s3.amazona... User-Agent: HTTP.jl/1.5.0-DEV.623 Content-Length: 0

(the first couple bytes are the tail of the first server response, which does get decoded properly). Is there some setting I'm missing that would make this work?

Capture of just this TCP stream available here: https://drive.google.com/open?id=133K...

edit retag flag offensive close merge delete

Comments

As that appears to be a TLS stream we're not going to be able to see any HTTP traffic without the necessary decryption material, which in this case will have to be the pre-master secret Are you able to provide that?

grahamb gravatar imagegrahamb ( 2020-04-15 12:56:08 +0000 )edit

Ah, I thought the export would save the key material along with the stream. See here for the key log: https://drive.google.com/open?id=1zlA...

kenofischer gravatar imagekenofischer ( 2020-04-15 13:09:31 +0000 )edit

The capture now decrypts. I suspect the number of out-of-order packets and retransmissions are breaking HTTP reassembly. With the following TCP and HTTP preferences set I get the first 6 HTTP responses showing up,but nothing after that:

  • TCP: All subdissectors to reassemble TCP streams - ON
  • TCP: Reassemble out-of-order segments - OFF
  • TCP: Do not call subdissectors for error packets - OFF
  • HTTP: All Reassemble options - ON
grahamb gravatar imagegrahamb ( 2020-04-15 14:06:44 +0000 )edit

Thanks, that does help a bit, but I think turning off the "Reassemble out-of-order segments" option, also confuses the TLS dissector into giving some weird packet types later in the stream. Do you think it would be feasible to improve wireshark to allow HTTP reassembly even in the presence of these out-of-order packets?

kenofischer gravatar imagekenofischer ( 2020-04-15 22:25:41 +0000 )edit

I've done a bit of work on the TCP reassembly code, and then dissector reassembly, e.g. for UDP, and it's really tricky to work on. I suggest you create a bug over at the Bugzilla and attach this capture and the secrets log file.

grahamb gravatar imagegrahamb ( 2020-04-16 09:51:22 +0000 )edit
add a comment