How to hide confidential information from strangers?

The simplest is to encrypt.

On the Internet and Intranet networks, data encryption is controlled by SSL / TLS.

The soldier is sleeping, the service is on.

However, sometimes there is a need to do the opposite - to decipher the intercepted traffic.

This may be required both for debugging applications and for checking suspicious network activity.

Or to study the operation of SSL / TLS (obvious, malicious goals are not discussed).



How and under what conditions can I decrypt a dump of SSL / TLS traffic in Wireshark?

Let's try to figure it out.





')

Deal with the decryption will be much easier if you have a general understanding of the principles of the SSL / TLS protocol. Consider a simplified version of the functioning of SSL / TLS, highlighting in it only the most important points for us.



Usually the beginning of the exchange of encrypted data, in SSL / TLS is preceded by the process of establishing a connection, a handshake (SSL handshake).

on Habré there is an article detailing the process of setting up an SSL / TLS connection ( The first few milliseconds of an HTTPS connection ) thevar1able

At this stage, in addition to authentication and other actions, the two parties (applications) agree on a common session key ( symmetric ). After negotiation, the key is used by applications to encrypt and decrypt the data transmitted between them.



However, how do the parties agree on the same session key when communicating over unprotected communication channels?

There are various algorithms for this. The most commonly used on the Internet are RSA (most popular) and ephemeral Diffie-Hellman (DHE / ECDHE).

At the time of the SSL / TLS connection, the session key negotiation algorithm is selected by the server.

The choice comes from the list of algorithms supported by the client, which it sends to the server.

The diagram below shows the process of negotiating session keys in RSA and DHE / ECDHE cases, as well as information that the Sniffer (Wireshark) sees in the traffic intercepted by SSL / TLS.







In the first case (RSA key negotiation), at the time the connection is established, the client generates a random number, a pre-master secret. Encrypts it with the public key obtained in the certificate from the server.

Sends encrypted to the server. The server decrypts the pre-secret with its secret key. Then both parties, possessing the same preliminary secret, convert it into the main one and create a common session key from it.

In asymmetric encryption algorithms (RSA), data encrypted with a public key can only be decrypted with a secret. At the same time, the public and private keys must be interconnected in a certain mathematical way, they are a key pair.

In the second case (reconciliation of keys DHE / ECDHE), everything works a little differently.

When a new connection is established, the client and server generate a pair of random ephemeral (temporary) Diffie-Hellman keys.

The pair consists of public and private keys. The parties exchange public keys.

Next, the client and server, using their private and received public keys, create a pre-secret, a master secret and a shared session key.

In this algorithm, the permanent server secret key (RSA / DSA / ECDSA) does not participate in encryption and is used only for signing public DH keys. The description is very general, there is detailed information in the article on Habré ( How HTTPS ensures connection security: what every web developer should know ) zavg .

Now it may have become a little clearer.



If the client and the server use RSA algorithm when negotiating session keys, then the traffic intercepted between them can always be decrypted with the server's secret key.

The fact is that at the time of the SSL / TLS connection the client sends the encrypted value of the pre-secret to the server.

The pre-secret is decrypted by the server's secret key, then the session key is calculated.

The data is decrypted by the received session key.



In the case of using the DHE / ECDHE algorithm and possessing the server's secret key, it will no longer be possible to decrypt the SSL / TLS traffic data.

At the time of establishing the connection, only the public values ​​of the DH keys are transmitted.

The secret DH keys needed to compute the session keys are stored in the client and server’s RAM and are destroyed after the connection is completed.

Diffie-Hellman's ephemeral key agreement algorithms (DHE / ECDHE) support Perfect Forward Secrecy (PFS).

There is of course another alternative.

Suitable for decrypting SSL / TLS-traffic without a private server key, as well as using algorithms DHE / ECDHE, RSA and others.

At the time of the SSL / TLS connection, the open values ​​of secrets, prior and main secrets are present in the RAM of the client and server.

If you have time to extract secrets from memory and save to disk, then in the future they can also be used to decrypt data.

Of course, this is not always easy to do and does not allow decrypting traffic that has ever been intercepted.



Now let's see how, in practice, if you have a server secret key or session secret values, you can decrypt SSL / TLS traffic in Wireshark.

Wireshark + server secret key

Actually, everything is relatively simple.

We load a dump of client / server SSL traffic into Wireshark, connect the server's private key and decrypt it.



Of course, it is worth checking first that the client and server used the RSA algorithm to negotiate session keys.

To do this, we find the initialization of an SSL / TLS connection (filter "ssl.handshake").

Check that the server in the Server Hello message in the Cipher Suite specifies the RSA algorithm.







The Client Key Exchange contains an encrypted value for the session's secret secret (Encrypted PreMaster).







Perform Wireshark settings.

In the Edit -> Preferences menu on the left, open the branch with the list of protocols (Protocols) and select SSL.

We check the setting of the “Reassemble SSL records spanning multiple TCP segments” flag.

