I want to log urls without using TLS decryption. However, Microsoft Yammer and others often use TSL Session resumption. PA does not cache the TLS state by default (?), so it cannot identify the SNI . Do you have any good ideas?
To see this working, head to your live site.
Search
Sep 21, 2020
How to identify the SNI of TLS where the session was resumed?
How to identify the SNI of TLS where the session was resumed?
4 answers6 replies
0
For such cases I would install a MineMeld instance (or any web interface where you can load up lists) and feed an ExternalDynamicList with the individual IP pools for those applications: https://docs.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide and filter based on those destinations, if applications are tricky to catch
Thank you for your answer. I'm not very good at English. Therefore, some sentences may look irreverent. Please don't be offended.
Identifying application traffic for yammer isn't very important to me. Because there is an App-id that identifies yammer. This App-id also works correctly for resumed TLS sessions.
So the point of the question is, "Similar to yammer, what are some good URL-based controls for traffic with frequent TLS session resumptions?"
By the way, Microsoft does not recommend limiting yammer by specifying an IP address range.
As far as the recommendations below are concerned, it seems that yammer is using a server such as akamai and cannot specify the IP address range. If we are familiar with the mechanism of akamai, I think you can limit the scope to some extent. But I'm not very interested in that.
https://techcommunity.microsoft.com/t5/yammer-blog/using-hard-coded-ip-addresses-for-yammer-is-not-recommended/ba-p/276592
Hi Nanashin, your English is perfect please don't worry about that at all. Any misunderstanding is on my part as I failed to properly read and comprehend your question. Allow me to try again:
unless the session remains open (no TCP FIN or RST and no TCP timeout) the TLS state will be forgotten by the firewall when the session is broken down. What I do wonder, as I have not seen this type of TLS behavior 'in the real world" yet, is how the session is continued, is there a new (blank?) TLS handshake to reestablish the session, or is the session continued as if it was never interrupted? Since apparently sessions like this work for Yammer there must be something the firewall is able to identify.
One other option, but this is not reliable, is the app-cache, where the firewall caches app-id's for common and frequent connections. This mechanism will 'predict' which app-id is needed when a connection matching the same 6-tuple as previously seen is received by the firewall. This could assist in catching some continued sessions but may not be 100% reliable (as it is based on caching).
If you are seeing certain applications that are failing due to TLS resumption, the best solution would probably to reach out to TAC to have the app-id modified to account for this behavior. If there's no TLS information in the continued session, the firewall wll not be able to assign a url category.
In this case, it is difficult to tell whether the session is simply a session identified by PA or a session identified by TLS. Therefore, I will call the former a firewall session and the latter a TLS session.
I have confirmed that the behavior in issue is occurring on clients that limit the TLS version to 1.1 or later, but I could not clearly confirmed the action of resuming the TLS session.
However, the situation says that the client is terminating the TCP connection after receiving a "closure alert" from the server and the TCP connection is then re-established and the TLS session is resumed.
This is because the traffic log records two firewall sessions, but the latter firewall session does not record the corresponding url log.
There are several possible reasons why the url log may not be logged. The first is when there is an error in the settings, but it is unlikely because the traffic for which the URL log is recorded hits the same rule. The second is when SNI is omitted for some reason. If SNI is omitted, the common name contained in Server Hello will be recorded instead of SNI. But that's not the case. The third is the case where Client Hallo is omitted. I think this is nothing more than resuming a TLS session, but I think this move has been banned since TLS 1.1.
So it seems that Client Hallo doesn't include SNI and Server Hello doesn't include the certificate, but I can't think of anything other than resuming the TLS session defined in TLS 1.1 and above.
I thought there was some smart solution, such as setting a "no decryption rule" with some options enabled to support features such as being able to monitor the state until the end of the TLS session. But now I think there is a long way to go.
In our region, TAC doesn't give us more information than the official documentation, so it's never helped with support other than a hardware failure that obviously requires box or parts replacement.
If I understand correctly, this only appears to happen in TLS 1.1? You could force the TLS sessions to 1.2 minimum, but unfortunately that option only applies to decrypted sessions... I don't see many alternatives at this time. Maybe you can raise a Feature Request with your local sales team?
As far as I know, the problem occurs with TLS 1.1 "or later"(Occurs when TLS 1.0 or earlier is not allowed). Again, at the moment, by specifying the application, no trouble has occurred. Given this workaround, I suspect PA developers are aware of this issue as well. I think the essential problem is that the PA was not designed with the assumption that TLS session resumption will occur. As a matter of fact, now that TLS 1.0 is still mainstream, I don't think it should be supported because there is a vulnerability in resuming TLS sessions.
Thank you for your time.
I did a little bit of digging and even in TLS1.3 there appears to be a resumption function, so this must be something they're looking into
When I checked the log again today, the log pattern as before was gone (this was first addressed around June). Due to the influence of COVID-19, the use of teams etc. is progressing rapidly, so it may have been an unintended move on the Microsoft side as well....?
If we use session resumption frequently, the load on the server will be reduced and may increase in the future.
Ah interesting, thanks for sharing!!