["Al Aghili" <aaghili@xxxxxxxxxxxxxxxxxx>]

Sake,
I think you're correct. I've included the actual frames. But it does
look like this is retransmission. Is this something that we can change
on the client? Why would a retransmission occur? 

We are using tshark standard out to look at the frames. When you say
manually remove the frame from the capture file are you suggesting to
first have tshark create a capture file then remove the redundant frame
from the file and then feed the capture file back through tshark for
decryption? I could programmically do that I just want to understand
what steps I need to take and how to run tshark.

Thanks











Frame 1152 (64 bytes on wire, 64 bytes captured)
    Arrival Time: May 13, 2008 10:50:18.033536000
    [Time delta from previous captured frame: 0.000002000 seconds]
    [Time delta from previous displayed frame: 0.000002000 seconds]
    [Time since reference or first frame: 6.773458000 seconds]
    Frame Number: 1152
    Frame Length: 64 bytes
    Capture Length: 64 bytes
    [Frame is marked: False]
    [Protocols in frame: eth:ip:tcp:ssl]
Ethernet II, Src: TyanComp_30:56:6a (00:e0:81:30:56:6a), Dst:
Resilien_01:04:6b (00:60:ac:01:04:6b)
    Destination: Resilien_01:04:6b (00:60:ac:01:04:6b)
        Address: Resilien_01:04:6b (00:60:ac:01:04:6b)
        .... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
    Source: TyanComp_30:56:6a (00:e0:81:30:56:6a)
        Address: TyanComp_30:56:6a (00:e0:81:30:56:6a)
        .... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
    Type: IP (0x0800)
    Frame check sequence: 0x7c6a7f06 [correct]
Internet Protocol, Src: 192.168.15.30 (192.168.15.30), Dst: 192.168.15.1
(192.168.15.1)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 46
    Identification: 0x247f (9343)
    Flags: 0x04 (Don't Fragment)
        0... = Reserved bit: Not set
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: TCP (0x06)
    Header checksum: 0x76db [correct]
        [Good: True]
        [Bad : False]
    Source: 192.168.15.30 (192.168.15.30)
    Destination: 192.168.15.1 (192.168.15.1)
Transmission Control Protocol, Src Port: https (443), Dst Port: 30176
(30176), Seq: 3224, Ack: 309, Len: 6
    Source port: https (443)
    Destination port: 30176 (30176)
    Sequence number: 3224    (relative sequence number)
    [Next sequence number: 3230    (relative sequence number)]
    Acknowledgement number: 309    (relative ack number)
    Header length: 20 bytes
    Flags: 0x18 (PSH, ACK)
        0... .... = Congestion Window Reduced (CWR): Not set
        .0.. .... = ECN-Echo: Not set
        ..0. .... = Urgent: Not set
        ...1 .... = Acknowledgment: Set
        .... 1... = Push: Set
        .... .0.. = Reset: Not set
        .... ..0. = Syn: Not set
        .... ...0 = Fin: Not set
    Window size: 5840
    Checksum: 0xdcd4 [correct]
        [Good Checksum: True]
        [Bad Checksum: False]
    [SEQ/ACK analysis]
        [TCP Analysis Flags]
            [This frame is a (suspected) out-of-order segment]
Secure Socket Layer
    TLSv1 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec
        Content Type: Change Cipher Spec (20)
        Version: TLS 1.0 (0x0301)
        Length: 1
        Change Cipher Spec Message

Frame 1153 (111 bytes on wire, 111 bytes captured)
    Arrival Time: May 13, 2008 10:50:18.033537000
    [Time delta from previous captured frame: 0.000001000 seconds]
    [Time delta from previous displayed frame: 0.000001000 seconds]
    [Time since reference or first frame: 6.773459000 seconds]
    Frame Number: 1153
    Frame Length: 111 bytes
    Capture Length: 111 bytes
    [Frame is marked: False]
    [Protocols in frame: eth:ip:tcp:ssl]
Ethernet II, Src: TyanComp_30:56:6a (00:e0:81:30:56:6a), Dst:
Resilien_01:04:6b (00:60:ac:01:04:6b)
    Destination: Resilien_01:04:6b (00:60:ac:01:04:6b)
        Address: Resilien_01:04:6b (00:60:ac:01:04:6b)
        .... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
    Source: TyanComp_30:56:6a (00:e0:81:30:56:6a)
        Address: TyanComp_30:56:6a (00:e0:81:30:56:6a)
        .... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
    Type: IP (0x0800)
    Frame check sequence: 0x1e385955 [correct]
Internet Protocol, Src: 192.168.15.30 (192.168.15.30), Dst: 192.168.15.1
(192.168.15.1)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 93
    Identification: 0x2480 (9344)
    Flags: 0x04 (Don't Fragment)
        0... = Reserved bit: Not set
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: TCP (0x06)
    Header checksum: 0x76ab [correct]
        [Good: True]
        [Bad : False]
    Source: 192.168.15.30 (192.168.15.30)
    Destination: 192.168.15.1 (192.168.15.1)
Transmission Control Protocol, Src Port: https (443), Dst Port: 30176
(30176), Seq: 3230, Ack: 309, Len: 53
    Source port: https (443)
    Destination port: 30176 (30176)
    Sequence number: 3230    (relative sequence number)
    [Next sequence number: 3283    (relative sequence number)]
    Acknowledgement number: 309    (relative ack number)
    Header length: 20 bytes
    Flags: 0x18 (PSH, ACK)
        0... .... = Congestion Window Reduced (CWR): Not set
        .0.. .... = ECN-Echo: Not set
        ..0. .... = Urgent: Not set
        ...1 .... = Acknowledgment: Set
        .... 1... = Push: Set
        .... .0.. = Reset: Not set
        .... ..0. = Syn: Not set
        .... ...0 = Fin: Not set
    Window size: 5840
    Checksum: 0x80bd [correct]
        [Good Checksum: True]
        [Bad Checksum: False]
Secure Socket Layer
    TLSv1 Record Layer: Handshake Protocol: Encrypted Handshake Message
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 48
        Handshake Protocol: Encrypted Handshake Message

-----Original Message-----
From: wireshark-users-bounces@xxxxxxxxxxxxx
[mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Sake Blok
Sent: Wednesday, May 28, 2008 1:08 PM
To: Community support list for Wireshark
Subject: Re: [Wireshark-users] tshark SSL Decryption

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
_______________________________________________
Wireshark-users mailing list
Wireshark-users@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-users