ssl.handshake.type == 1
ssl.handshake.type == 1 && ip.addr == 35.160.54.177
ssl.handshake.type == 1 && ip.addr == 35.160.54.177 && tcp.port == 443
ssl.handshake.type == 1 && tls.handshake.extensions_server_name contains "mozilla.com"
ssl.handshake.type == 1 && tls.handshake.extensions.supported_version == 0x0304
ssl.handshake.type == 1 && tls.handshake.extensions.supported_version == 0x0303
ssl.handshake.type == 1 && tls.handshake.extensions.supported_version == 0x0302
ssl.handshake.type == 1 && tls.handshake.extensions.supported_version == 0x0301
ssl.handshake.type == 2
Following the conversation
Once you’ve identified the Server Hello packet, it’s time to dig a little deeper.
First, ensure that your Wireshark is set to reassemble out-of-order TCP packets. Without this, it can sometimes be very difficult to complete this next step. You can verify that Wireshark is configured to do this by going to this page in the Wireshark GUI and ensuring that any reassembly related options are ticked.
Wireshark GUI:
1. Edit > Preferences
(A popup window should appear)
2. In the popup window, go to "Protocols" and then "TCP"
3. Ensure TCP reasembly options are enabled
In the packet you’ve selected, identify the Transport Layer Security section and expand the contents. You are looking for a section similar to this:
Note that, depending on the particular Server / CA / Protocol you’re dealing with, the packet capture may contain multiple Certificates. You may also notice that some of the Certificates are bigger than the others. This is because the server has basically sent everything twice.
Now you’ve found the Certificate, you can extract it by right clicking on the Certificate and selecting ‘Export packet bytes…’ and ave the file as a *.cer file.
Once you’ve got the file save, you can then open it in Windows like any normal Certificate.
\