Let’s look at the whole handshake over SSL / TLS:
version: the best protocol version supported by the client
Random: The 32-byte, 28-byte random number, 4 bytes of additional information, the influence by the client clock (to avoid browser fingerprint, 4 byte clocks will now generally do twist)
Session ID: 32 bytes of random numbers, and the server for the reconstruction of the session, a new session is open, which means
cipher suit: client supports all cipher suites, in order of priority
Compression: Compression algorithms supported by the client, the default uncompressed
Extensions: composed of any number of extensions, carry additional data
Select the parameters provided by the client feedback client
Server does not support the best version supported by the client, if the server does not support the client version, other versions may be provided to the client we can look forward to receiving
X.509 server certificate chain for carrying
Transmitting a primary certificate must first intermediate certificate in the right order follows the primary certificate
Must ensure that the same server certificate transmitted and the selected algorithm suite
When the optional Certificate message
Algorithm: verrify_data = PRF (master_secret, finished_label, hash (handshake_message))
ServerKeyExchange: carry extra data key exchange, depending on the cipher suite
ServerHelloDone: server has all the expected handshake message has been sent
ClientkeyExchange: The client carries the information provided by key exchange
ChangeCipherSpec: sending end has acquired sufficient information for the connection parameters
To decrypt HTTPS traffic, you require an encryption key, an encryption key is generated by the master key, the client nonce, the server random number. From the above handshake, the client and the server random number in the random number transmitted in both the handshake message, the master key (the master_secret) by the pre-master key (pre_master_secret) binding two random number generator. Pre-master key exchange (DH, RSA) algorithm exchange key cipher suites.
Thus, by decrypting the HTTPS Wireshark, you may start from two places: 1, the RSA key exchange algorithm selection, and then extract the private key of the server, the private key Wireshark introduced through a pre-master key delivery Wireshark decryption key exchange process , client and server random number generation master key before recombination, further generates the encryption key, to decrypt the encrypted subsequent fetch packets. 2, the client directly extracted from pre-master key, the encryption key generating server and the client in conjunction with a random number, decrypting the encrypted achieved packets.
The following shows two ways to decrypt HTTPS traffic.
P12 format export certificate with the private key from the server, or directly export the private key of the server.
Capture a complete message from the beginning of TCP three-way handshake:
At this point you can see the message is encrypted TLS, you can not see the specific content of the message.
Click Edit -> Preferences -> Protocols -> SSL (some versions only TLS), import the RSA key:
Since the key exchange by DH method is not transmitted in the middle, so this method can only be decrypted by the RSA key exchange.
Import a server certificate:
After clicking ok, Wireshark will capture packets decryption:
Message is successfully decrypted, you can visually see the HTTP request and response packets.
By setting environment variables taken pre_master_secret browser, thus achieving the purpose of decrypting HTTPS.
New environment variables User variables SSLKEYLOGFILE = path \ sslkey.log file, and then after wireshark in the development of the ssl configuration file location.
Click Edit> Preferences> protocol> ssl:
To decrypt browser traffic: