Handling bad certificates when connecting to public wifi
September 2, 2016 4:19 PM Subscribe
I use HTTPS Everywhere with Firefox on my Android to use HTTPS connections by default. Consequently, whenever I try to connect to public wifi that redirects you to an agreement page my phone flips out and refuses to connect because the certificate is invalid. This can be circumvented with complicated wrangling. (Visiting some non-HTTPS site before the phone gets mad about my not agreeing in time and disconnects, visiting any site in the default Samsung browser.) I would like to reduce my amount of wrangling to zero. Is there a good way to do this?
Response by poster: (my Android detects captive portals and uses a Google server to trigger the redirect to show the portal, and it usually works well- it might be an Android 6.0 thing, or maybe Samsung disabled it for your phone?)
I’m using a Galaxy 4, and my last system update was back in 2015. Boo.
posted by Going To Maine at 5:12 PM on September 2, 2016
I’m using a Galaxy 4, and my last system update was back in 2015. Boo.
posted by Going To Maine at 5:12 PM on September 2, 2016
Could you whitelist a bogus site in https everywhere and then "visit" that site to trigger the wifi signin page redirect?
posted by zippy at 5:50 PM on September 2, 2016
posted by zippy at 5:50 PM on September 2, 2016
If you trust using an app to auto-login to the captive portal, an app like this or this might work for you. There are a few variants on this theme in the play store; I searched for "wifi login" to find these.
posted by Aleyn at 6:08 PM on September 2, 2016
posted by Aleyn at 6:08 PM on September 2, 2016
It strikes me that the real problem here is "HTTPS Everywhere" and your problem would go away if you stopped using it. Is it really that important to you?
posted by Chocolate Pickle at 9:46 PM on September 2, 2016
posted by Chocolate Pickle at 9:46 PM on September 2, 2016
HTTPS Everywhere is a bit 2010-2011 era, and with the Snowden NSA revelations and NSA tapping of Google and Yahoo data center communications, most sites where https is actually a significant issue are already using various techniques to redirect clients into https. As Chocolate Pickle suggests, from a certain point of view, H/E is your actual problem because it is changing the expected behaviour of the browsing/networking environment. It could also be argued that captive portals are changing the expected behaviour of the browsing/networking environment, but you don't really have a good opportunity to change that other than to not use public wifi. The actual problem is that there are two things, H/E and the captive portal, that are tinkering with the browsing environment in a fundamentally incompatible way.
Our remote laptop users have similar issues here. When connecting from a hotel or other public wifi, I suggest that they need to make sure they're actually connected to the Internet prior to connecting to the company network via VPN, and if they call in for tech support, the first thing on the support script is to make them go to cnn.com and read off the headline. The overall process of connecting to hotel or public wifi is rather pathetically nonstandardized, so if you cannot find an app that automates the captive portal sign-in, you probably need to do what our remote laptop users do when connecting to random wifi: connect, pull up a web site to make sure that you actually have connectivity, and then go about your business.
It might come to seem like less "complicated wrangling" if you can come to terms with the fact that there isn't really a reliably standard and easier way to go about it, and then just commit to a consistent process of doing this on your Android device's built-in web browser as part of the "connecting to wifi" process. I'm guessing that everyone would agree that this is sucky, but modifying your connecting environment to be compatible with the expectations of the destination network (especially bearing in mind the wide variety of potential expectations) is probably the only real fix.
I don't really suggest disabling HTTPS Everywhere, but it is almost certainly buying you less today than it was five years ago, so if a complicated connection procedure isn't acceptable to you, take a very close look at the sites you're visiting and see if maybe they're already https redirecting without HTTPS Everywhere.
posted by jgreco at 4:59 AM on September 3, 2016 [1 favorite]
Our remote laptop users have similar issues here. When connecting from a hotel or other public wifi, I suggest that they need to make sure they're actually connected to the Internet prior to connecting to the company network via VPN, and if they call in for tech support, the first thing on the support script is to make them go to cnn.com and read off the headline. The overall process of connecting to hotel or public wifi is rather pathetically nonstandardized, so if you cannot find an app that automates the captive portal sign-in, you probably need to do what our remote laptop users do when connecting to random wifi: connect, pull up a web site to make sure that you actually have connectivity, and then go about your business.
It might come to seem like less "complicated wrangling" if you can come to terms with the fact that there isn't really a reliably standard and easier way to go about it, and then just commit to a consistent process of doing this on your Android device's built-in web browser as part of the "connecting to wifi" process. I'm guessing that everyone would agree that this is sucky, but modifying your connecting environment to be compatible with the expectations of the destination network (especially bearing in mind the wide variety of potential expectations) is probably the only real fix.
I don't really suggest disabling HTTPS Everywhere, but it is almost certainly buying you less today than it was five years ago, so if a complicated connection procedure isn't acceptable to you, take a very close look at the sites you're visiting and see if maybe they're already https redirecting without HTTPS Everywhere.
posted by jgreco at 4:59 AM on September 3, 2016 [1 favorite]
This thread is closed to new comments.
(my Android detects captive portals and uses a Google server to trigger the redirect to show the portal, and it usually works well- it might be an Android 6.0 thing, or maybe Samsung disabled it for your phone?)
posted by BungaDunga at 4:48 PM on September 2, 2016