In the field “SSL debug file” we indicate the path to the log with debug information (the results of the decryption are recorded, it can be useful when analyzing problems that have arisen).

In the “RSA keys list” field, click the Edit button.







In the window that appears, click the New button and fill in the fields:



• IP Address - the IP address of the SSL server in IPv4 or IPv6 format

• Port — the SSL server port number (for https, usually 443)

• Protocol - the name of the protocol that uses SSL encryption (for example, http). If not known, specify data

• Key File - path to the server's secret key file ( PEM or PKCS # 12 format file)

• Password - filled in only if the secret key is PKCS # 12 and is password protected.







Confirm the settings and enjoy viewing the decrypted traffic.



For convenience, we only output the application-level traffic through the filter, for example, http.

Also, open information is available on the “Decrypted SSL Data” tab at the bottom of the window.







Or choose any package from the SSL / TLS session, right-click, then “Follow SSL Stream” in the list.

We receive a stream of decrypted data from the selected connection.

Wireshark + session secrets

In addition to the server's secret key, known values ​​of session secrets can be used to decrypt data in Wireshark.

A good opportunity for those who do not have a private server key or if the server chooses a PFS-enabled session key negotiation algorithm (DHE / ECDHE).



Where and how can I get the secrets of the sessions?

1. Wireshark supports the export of pre-secrets from a loaded dump of SSL / TLS traffic.
   
   

   Wireshark, Files menu -> Export SSL Session Keys

   
   
   Of course, before this traffic must be decrypted with the server's secret key.
   
   
   
   Very important functionality.
   
   The fact is that Wireshark does not know how to save traffic in decrypted form.
   
   Sometimes there is a need to transfer decrypted traffic to someone else, without compromising the secret key of the server.
   
   To solve this problem, you can, as usual, decrypt the traffic with the server's secret key and export all the secrets of the SSL / TLS sessions from it to a separate file.
   
   After this, it becomes possible to re-decrypt the traffic using only a file with secrets.
   
   
   
   
2. In some applications, there is a built-in functionality that allows you to save secrets to disk.
   
   

   A striking example of such applications is the Chrome and FireFox browsers.
   
   Both in their work use the NSS cryptographic module, allowing logging secrets to a file.
   
   The format of the log is shown below and corresponds to the first two options.
   
   A more detailed description of the functionality is in the article on Habré ( How to easily decrypt TLS traffic from the browser in Wireshark ) ValdikSS .
   
   
   
   In Java programs, secrets can be obtained from SSL debug log ( TLS decryption of Java application traffic using logs ) Toparvion .
   
   Or immediately in the Wireshark format via jSSLKeyLog ( java java log files)

   
   
   
3. Other options.
   
   

   Using third-party utilities, to intercept the secrets of the sessions in the RAM of the client or server.

   
   
   

And now - how and in what form the secrets are uploaded to Wireshark.

The values ​​of the secrets of the sessions are specified line by line in a plain text file in a specific format.



There are three possible row formats:

1. For SSL / TLS sessions with RSA session key agreement algorithm
   
   
   
   RSA <hex encrypted pre-master secret> <hex pre-master secret>
   
   

   <hex encrypted pre-master secret> - the encrypted value of the preliminary secret of the session (the Encrypted Premaster field in the message ClientKeyExchange)
   
   <hex pre-master secret> - decrypted value of pre-secret

   
   
   
2. For SSL / TLS sessions with DHE / ECDHE session key negotiation algorithm
   
   
   
   CLIENT_RANDOM <hex client_random> <hex master secret>
   
   

   <hex client_random> - random number of the client (Random in the Client Hello message)
   
   <hex master secret> - the value of the master secret of the session

   
   
   
3. Support for master-key output in “openssl s_client”
   
   
   
   RSA Session-ID: <hex session id> Master-Key: <hex master secret>
   
   

   <hex session id> - session ID (Session ID field from Server Hello or Session Ticket from Client Hello)
   
   <hex master secret> - the value of the master secret of the session

   
   
   

And now we connect the file with the secrets in Wireshark and decrypt the SSL / TLS traffic.



Wireshark settings are similar to those in the previous section.

Except that in the SSL settings in the RSA keys list you do not need to specify anything (the SSL server settings and its secret key). Only in the field "(Pre) -Master-Secret log filename" is the path to the file with secrets.







We confirm the settings and look at the decoded traffic.

Conclusion

I hope the information provided will be interesting to everyone.

who plans or is already engaged in the analysis of SSL / TLS-traffic in Wireshark.



All related links:

Wireshark - taming the shark PENTESTIT

What is TLS babayota_kun

The first few milliseconds of thevartable HTTPS connection

How HTTPS Secures Your Connection: What Every Zavg Web Developer Should Know

How to easily decrypt TLS traffic from the browser in Wireshark ValdikSS

TLS decryption of Java application traffic using Toparvion logs

jsslkeyeylog

Public key cryptosystem

RSA

Diffie-Hellman Protocol

Perfect forward secrecy