How to identify the SNI of TLS where the session was resumed?

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.

@Reaper After all this time, it turns out that the following is the cause. PAN-115238 Fixed an issue where SSL renegotiation sessions incorrectly identified URL categories.

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.

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