Boring about the work of decoding ngfw

If you want to completely spoil the first date - talk to the girl about decoding. Yes, and in the case of the subsequent - is also not worth it.

Our meeting with you is not the first , so this text will again deal with decoding.
Yes, I will talk again about SSL. I can gladden myself and you with the fact that this is the second and last material on this topic. Maybe.

Last time, we figured out why you might need to decrypt the long-suffering SSL.
In this material we will analyze exactly how decryption works with certificate substitution.
')
What do we need for this?

First, let's remember how SSL works. I will briefly describe the main points.

After establishing a TCP session between the client and the server, SSL Handshake occurs. Within it, both parties exchange messages Client Hello and Server Hello.


SSL connection establishment dump from vk.com

Client Hello describes the supported encryption parameters, Server Hello contains the parameters selected from the options offered by the client. Client Hello and Server Hello can be used as an indicator for establishing an SSL session. When these messages appear, the device (vFTD in our case) scans the configured decryption policies for a decision on whether to further decrypt the session or not.

If the configured policies dictate the decryption of traffic, the device becomes man-in-the-middle (MITM) and decrypts the transmitted data. With the successful launch of MITM, we have two established SSL sessions.

The first is between the client and the descrambler (vFTD). The second is between the descrambler and the server. Encrypted data comes from the client to vFTD.
Deciphered. They are checked by various policies (access, IPS, file, AMP, etc.). If the decrypted data from the client is checked, it is encrypted again and sent to the server. If they do not pass any test, the data is either simply blocked (not sent to the server), or the session is reset. Server responses are handled similarly.

For a device to become a MITM in an SSL session, it takes a little. At the SSL handshake stage, in addition to authentication and other actions, a shared session key is formed. It is with its help that the transmitted data will be encrypted. For this, a symmetric algorithm will be used.

There are two of the most common ways to form a common session key over open communication channels on the Internet: RSA and ECDH (Diffie-Hellman). The process of generating session keys is shown in the diagrams below (taken from the material “ Analysis of SSL / TLS traffic in Wireshark ”):


Formation of a session key when using RSA

In the case of RSA, the client generates a pre-master secret. Encrypts it with the public key from the server certificate and sends it. You can decrypt the pre-secret only with the private key, which is known only to the server.

Now both sides have a preliminary secret. They form the main secret and further the common session key.


Session key generation using ECDH

In the case of ECDH, the SSL certificate key pair is not used for encryption at all. The client and the server form Diffie-Hellman random key pairs - open and closed. Each party transmits its public key to the other party in an unencrypted form.

Further, using the Diffie-Hellman algorithm, the client and server compute a shared pre-secret from their own secret key and someone else’s public secret. After that, each party generates a shared master secret and session key.

When using ECDH, you must preserve the integrity of the Diffie-Hellman transmitted public keys. The server signs its own Diffie-Hellman public key using its private certificate key. The client can verify the authenticity of the received Diffie-Hellman public key using the public key of the server certificate.

Thus, in order to organize a MITM for an SSL session, in most cases it will be sufficient to replace the server certificate with your own. If the substitution is successful, it will be possible to get a shared session key with the client and be able to decrypt the data.

In the case of RSA, the MITM device will be able to decrypt the pre-secret using the certificate’s own private key. If ECDH is used, the device will be able to sign its Diffie-Hellman public key in such a way that the signature is considered valid on the client’s side.

In order to replace the server certificate with your own (for which we will know the private key), we need our own certificate to ensure correct server authentication on the client side. Simply put - it is necessary that the client browser does not issue any warnings or locks when replacing the certificate. For this, in most cases it is necessary that:

1. The subject field of the certificate contained the Common Name parameter with a value equal to that entered in the address bar of the browser;
2. The certificate was signed by a trusted certificate authority.

Of course, in order for a certificate to be considered valid on the client’s side, other conditions must be met: it should not be revoked, expired, etc. But all these conditions are taken into account at the stage of signing the certificate by its own certification authority.


When using Certificate pinning, a service certificate must be signed by a strictly defined certificate authority. If this is not the case, access to the resource is blocked even if the certificate is signed by a trusted authority.

Accordingly, for resources with certificate pinning, decryption with certificate spoofing will not work.

Thus, in order to organize MITM in an SSL session, the device must generate a new certificate with the same fields as the certificate of the remote server. At the same time, we will have a known private key. A new certificate must be signed using a trusted certificate authority.

In practice, this is implemented as follows:

A company must have its own certification center, the root certificate of which is placed into trusted companies on all devices. This is a necessary condition.

The certificate authority requests a new certificate using the “Subordinate certificate authority, hereafter SubCA) pattern. The peculiarity of this certificate is that using its private key, you can sign other certificates (the CA flag is set in the “certificate main limitations” extension).

Since SubCA is signed by a trusted root certificate, client machines will trust both themselves and any certificate signed with it. SubCA and its corresponding private key is installed on the device, which is supposed to be the MITM in an SSL session. Thanks to this, every time a client attempts to establish an SSL session with an HTTPS server, our device will be able to:

1. Intercept the server certificate;
2. Create a private key;
3. Generate a new certificate with the same fields as the replaced one;
4. Sign the generated certificate using SubCA.

If everything is configured correctly, the user browser will not issue any warnings when opening https pages. The user will be able to determine whether the certificate has been changed, only if it gets into the settings.


Certificate Chain in Mozilla

If you look at the fields of the final certificate, you will see that the subject field contains the correct Common Name value.


Common Name field

If we compare the real and spoofed certificates, we see that they actually differ in the values ​​of public keys and digital signatures (in this case, I neglect the serial number, etc.).



The last thing I wanted to point out is that vFTD uses the same key pair to generate any certificate that has been replaced. What is actually logical: why waste resources already loaded with encryption / decryption of the device to generate new key pairs. If you open the page ya.ru and view the received certificate, we see that the public key will be the same as that of the replaced certificate for vk.com.


Replaced and real certificate

This concludes the description of the SSL decryption mechanism on the NGFW. Greetings to everyone awake, we finally did it! It was painful, but now you know a little more about SSL. Whether it was worth it or not is at your discretion.

PS: And yes, I convey greetings from my colleagues (and join): Happy New Year, everyone! May the new year have less bugs, crutches and dances with a tambourine!



PPS: For those who are interested in how this kitchen is tuned to FirePOWER - velkam in the tackle.