4 ms·

I wonder how it will work against websites like http://neverssl.com http://neverssl.com (which helps me to log in to some wifi portals, HTTPS Everywhere shows t

by whym 6y ago

I wonder how it will work against websites like http://neverssl.com http://neverssl.com (which helps me to log in to some wifi portals, HTTPS Everywhere shows the prompt for a temporary exception.)

mittermayr 6y ago
An alternative I use is http://captive.apple.com http://captive.apple.com (other OS vendors have their own). Which may have a higher chance of being detected by the portal (more likely to be white-listed) and triggering the prompt correctly.
- gspr 6y ago
  http://detectportal.firefox.com/success.txt http://detectportal.firefox.com/success.txt is Mozilla's.
- stephen_g 6y ago
  Frustratingly it doesn’t always work that way - one I have seen that is just bizarre is Qantas inflight wifi. It actually allows captive.apple.com to bypass the captive portal, so your iPhone, iPad or Mac thinks it has internet access. So you try to navigate to a page or use an app and just hit HTTPS certificate errors! So you have to think of some other site that is only HTTP or get the information card and enter the address it tells you to log in! It’s crazy, because somebody must have had to configure something to explicitly let that through (not understanding the purpose of it?) and it just completely breaks it! I’ve tried to leave feedback (there is a link from the portal page) that they’ve screwed it up but it hadn't been fixed the last flight I went on..
  - dspillett 6y ago
    Perhaps they were told to make Apple stuff work without login, and just blindly whitelisted all known Apple host address ranges.
  - judge2020 6y ago
    It might be forging responses from captive.apple.com and not actually sending those out to the internet. If you set up your own intercept that responds 'Success', iOS will assume it has internet as well.
  - ryan29 6y ago
    Like the sibling post said, you're probably seeing certificate errors caused by the portal, not traffic being allowed to captive.apple.com. With http, a captive portal system will intercept your connection and redirect you to the portal authentication page. Most modern devices deal with it automatically by checking those plain http urls when the network comes up. For example, I think the way it works on iOS is that when you connect to a WiFi network the OS tries to hit http://captive.apple.com http://captive.apple.com which triggers the redirect and prompts you for authentication. With https, there's no way to have a valid TLS certificate for a random site the user is connecting to (ex: captive.apple.com), so you get a TLS error if you're attempting to connect to an https site while the portal is trying to redirect you for authentication.
dspillett 6y ago
I'll have to remember that for next time I get "wireless on the train doesn't work, I get some security error" via SMS. Last time I pointed them at one of my sub-domains that still serves plain HTTP to bring up the captive portal (which wasn't trying to charge, or apparently even advertise, the network just insisted you hit it at least once to be told "Hello!" and presumably have your MAC added to the whitelist for a time). The name "neverssl" might confuse non-techies though. Maybe I'll register something like iswirelessbroken.com for doing the same thing.
- t0astbread 6y ago
  Captive portals are not unique to wireless networks so if you are gonna register a new name you might wanna go with something more generic (like "isnetworkbroken.com" or something like that).
iso1631 6y ago
It will say "this website doesn't support https, do you want to connect anyway"
- tialaramex 6y ago
  Just checked this yup. If I go to https://neverssl.com/ https://neverssl.com/ I get a warning explaining that this site doesn't have a certificate for neverssl.com but only for Cloudfront (presumably where it's hosted) But if I try to go to http://neverssl.com/ http://neverssl.com/ then I get the message explaining that the HTTPS site doesn't work, do I want the insecure HTTP one instead?
  - iso1631 6y ago
    If I specify http://whatever.com http://whatever.com in the address bar, or if I follow a link to http://whatever.com http://whatever.com, I'd expect it to attempt to connect to port 80 on whatever.com, and not redirect to https unless the page responds with a Location header If I type "whatever.com", I'm happy with it to try port 443 first I'm not sure if a http/80 page should be at least HEADed to see if there's a redirect to https/443 before throwing up the "this is not secure"
    - ldjb 6y ago
      I can understand your use case, but I know a lot of people (often those who use computers infrequently) type out the full URL all the time. They don't know what HTTP or HTTPS is, they don't realise you can omit that part. They just want to access the website. For those people, it makes sense that typing "http:// http://" would take them to the "https:// https://" site if available. Although they did specify HTTP, it isn't necessarily what they actually wanted. I think the use case you describe (whilst valid) only applies to a relatively small pool of people. Most people don't really understand HTTP or HTTPS very well. They know it's part of the web address, and some know that "https:// https://" is "secure", but that's about it. I think it makes sense to direct people to the secure version of the site as much as possible, whilst of course providing a mechanism to switch to the HTTP version if necessary.
