TLS Inspection & Google Passkeys

Hi Josh Wing ,

Thank you for reaching out to the community, under the web > exceptions add the following:

^([A-Za-z0-9.-]*\.)?accounts\.google\.com/

^([A-Za-z0-9.-]*\.)?apis\.google\.com/

^([A-Za-z0-9.-]*\.)?*\.client-channel\.google\.com/

^([A-Za-z0-9.-]*\.)?clients*\.google\.com/

^([A-Za-z0-9.-]*\.)?contacts\.google\.com/

^([A-Za-z0-9.-]*\.)?*\.googleusercontent\.com/

^([A-Za-z0-9.-]*\.)?mail\.google\.com/

^([A-Za-z0-9.-]*\.)?mail-attachment\.google\.com/

^([A-Za-z0-9.-]*\.)?ogs\.google\.com/

^([A-Za-z0-9.-]*\.)?play\.google\.com/

^([A-Za-z0-9.-]*\.)?ssl\.gstatic\.com/

^([A-Za-z0-9.-]*\.)?www\.google\.com/

^([A-Za-z0-9.-]*\.)?www\.gstatic\.com/

Thanks Vivek. I tries entering the list and the following two entries were rejected,

^([A-Za-z0-9.-]*\.)?*\.client-channel\.google\.com/
^([A-Za-z0-9.-]*\.)?*\.googleusercontent\.com/

When i try to use the passkey I still get the message below.

Hi,

are you using IPv6 in your firewall? I had to create a special IPv6 rule with a local IP host definition because the current version of XG does not allow the use of IPv6 FQDNs in firewall rules.

Ian

Hi Ian,

IPv6 is enabled on the router, firewall and workstation, but not used. The active connection is Sophos are not showing any active IPv6 sessions.

Just to clarify, did you have to create an entry for your workstation? Just curious about what the rule was you had to make.

TIA 

I had to make a specific gmail rule for IPv6 traffic. IP4 traffic was handled by the existing mail rule.

I had to use the IPv6 address of google and create my own IP address group because the current versions of XG v20 and v21 do not support IPv6 FQDNs. The rule only allows smtps.

Ian

That's helpful and sent me down the right path. I created an IPV6 rule for LAN to WAN, with the "Destination networks" being the predefined "Google app enforcement" group. The "Security features" are,

• Block QUIC protocol
• Scan HTTP and decrypted HTTPS
• Use zero-day protection
• Use web proxy instead of DPI engine

If Decrypt HTTPS during web proxy filtering is enables then the passkey auth fails. 

The description on the group is, "Google app domain enforcement requires use of the web proxy. Use this FQDN group in a firewall rule to ensure that all affected traffic is handled by the proxy." However, the selected hosts are google.com and *.google.com. If I understand the settings above, that will leave a whole heap of traffic uninspected. 

The general rule is allowing GMail using inspection. The next question is how to tighten the destination network from "Google app enforcement" to just the destinations needed  for passkey auth. I can't work that out from the Google documentation. Does anyone have any references?  

That's helpful and sent me down the right path. I created an IPV6 rule for LAN to WAN, with the "Destination networks" being the predefined "Google app enforcement" group. The "Security features" are,

• Block QUIC protocol
• Scan HTTP and decrypted HTTPS
• Use zero-day protection
• Use web proxy instead of DPI engine

If Decrypt HTTPS during web proxy filtering is enables then the passkey auth fails. 

The description on the group is, "Google app domain enforcement requires use of the web proxy. Use this FQDN group in a firewall rule to ensure that all affected traffic is handled by the proxy." However, the selected hosts are google.com and *.google.com. If I understand the settings above, that will leave a whole heap of traffic uninspected. 

The general rule is allowing GMail using inspection. The next question is how to tighten the destination network from "Google app enforcement" to just the destinations needed  for passkey auth. I can't work that out from the Google documentation. Does anyone have any references?  

Form what I can see the pass key is an encryption method not an application, so you will never see the pass key because it sets up secure communication with google by encrypted handshakes.

Can you watch the Log Viewer Web Filter and SSL/TLS Inspection?

Note: Any TLS Traffic that does not match any SSL/TLS Rule will not be decrypted but will also not be logged in the Log Viewer.  If you want all undecrypted traffic to be logged you need to create a bottom rule that is Not Decrypted but with logging on.

You can try both with the TLS decrypted and not.  It should lead you to what specific domains it is having problems with.  One suggestion I have is before you decide to let it through undecrypted you may want to try a Web Exception that turns off A/V and policy.  Sometimes it is not having problem because you are decrypting HTTPS, it is because you are not A/V scanning that traffic.  For example the A/V scanning could be complaining that a specific download is unscannable and your action on malware scan failure is block.