IRC conversation:

<drago01_> dcbw: hi, around?
<dcbw> drago01_: hey
<drago01_> dcbw: is the connectivty check supposed to work when the captive portal uses ssl?
<dcbw> drago01_: you  mean like it does a redirect to some https:// enabled page?
<drago01_> dcbw: yes
<drago01_> it seems to cause some confusion and stay at the "question mark" forever ... I had to go to a non https page in firefox to see the portal
<dcbw> drago01_: yeah, I think that triggers "limited" connectivity, not portal
<dcbw> looking at the code
<dcbw>  if (SOUP_STATUS_IS_TRANSPORT_ERROR (msg->status_code)) {
<dcbw>   _LOGI ("check for uri '%s' failed with '%s'", uri, msg->reason_phrase);
<dcbw>   new_state = NM_CONNECTIVITY_LIMITED;
<dcbw>   goto done;
<dcbw>  }
<dcbw> danw: ?
<danw> yeah, SOUP_STATUS_SSL_FAILED should be excluded from that check
<dcbw> though  maybe the that TRANSPORT_ERROR thing doesn't return TRUE for redirects since it's not really a transport error
<danw> redirects are already handled before that code runs
<dcbw> ah
<dcbw> danw: what is SSL_FAILED though?  would that  mean that if there's some problem with an HTTPS-enabled connectivity server, that it would end up in PORTAL?
<danw> well, there's really no reason to be using an https connectivity server...
* drago01_ was about to ask about that
<drago01_> there isn't really any "secret" it transport
<drago01_> s
<drago01_> so why bother?
<danw> nm-connectivity doesn't try to validate signatures, so it would probably mean you passed an https URI and the server responded with plain http
<dcbw> ok
<danw> or you reached the connectivity server, but it failed to do an https handshake, or responded with an expired certificate
<dcbw> is there a way to differentiate those kinds of errors from an https portal?
<danw> there's no easy way to distinguish "captive portal returned a bogus response to an https request" from "actual connectivity server returned a bogus response to an https request"
<dcbw> I mean, real ones versus unreal ones :)
<danw> not trivially
<drago01_> domain in the cert doesn't match the domain of the connectivity server?
<dcbw> danw: could we disable redirects, and just assume that any redirect is portal-suckage?
<danw> that doesn't distinguish "captive portal" from "the connectivity server got misconfigured"
<dcbw> danw: I assume that last comment was for drago01_?
<danw> yes
<grawity> HTTPS for captive portal detection isn't a good idea... older pfsense (before 2.2) only had HTTP support and any HTTPS connection attempts would simply get discarded until login
<danw> dcbw: there isn't an http redirect happening here; either the portal responds to the http request with an incorrectly-signed https response, or it responds with non-https
<drago01_> danw: the latter would quickly trigger a shitstorm so shouldn't happen (for a long time)
<danw> drago01_: we've already had configuration failures on the fedora connectivity server at least once
<drago01_> ugh
<danw> however, this is yet another reason we shouldn't be using https; because that multiples the number of possible ways to misconfigure the server by about 1000
<dcbw> danw: oh, I was just assuming that the portal would first do a redirect to a different URL that was HTTPS enabled, I didn't know you could respond with HTTPS to an HTTP request
<danw> dcbw: you can't. you can't do either of those two things
<danw> dcbw: the portal can't do a redirect, because it would have to complete the https handshake before it could send the redirect
<danw> dcbw: and while it might respond to the https request with http, and maybe some browsers deal with that, that's not actually a valid thing to do
* danofsatx hat die Verbindung getrennt (Quit: Probably rebooting....)
<drago01_> danw: so the fix is "don't use https for the connectivity server" ?
<dcbw> so you can't do a 301 with an HTTPS URL for Location?
<dcbw> or 302 or whatever
<drago01_> shouldn't that work if the site that does the redirect have a valid cert?
<drago01_> i.e do the handshake and then send a redirect header
<drago01_> *has
<danw> dcbw: you can't send an http response until after you have completed the tls handshake
<dcbw> danw: what I meant was HTTP -> HTTPS
<grawity> drago01_: it might have a valid cert for the portal itself, but it cannot possibly have a valid cert for the actual hostname the client tried to access...
<dcbw> you  make an HTTP request to google.com, which is intercepted and responded to by the portal with a redireect or Refresh to an HTTPS URL
<danw> drago01_: given that NM isn't checking the domain name on the cert in this case, yes, in theory, as long as it used any cert, it could do that
<dcbw> in that case, I think we can assume we're portaled
<drago01_> grawity: I meant in general not for the portal case
<dcbw> and then any SSL errors just mean PORTAL not LIMITED
<danw> dcbw: if it's redirecting you to its own https url, then presumably it will handshake correctly, and then we'll get back a 200 OK response that does not contain the expected response, and we'll declare CONNECTIVITY_PORTAL
<dcbw> eg, assume that if SSL was used anywhere, it's PORTAL
<danw> dcbw: but if you aren't behind a portal and you make an http request to google.com then you'll get an https redirect...
<dcbw> danw: well, I've seen all kinds of stupid portal stuff too, like cert failures
<dcbw> danw: yeah google.com was a bad example
<dcbw> but what I mean is, if we can assume that connectivity URLs must be HTTP, then if HTTPS ever gets involved, we know there's a portal
<danw> we could perhaps declare that the configured connectivity URI is not allowed to return a redirect
<danw> sure
<drago01_> in that case the portal itself asked for a password ... and it was an unecrypted hotspot so using ssl there made sense for the portal
<dcbw> yeah
<drago01_> dcbw, danw: <nirik> beats me. Fun fact: we didn't actually create that setup for connectivity... it just started getting used for that.
<drago01_> (question was why it uses https)
<dcbw> danw: drago01_: ok, so the conclusion then... possibly we cannot assume HTTP-only for connectivity?
<dcbw> if there are already configs in the wild?
<danw> we can just stop supporting those configs
<danw> if the uri is https, just always claim CONNECTIVITY_FULL
<danw> and log a warning
<dcbw> that's true
<dcbw> note that our NM-connectivity-fedora uses https :(
<dcbw> but we can change that
<drago01_> we could use http://fedoraproject.org/static/hotspot.txt
<dcbw> it's currently https://fedoraproject.org/static/hotspot.txt, so yeah
<drago01_> yeah we should just fix that
<drago01_> don't even have to change the server config
<drago01_> dcbw: do you want me to file a bug or is that "report" good enough?
<dcbw> drago01_: bug would be great so we have somewhere to track it