[SSL] Using public hotspots with registration portals might be a problem for oc client connection

[godfuture]

Open, public hotspots often require to first login to a portal. After login, a dns timeout occurs and normally internet is available.

But before the login on portal was done, oc client opens cert validation dialog. the shown cert is not the one of the server, but of the portal. I usually decline the dialog, because I will do the login and accepting this cert is then not required.

Problem: after login, when internet is available, I am not able to connect my oc client to server. Clicking login does not show any action. Nothing happens.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/11241768-ssl-using-public-hotspots-with-registration-portals-might-be-a-problem-for-oc-client-connection?utm_campaign=plugin&utm_content=tracker%2F216457&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F216457&utm_medium=issues&utm_source=github).

[danimo]

The question is: what do we want here?

1. The popup showing up is usually never right, in particular after restart -> Never show it by default but only if you actively sign in (the fact that the error message is hideous is another problem, documented in another task, the number of which I do not have readily available)
2. You want to sign into the hotspot: Of course, but only a few OSes have APIs for that. We should call those APIs where they exist (IIRC mac), and just wait for the user to auth through a browser, i.e. keep retrying silently.

Bonus points: Shibboleth opens a webview, and has the same problem. But that's for later.

/cc @jancborchardt

[jancborchardt]

@danimo yeah, probably retry silently, and all the other things you say. Never show this popup. It’s not really our job to show a page of 192.168.0.1 so ppl can log in.

[plinss]

Probably also related to #203 DNS caching issue. Hotspot most likely gives spoofed IP address for first lookup, if the client caches that IP it will fail to connect after the internet connection is properly established.

[guruz]

As a first fix, in sslAuthenticatioRequired we should check if we're coming from the ConnectionValidator or from a regular request.
In case of the regular request, we could just go into a timeout state.
Then until the ConnectionValidator is checking again we might be connected already to the captive portal.

FYI @ckamm @ogoffart

[ogoffart]

we should check if we're coming from the ConnectionValidator or from a regular request.
In case of the regular request, we could just go into a timeout state.

That would only work if there is only one host. With direct URL or redirection, there may be several host, specific to some files. In which case we might have another certificate for them to accept.
But this is not the common case.

Yet, it would not solve the problem. because the connectionvalidator will then run quickly after that and show this dialog.

I don't really know what we can do.
Try again to open a connection from the dialog every minute, and if the connection works, then restart the connection?

[guruz]

@ogoffart I didn't mean to check for any hosts or redirection.
Just check which code path we're from, e.g. tag the QNetworkReply with something.

I had commented over one year ago so I don't remember in detail what I imagined.

But I think it was something about NOT showing the scary dialog immediately if this account was connected before (in the same session) and the request is a regular request.
So one would still see the scary dialog if one starts the client freshly.

[amedranogil]

how about a "retry" option in the "SSL certificate incorrect" dialog, which the user may click after login?
This might also help on other cases when debugging SSL certificates on the server or other networking testing cases.

[arthurzenika]

This is also a problem when a nextcloud is behind a VPN.