Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

TLS Inspection & Google Passkeys

I have TLS inspection setup on my main network running through a Sophos XG (20.0.2 MR-2) and am trying to setup Google Passkeys for G-Mail. 

The passkeys were setup using a different network connection, and they do work on another network. If I go through the G-Mail logon process it gets to the point of displaying the QR code which I scan on a mobile phone, at which point the browser give a "Something went wrong" error and G-Mail asks if I want to try again. 

If I turn TLS inspection off the logon process works using passkeys.

To get Passkey authentication working I suspect that I need to exclude one of the Google URLs from TLS inspection, but don't know which one. I don't want to exclude all Google services, including Gmail itself, from TLS - just the Passkey authentication process.

Has anyone got this working with TLS enabled?



Added TAGs
[edited by: Raphael Alganes at 9:52 AM (GMT -7) on 16 Oct 2024]
Parents Reply Children
  • 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

    XG115W - v20.0.2 MR-2 - Home

    XG on VM 8 - v21 GA

    If a post solves your question please use the 'Verify Answer' button.

  • 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.

    XG115W - v20.0.2 MR-2 - Home

    XG on VM 8 - v21 GA

    If a post solves your question please use the 'Verify Answer' button.

  • 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.