This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

HTTPS Decrypt and Scan kills Android WiFi

I finally decided to give the "exercise in frustration" that is HTTPS Decrypt and Scan a go at home and I hope to apply it at my family sites.  Desktops (Windows or Linux) are fine but mobile devices (Android is all I've got to work with here) not so much...  After not coming across a solution hunting through the community and Googling around I'm posting this.

The setup: UTM 9.605 acting as the DHCP server for the environment.  Wireless Router (ASUS RT-AC68U) in AP mode.  The same setup exists at my family sites.

The issue: mobile devices connect to my WiFi AP but the connection icon has the "X" on it and I've got no internal or external access on any Android device running Nougat or Pie.  Going back to "URL filtering only" took care of this instantly.  The only post in the community matching my predicament and the closest thing to a solution I found is over in the XG forum but I can't believe this workaround is reasonable.  I did, however, find similar solutions suggested by Barracuda and Fortinet regarding Google and SSL inspection so maybe I am wrong in my belief.

The question: based on that XG user's workaround I'm guessing that the issue is that since the UTM Web Protection Proxy CA hasn't been applied to the devices Android can't phone home to Google in order to validate that the device has a connection?  If so is there any reasonable way to get around this so that the device can connect to the WiFi AP so that the UTM Web Protection Proxy CA can afterwards be installed OR do I have to get the UTM Web Protection Proxy CA on each mobile device to resolve this (and is the same hassle to be had with iOS devices)?



This thread was automatically locked due to age.
Parents
  • Based on this statement from Google and after reading some Untangle, Reddit and OPNsense threads that I apparently couldn't find due to being up for 20 hours yesterday it very much appears that the workaround posted in the XG forum seems like the way to go...

    OPNsense has this in their documentation:

    Will try such and update here.

  • This makes perfect sense.   Normal certificate verification ensures that a certificate was issued by one of the 50 or so root certificates installed on your machine.   And even that check falls apart if the user clicks through the invalid certificate warning.   Google is such a potential target that they do not want to trust all of those certificate authorities to be perfectly behaved.   So their code is checking for a particular certificate rather than merely a valid certificate.   That is what HPKP (which I think stands for Hypertext Protocol Key Pinning) is all about.

    It is really part of the cat-and-mouse game with the bad guys.   You want to do https inspection because you don't trust the servers.   Google is doing HPKP because they don't trust the client device or the devices between themselves and the client device. 

Reply
  • This makes perfect sense.   Normal certificate verification ensures that a certificate was issued by one of the 50 or so root certificates installed on your machine.   And even that check falls apart if the user clicks through the invalid certificate warning.   Google is such a potential target that they do not want to trust all of those certificate authorities to be perfectly behaved.   So their code is checking for a particular certificate rather than merely a valid certificate.   That is what HPKP (which I think stands for Hypertext Protocol Key Pinning) is all about.

    It is really part of the cat-and-mouse game with the bad guys.   You want to do https inspection because you don't trust the servers.   Google is doing HPKP because they don't trust the client device or the devices between themselves and the client device. 

Children
No Data