devit 6y ago
It might be time to introduce a protocol that allows networks to display authentication prompts without needing to MITM HTTP connections. It's not even hard, all that's needed is to add an "authentication URL" field to DHCP and IPv6 router advertisements.
- MayeulC 6y ago
  Isn't it part of what "Hotspot 2.0" (https://en.wikipedia.org/wiki/Hotspot_%28Wi-Fi%29#Hotspot_2.0 https://en.wikipedia.org/wiki/Hotspot_%28Wi-Fi%29#Hotspot_2....) provides? It certainly solves the login part, it might also solve the register part?
- tialaramex 6y ago
  https://tools.ietf.org/html/rfc8910 https://tools.ietf.org/html/rfc8910 Captive-Portal Identification in DHCP and Router Advertisements (RAs) Actually the future is ambient network access. But on the way there, the likely pathway is larger and larger federated network authentication. Most of the world's higher education students/ staff are enrolled into EduROAM, so that it doesn't matter if they're in a classroom in Tokyo or London, the federated system concludes they are a legitimate user somewhere and so they can connect here. In these federated systems there's no use for a "Captive portal" since it could not safely achieve federated authentication, so there isn't one.
MinusGix 6y ago
I personally access 10.0.0.1 and that works at numerous places with wifi portals. Especially useful when my device/browser doesn't automatically detect that there is a captive portal.
morpheuskafka 6y ago
Firefox has is own such domain, detectportal.firefox.com, which would presumably be excluded. But otherwise, it looks like the user will just have to turn it off for these kind of sites. Same goes for things like browsing APT update servers that don't use HTTPS by design.
surround 6y ago
Firefox by default tries to connect to http://detectportal.firefox.com/success.txt http://detectportal.firefox.com/success.txt in order to detect captive portals.

by whym 6y ago

I wonder how it will work against websites like http://neverssl.com http://neverssl.com (which helps me to log in to some wifi portals, HTTPS Everywhere shows the prompt for a temporary exception.)

mittermayr 6y ago

An alternative I use is http://captive.apple.com http://captive.apple.com (other OS vendors have their own). Which may have a higher chance of being detected by the portal (more likely to be white-listed) and triggering the prompt correctly.

gspr 6y ago
http://detectportal.firefox.com/success.txt http://detectportal.firefox.com/success.txt is Mozilla's.
stephen_g 6y ago
Frustratingly it doesn’t always work that way - one I have seen that is just bizarre is Qantas inflight wifi. It actually allows captive.apple.com to bypass the captive portal, so your iPhone, iPad or Mac thinks it has internet access. So you try to navigate to a page or use an app and just hit HTTPS certificate errors! So you have to think of some other site that is only HTTP or get the information card and enter the address it tells you to log in! It’s crazy, because somebody must have had to configure something to explicitly let that through (not understanding the purpose of it?) and it just completely breaks it! I’ve tried to leave feedback (there is a link from the portal page) that they’ve screwed it up but it hadn't been fixed the last flight I went on..
- dspillett 6y ago
  Perhaps they were told to make Apple stuff work without login, and just blindly whitelisted all known Apple host address ranges.
- judge2020 6y ago
  It might be forging responses from captive.apple.com and not actually sending those out to the internet. If you set up your own intercept that responds 'Success', iOS will assume it has internet as well.
- ryan29 6y ago
  Like the sibling post said, you're probably seeing certificate errors caused by the portal, not traffic being allowed to captive.apple.com. With http, a captive portal system will intercept your connection and redirect you to the portal authentication page. Most modern devices deal with it automatically by checking those plain http urls when the network comes up. For example, I think the way it works on iOS is that when you connect to a WiFi network the OS tries to hit http://captive.apple.com http://captive.apple.com which triggers the redirect and prompts you for authentication. With https, there's no way to have a valid TLS certificate for a random site the user is connecting to (ex: captive.apple.com), so you get a TLS error if you're attempting to connect to an https site while the portal is trying to redirect you for authentication.

