How to extract certificate from SSL session setup trace

asked 2019-10-09 10:19:19 +0000

MWRMWR
3 ●1 ●3 ●2

Hi, I have been working with Wireshark for years particularly as I use the Riverbed trace analysis programs daily. I found ways on the Internet to extract certificates from an SSL session trace. All the info I found seems to speak about fields I don't find in my version of WS (I tried 2.4.0 and 2.6.3. Expanding the SSL details on my trace shows:

Frame 3871: 1402 bytes on wire (11216 bits), 256 bytes captured (2048 bits)
Ethernet II, Src: Cisco_f3:00:11 (d4:2c:44:f3:00:11), Dst: HewlettP_6f:21:d0 (f4:39:09:6f:21:d0)
Internet Protocol Version 4, Src: xxx.xxx.xxx.xxx, Dst: xxx.xxx.xxx.xxx
Transmission Control Protocol, Src Port: 8080, Dst Port: 57248, Seq: 40, Ack: 752, Len: 1348
Hypertext Transfer Protocol 
Secure Sockets Layer
 TLSv1.3 Record Layer: Handshake Protocol: Server Hello
    Content Type: Handshake (22)
    Version: TLS 1.2 (0x0303)
    Length: 122
    Handshake Protocol: Server Hello
        Handshake Type: Server Hello (2)
        Length: 118
        Version: TLS 1.2 (0x0303)
        Random: 679cb032893ff093df50b2aad0ef633b8e1923abb79837f8...
        Session ID Length: 32
        Session ID: f8046d1805478fa3cc6658da57be9a03ba6807a79094af06...
        Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
        Compression Method: null (0)
        Extensions Length: 46
        Extension: key_share (len=36)
        Extension: supported_versions (len=2)
 TLSv1.3 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec
    Content Type: Change Cipher Spec (20)
    Version: TLS 1.2 (0x0303)
    Length: 1
    Change Cipher Spec Message

I understand I should find the certificate line and click right to export, but there is no certificate line. What am I doing wrong or not seeing?

Thanks

Marc

edit retag flag offensive close merge delete

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2019-10-09 11:27:05 +0000

grahamb

flag of United Kingdom of Great Britain and Northern Ireland

23835 ●4 ●976 ●227 https://www.wireshark.org

You're looking at the wrong TLS record.

You need to look at the TLS handshake record that sends the server certificate. Use the display filter tls.handshake.type == 11 to find certificate records.

Note that 3.0.5 is the current stable release version of Wireshark.

edit flag offensive delete link

Comments

Hello grahamb

I agree that I had to update my version of WS to have a tls.xxx filter capability, but even then tls.handshake.type appears to have a value of 0 through 8 for me. Can"t upload pic, but value choice is:

Error
Client Hello
Client Master Key
Client finished
Server Hello
Server Verify
Server finished
Request Certificate
Client Certificate

Sorry and thanks again. Marc

MWRMWR ( 2019-10-09 13:30:02 +0000 )edit

Hi again, After checking again, could I have a different formatting/interpretation because I am tracing the client TO PROXY connection (on port 8080) not the Proxy to actual server (on port 443) connection?

MWRMWR ( 2019-10-09 13:38:12 +0000 )edit

Do you have the TCP preference "Allow subdissectors to reassemble TCP streams" enabled? This is required as a TLS certiificate often extends over multiple TCP segments so must be reassembled.

grahamb ( 2019-10-09 16:07:41 +0000 )edit

Hi Yes this option was required in the post I followed in the first place. It was, as still is checked. Could you please let me know what I would see in the INFO filed of the correct record to work on, or would some handshake message sequence be available somewhere to show it ? Thanks for your time and help

Marc

MWRMWR ( 2019-10-10 07:01:31 +0000 )edit

But I see that the packet I am analysing is maxed out in size and followed by another also maxed and a third half empty, so I think you are right: somehow the PC-to-Proxy message may not be re-assembled (maybe things work slightly different due to using the proxy). I will try tracing on the other side of the proxy to have a proxy-server trace. I'll let you know

MWRMWR ( 2019-10-10 07:06:17 +0000 )edit

add a comment

answered 2019-10-09 18:44:39 +0000

SYN-bit

18528 ●9 ●343 ●255 https://SYN-b.it

In your example, the ChangeCipherSpec comes straight after the ServerHello. This means this is a resumed session (either cached on both client and server or there was a TLS ticket). In resumed sessions the authentication of the server certificate (and in case of mutual TLS, also the client certificate) has already taken place so the cetificate(s) will not be exchanged.

If this is a test with a browser, make sure you start your capture before you open your browser (and close all open browser windows before you start).

edit flag offensive delete link

Comments

The wireshark trace I was using was not recording the entire length of each packet, so Wireshark was not interpreting the packet correctly and displaying 'Packet size limited during capture') I had not identified the error because the 'Server Hello' packet does not mention 'limited' The correct packet containing the certificates is, apparently the second one just after the one marked 'Server Hello' and, when interpreted correctly by WS, is marked 'Certificate' and has a Tls.handshake.type of 11, as grahamb pointed out. Thanks for your help

Marc

MWRMWR ( 2019-10-10 08:45:09 +0000 )edit

@SYN-bit, I think your answer was intended for another TLS question, maybe this one?

grahamb ( 2019-10-10 09:44:46 +0000 )edit

@grahamb No, it was indeed a response to this question. However, I did not look close enough. In a TLSv1.2 handshake my answer made sense, I did not notice that this is a TLSv1.3 handshake where things are different :-)

SYN-bit ( 2019-10-10 16:24:10 +0000 )edit

@SYN-bit, ACK, I was looking at this question.

grahamb ( 2019-10-10 17:15:44 +0000 )edit

add a comment