• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

URL Filtering for HTTPS connections

mekinney

n00b
Joined
Jan 21, 2011
Messages
13
My current router, an Actiontec MI-424 supplied by Verizon FIOS, supports URL filtering however it only works over HTTP connections. Does anyone know of a router that supports URL filtering over HTTPS connections also? Ideally it would be a gigabit router with wireless also.

Thanks,
Mike
 
Easiest method would be to use a DNS based filtering, like OpenDNS or similar.

Very easy to bypass though unless you lockdown inbound port 53. ...or if you know the IPs...
 
Thanks. I want to block all google searches, but if I block google with OpenDNS, then gmail stops working also. I haven't found an answer to that on OpenDNS.

I can use URL filtering to block it, however, Google allows HTTPS searches that effectively bypass the URL filtering on my current router. Maybe it's not technically possible to do URL filtering with HTTPS. I'm not sure.
 
Fortinet will do url screening over https as will most real UTM firewalls these days.
 
Apparently giving an example completely derailed this thread.

Thanks Nicklebon, I'll check in to Fortinet.

Does anyone know if the major modern routers support HTTPS URL filtering? The ASUS manual online is very vague.
 
There are (IMO) bad security and privacy implications to using a MITM (proxy) UTM to break/recreate the SSL. You had better be DAMN certain that the UTM device is secure because it can easily snoop all traffic that was supposed to be (and would probably have been) securely transmitted. That said, it's the best way to do it if you insist.

I personally take pride when my users switch to using SSL-heavy browsing habits.

For those that might pooh-pooh me; a lot of SonicWall devices offer this and it was but two months ago one of their default/un(user)removable "remote support" root accounts was compromised... Who knows how long that was a 0-day that someone was using to spy via their devices.
 
There are (IMO) bad security and privacy implications to using a MITM (proxy) UTM to break/recreate the SSL. You had better be DAMN certain that the UTM device is secure because it can easily snoop all traffic that was supposed to be (and would probably have been) securely transmitted. That said, it's the best way to do it if you insist.

I personally take pride when my users switch to using SSL-heavy browsing habits.

For those that might pooh-pooh me; a lot of SonicWall devices offer this and it was but two months ago one of their default/un(user)removable "remote support" root accounts was compromised... Who knows how long that was a 0-day that someone was using to spy via their devices.

Agreed with this. My org has tested SSL interception many, many times and it seems to break web and some desktop apps.
 
Filtering != interception though.

Correct me if i'm wrong, but you still need to break (MITM) the SSL connection in order to see and therefore filter on the URL. The problem we saw was with applications that use hard-coded certs not accepting the proxy server's certificate. Granted, we didn't try very hard.
 
Devices should still be able to block via DNS lookup (or snooping) on traffic heading to 443. Though I guess this isn't being implemented widely.
 
You have to filter based on destination IP not URL. HTTPS encrypts the URL too so either you have to be able to do HTTPS inspection (i.e. load a root cert on your firewall and all your PCs and mobile devices and everything opens a HTTPS connection to your firewall and the firewall opens another to the real host so it can inspect the HTTPS traffic, but as some have mentioned this never works well since some devices it's difficult to impossible to add a root cert or they expect a particular cert on the other end and will refuse to work with the HTTPS inspection), or just block the entire IP for the root domain from the URL you want to block.
 
Back
Top