dspillett 6y ago

I'll have to remember that for next time I get "wireless on the train doesn't work, I get some security error" via SMS. Last time I pointed them at one of my sub-domains that still serves plain HTTP to bring up the captive portal (which wasn't trying to charge, or apparently even advertise, the network just insisted you hit it at least once to be told "Hello!" and presumably have your MAC added to the whitelist for a time). The name "neverssl" might confuse non-techies though. Maybe I'll register something like iswirelessbroken.com for doing the same thing.

t0astbread 6y ago
Captive portals are not unique to wireless networks so if you are gonna register a new name you might wanna go with something more generic (like "isnetworkbroken.com" or something like that).

iso1631 6y ago

It will say "this website doesn't support https, do you want to connect anyway"

tialaramex 6y ago
Just checked this yup. If I go to https://neverssl.com/ https://neverssl.com/ I get a warning explaining that this site doesn't have a certificate for neverssl.com but only for Cloudfront (presumably where it's hosted) But if I try to go to http://neverssl.com/ http://neverssl.com/ then I get the message explaining that the HTTPS site doesn't work, do I want the insecure HTTP one instead?
- iso1631 6y ago
  If I specify http://whatever.com http://whatever.com in the address bar, or if I follow a link to http://whatever.com http://whatever.com, I'd expect it to attempt to connect to port 80 on whatever.com, and not redirect to https unless the page responds with a Location header If I type "whatever.com", I'm happy with it to try port 443 first I'm not sure if a http/80 page should be at least HEADed to see if there's a redirect to https/443 before throwing up the "this is not secure"
  - ldjb 6y ago
    I can understand your use case, but I know a lot of people (often those who use computers infrequently) type out the full URL all the time. They don't know what HTTP or HTTPS is, they don't realise you can omit that part. They just want to access the website. For those people, it makes sense that typing "http:// http://" would take them to the "https:// https://" site if available. Although they did specify HTTP, it isn't necessarily what they actually wanted. I think the use case you describe (whilst valid) only applies to a relatively small pool of people. Most people don't really understand HTTP or HTTPS very well. They know it's part of the web address, and some know that "https:// https://" is "secure", but that's about it. I think it makes sense to direct people to the secure version of the site as much as possible, whilst of course providing a mechanism to switch to the HTTP version if necessary.

devit 6y ago

It might be time to introduce a protocol that allows networks to display authentication prompts without needing to MITM HTTP connections. It's not even hard, all that's needed is to add an "authentication URL" field to DHCP and IPv6 router advertisements.

MayeulC 6y ago
Isn't it part of what "Hotspot 2.0" (https://en.wikipedia.org/wiki/Hotspot_%28Wi-Fi%29#Hotspot_2.0 https://en.wikipedia.org/wiki/Hotspot_%28Wi-Fi%29#Hotspot_2....) provides? It certainly solves the login part, it might also solve the register part?
tialaramex 6y ago
https://tools.ietf.org/html/rfc8910 https://tools.ietf.org/html/rfc8910 Captive-Portal Identification in DHCP and Router Advertisements (RAs) Actually the future is ambient network access. But on the way there, the likely pathway is larger and larger federated network authentication. Most of the world's higher education students/ staff are enrolled into EduROAM, so that it doesn't matter if they're in a classroom in Tokyo or London, the federated system concludes they are a legitimate user somewhere and so they can connect here. In these federated systems there's no use for a "Captive portal" since it could not safely achieve federated authentication, so there isn't one.

MinusGix 6y ago

I personally access 10.0.0.1 and that works at numerous places with wifi portals. Especially useful when my device/browser doesn't automatically detect that there is a captive portal.

morpheuskafka 6y ago

Firefox has is own such domain, detectportal.firefox.com, which would presumably be excluded. But otherwise, it looks like the user will just have to turn it off for these kind of sites. Same goes for things like browsing APT update servers that don't use HTTPS by design.

surround 6y ago

Firefox by default tries to connect to http://detectportal.firefox.com/success.txt http://detectportal.firefox.com/success.txt in order to detect captive portals.