[Sake Blok <sake@xxxxxxxxxx>]

On Wed, May 28, 2008 at 10:57:36AM -0600, Al Aghili wrote:
>
> Ok I've attached parts of the debug file. There is no "Unknown Record"
> in this file or the output of tshark. Some more info on the environment.
> Its very high load and these are http SOAP calls. So the client is a
> SOAP client not a browser.

Actually, to the ssl-decryption, it doesn't matter what type of client
makes the call, it just sees payload data that it wants to decrypt :-)

> One other thing. When we run tshark we have to start it with "data" not
> "http". If we start it with http we won't see anything. Not even the
> headers. So the argument to tshark looks like this (note the data after
> 443).
> 
> tshark  -i 1 -R ssl.app_data  -V -l -d tcp.port\=\=8001,http  -o
> ssl.keys_list\:192.168.15.30,443,data,/Wireshark/cert.pem

Wel, this tells Wireshark to not dissect the decrypted data any
further. I think the http-reassembly wants more data to be able
to construct the request PDU, but... (read on after the ssl-debug
info)


> I won't be able to send you the private key. This is financial
> institution and the same certificate is used in the qa and prod. Let me
> know if you need anything else from me and I can provide it for you.

OK, I understand, let's see if we can get any further without it.

> Could it be possible that the header is sent as part of a different
> session than the body and the response?

Nope, all http-servers I know, read the header and body of the request
from the same tcp connection and send the header and body of the 
response back over that tcp session.

> I really appreciate your help on this.

You're welcome, there is always room to improve Wireshark or fix
it's bugs. So hopefully your issue will result in a fix for Wireshark
that other people benefit from too :-)


[ skipped to the interesting bit ]

> dissect_ssl enter frame #1152 (first time)
>   conversation = 0x9826800, ssl_session = 0x9827e48
> dissect_ssl3_record: content_type 23
> decrypt_ssl3_record: app_data len 352 ssl, state 0x1F
> association_find: TCP port 39617 found 0x0
> packet_from_server: is from server - FALSE
> decrypt_ssl3_record: using client decoder
> ssl_decrypt_record ciphertext len 352
> Ciphertext[352]:
> 54 3e 13 f2 c0 a0 ad 46 e9 65 c6 e7 24 13 35 eb 
> 62 aa f3 5a 52 89 01 0f 10 2a 96 db ef b5 32 fe 
> 1a 26 b9 24 63 2b 19 09 b7 a8 27 23 ba d7 45 ac 

[ skipped again to another interesting bit ]

> dissect_ssl enter frame #1153 (first time)
>   conversation = 0x9826800, ssl_session = 0x9827e48
> dissect_ssl3_record: content_type 23
> decrypt_ssl3_record: app_data len 352 ssl, state 0x1F
> association_find: TCP port 39617 found 0x0
> packet_from_server: is from server - FALSE
> decrypt_ssl3_record: using client decoder
> ssl_decrypt_record ciphertext len 352
> Ciphertext[352]:
> 54 3e 13 f2 c0 a0 ad 46 e9 65 c6 e7 24 13 35 eb 
> 62 aa f3 5a 52 89 01 0f 10 2a 96 db ef b5 32 fe 
> 1a 26 b9 24 63 2b 19 09 b7 a8 27 23 ba d7 45 ac 

[ skipped to the really interesting bit ]

> ssl_decrypt_record found padding 0 final len 351
> checking mac (len 331, version 300, ct 23 seq 2)
> ssl_decrypt_record: mac failed

It looks like frame 1153 is a retransmission of frame 1152. Is
that correct? If it is, it messes up the ssl state machine, as 
it gets the same data to decrypt twice. Since that won't work
the mac (message authentication code) will fail. After that
nothing in that flow can't be decrypted anymore. This is an
issue that needs to be solved in Wireshark. There was actually
a thread on the dev-list about it recently.

You could manually remove the retransmitted frames from the 
capture file. That might help you out. Also, I'm not sure if
the program 'ssldump' might ignore the retransmissions. Since 
this program does not have to dissect and show every packet in
detail, it might be more useful in this case.

Cheers,
    Sake