Captive Portal & https-traffic

[hitzlbritzl]

Hello all,

I experienced the following behaviour of the captive portal:
a) no ssl-certificate selected: https-connections (like google) will timeout without getting redirected to the captive portal
b) default ssl-certificate selected: https-connections get redirected to the captive portal, but as the certificate is not signed, the browser will place a warning message. So this option is not feasible as all users would have to install the corresponding root certificate or always click through the browser warnings.

Question is: in the case that no ssl-certificate is selected: could the captive portal then handle https connections, redirect them to the portal (without Transport Layer Security, TLS) and then go back to the https-connection (e.g. https://www.google.com, again with TLS)? As I would like to use the captive portal only to show the terms of use together with an accept button (no username/password), no security problem is there because no passwords could be transmitted unencrypted.

Regards Johann

[franco]

Hi Johann,

Regarding (a): Yes, that is expected behaviour. We can't "intercept" HTTPS without a certificate, and we can't forward it, because the user is not authenticated.

Regarding (b): This is also expected behaviour. Not having a warning here for self-signed certificates would be a fundamental problem for how trust works with SSL certificates. The only way to fix this is to get a trusted certificate from a store or maybe from Let's Encrypt. Host name verification still doesn't work here, because you'll (likely) not get a certificate for "www.google.com". Again, this is how SSL secures the web.

Regarding your question: HTTPS is a HTTP connection wrapped in SSL, so to redirect the HTTP the SSL connection must be established, which doesn't work without a certificate.

Fundamentally speaking, the user needs an account in order to stay logged in, but what you can do is use a system account for all of them, the button click posts this username/password to the server. You won't need SSL for that, that's true. The username/password will be in plain text in the source code of the transferred JavaScript anyway.


Cheers,
Franco