Boring about decoding

No, have you ever seen funny SSL text?



Me not. But we still have to suffer. You could browse through this material and read something more interesting and intriguing. But if you need to figure out how and why it works, then I advise you to stock up on something invigorating. For further the unprepared person risks falling asleep.



Of course, I will take responsibility and wake you up from time to time. However, I advise you to pour yourself a cup of strong coffee and get comfortable. We need to talk about many things:

NGFW decryption is a delicate matter.

')

In the comments on the material on ISE + FirePOWER a controversy broke out on the subject of decryption. I decided to look into this fascinating subject in more detail.



All the NGFW, UTM and Web proxy solutions I know to decrypt https use certificate spoofing. I will operate on the example of Cisco virtual FirePOWER Thread Defense (hereinafter referred to as vFTD) managed by Cisco FirePOWER Management Center virtual (hereinafter referred to as FMC).



My colleague once described this solution in detail here . The principles mentioned apply to most such solutions.



Is decryption necessary or not?



Filtering by URL categories, site reputations, and Internet applications is the classic NGFW functionality.



To understand which site a client accesses it is not necessary to decrypt all traffic. The decoding functionality, as such, is only needed for certain actions: traffic analysis, file transfer control, and monitoring. In the case of filtering Internet access by https, decryption is not needed, even if it is not obvious.



This is how URL category blocking works:



Create an access policy on the FMC, which will block access to social. networks.







We try access in the usual http. From soc. We will use the old www.hi5.com .







Access Denied, the policy works. We look at the FMC in Analysis -> Connections -> Events. Here are our blocked requests:







Shift the table to the right to view the URL:







We look in Wireshark with a filter by IP-address 67.221.174.31:







We see: TCP handshake passes, then the client sends an HTTP Get with the URI "http://hi5.com". On HTTP Get, he immediately gets a 403 Forbidden response. Here is the content:







It can be seen that this is the very End User Notification (hereinafter EUN), which we see in the browser. EUN sends vFTD in response to an attempt to go to a prohibited resource. Moreover, EUN is sent from IP-address 67.221.174.31. That is, in fact, vFTD is wedged into the TCP session between the client and the server and puts its response.



Ok, with clear http everything is clear. Now we try to go to https-site, for example, vk.com. VFTD decryption is not enabled. Can we block?







Oh, again Access Denied. on FMC in Analysis -> Connections -> Events. Here are our blocked requests:







Move right:







We see that vk.com was not a good example. It turns out that initially the session is established via http (tcp port 80, seen in the second column of the last page). Therefore, blocking occurs in the same scenario as in the first case.





If you have not yet fallen asleep - try facebook.com:







Access is blocked, but EUN is not displayed. Let's look at FMC:











Let's look at Wireshark:







We see that, unlike vk, facebook immediately establishes a session on port 443.





By a traffic dump in Wireshark, we see that vFTD blocks the session to facebook after each SSL Client hello message. Accordingly, Client hello contains enough information to recognize the URL and make a decision about blocking. Consider Client hello more closely:







Indeed, the Server Name Indication extension field contains information on which the requested resource can be identified.



As for EUN, FirePOWER has some limitations when displaying blocking notifications to users. For un-decrypted traffic, EUN will not be displayed.



This is logical, because FirePOWER encloses the EUN page in the established session (if it is not decrypted, it cannot be done).



Internet application blocking:



Maybe you should pour yourself some coffee again. It remains a bit, but better to be safe.

The last thing I decided to check is whether filtering of Internet applications inside https will work. In particular, componentwise.



Create a policy that will block Google Drive, Google Maps and Google Play:







Check - selected applications successfully blocked. We look at FMC:











In Wireshark, you can see that applications are blocked by the same scenario as Facebook, that is, after each SSL Client Hello:













Thus, decryption is needed so that the notification of users about blocking works. Although only for this, I would not cook all this compote.



IPS signatures and file policies, including Advanced Malware Protection (AMP), do not work for encrypted traffic. And this is logical: to search for malware, traffic must be decrypted. Here it should be understood that a deep inspection will not work for payload. For the information that is transmitted in open form (IP headers, TCP headers, SSL Handshake messages) signatures will work.



From the point of view of IPS, the protection of incoming traffic is more interesting. If we publish a Web server to the Internet and want to protect it with IPS, then SSL sessions will be initiated outside. It does not make sense to decrypt them with certificate substitution: why change one own certificate to another?



For such a task on FirePOWER, decryption with the private key is provided. That is, the certificate of the published server and the corresponding private key are preloaded on FirePOWER. It will be used to decrypt a session running outside. This option in the framework of this material will not be considered.



The last use of decryption is traffic monitoring.



As a result, which may require decryption of traffic on FirePOWER:

1. EUN mapping for blocked sites and web applications;
2. Traffic analysis with IPS signatures;
3. Control of file transfer, including the analysis of files by the AMP system;
4. Recognition of some applications;
5. Monitoring

I think it’s clear now why decrypt SSL to NGFW (as well as UTM, Web proxy) in principle. In this case, I sorted out the subject using the example of FirePOWER. However, I am sure that on other solutions the situation will be similar. If this is not quite the case - write.



The following material will tell you how it is decryption works with the substitution of the certificate on the NGFW. Stay tuned.