Thanks for following up and apologies this didn't get a public response.
I'm glad R&D reached out to you on the backend.
What I can do is provide a little more color on the situation.
Hosting companies have using one server and one IP address to host many different websites or properties for a couple of decades now.
The way the server differentiates between the various properties is the HTTP Host header.
Based on this value, the server will serve up the appropriate content.
Obviously, this creates a problem when you add HTTPS to the mix when you need to validate the site you are connecting to before you pass any real data (including an HTTP Header).
Up until fairly recently, you had to dedicate an IP address to each property as you can use a single certificate per reachable IP address.
This became problematic to implement as the supply of IPv4 addresses exhausted.
An SSL/TLS certificate has a fairly flexible structure that's easy to extend.
One of the ways it was extended was the SubjectAltName field.
This essentially is a way of saying "this certificate is also valid for these sites" (whereas the DN field is the primary identity).
Many sites (including Google) do this, including this very community site.
The problem is: the certificate alone doesn't tell you which property you're actually accessing.
Which is kind of important for the webserver to know so the correct configuration and document root is applied to the connection.
An extension to the TLS protocol called SNI (Server Name Indication) tries to solve that.
The client signals as part of the TLS negotiation what site it is trying to access.
The problem with SNI is that it's sent in the clear, making it trivial to spoof.
This makes SNI not really a good candidate to make security decisions based off of.
This is why, on Check Point Security Gateways, for some applications and sites to be properly detected, HTTPS Inspection must be enabled.
R&D is working on addressing this limitation, as you noted above.
