WebPositive should be able to load pages with unverified SSL certs

[archpaladin1]

WebPositive throws an error when trying to load a page with a self-signed SSL certificate.

The error is:

Error loading <site>

Peer certificate cannot be authenticated with known CA certificates

While correct (and security-conscious), this should not prevent the user from continuing to browse that site if the user wishes.

[stippi]

This is indeed annoying, it would also be a problem with correctly signed sites that just happen not to be in the known certificates. The SSL errors can be ignored globally in the cURL WebCore backend, a better solution should be created, though, which ignores the error for a specific site only, if the user so wishes. As a temporary work around, you can remove the certs file from /boot/common/ssl/certs (if memory serves, just look at the WebPositive package to see what file it installs), which disables the SSL checks altogether.

[archpaladin1]

I looked, and there is a file /boot/common/ssl/certs/cacert.pem. Renaming or moving this file did allow the webpage to load, so your workaround is valid. I also suspect that putting in the certificate information for the self-signed CA in question would also work (and keep SSL checks from being completely disabled), but I didn't try that.

Please keep this case open until a proper solution is developed. It seems there should be a way to proceed despite not verifying the cert, as well as a good way to import a cert into the list of known CAs.

[scottmc]

This was voted as a must have for R1, so setting it as an R1/beta1 milestone. Keep in mind when fixing this one that the ssl directory will probably be moved to B_COMMON_DATA_DIRECTORTY/ssl sometime after alpha3 release.

[Freeman]

Basic fix for ssl error

[Freeman]

Patch still needs testing. Current implementation asks for user choice and to continue or cancel. If the user chooses continue, the page is reloaded with the authentication disabled once.

[stippi]

Thanks for the work! I see two problems with the patch. In the cURL backend, I think solution is really temporary. As a user, one would want to have a persistent white list of servers. It should work very much like how the persistent cookie jar works. I imagine a HashSet of white listed servers to replace the single "ignore server" field, and the list needs to be stored when WebPositive quits and restored when it launches.

The second problem is with the code in Window: It is a layer breach, Window should know nothing about the cURL backend. The layering is like this: WebCore <-> WebKit <-> WebPositive. Everything in WebPositive needs to use the WebKit API only, never any WebCore stuff directly. You can look at how getting authentication credentials is handled, it should be similar. It's a bit more overhead, but it really can't work any other way.

[Freeman]

Thanks for the input, I will hopefully be starting the credentials storage system soon.

[Freeman]

Just two quick questions, If I set create a function in Webkit to do the manipulation of data in Webcore and use Webpositive to access the function it would not be a breach right? Also where should the list be stored?

[Freeman]

Anyone?

[stippi]

Replying to Freeman:

Just two quick questions, If I set create a function in Webkit to do the manipulation of data in Webcore and use Webpositive to access the function it would not be a breach right? Also where should the list be stored?

Sorry for the delay. Yes, putting the function in WebKit, accessing WebCore stuff and then accessing the WebKit function from within the browser application is the way to go. There are lots of examples of this in the code (FrameLoaderHaiku.cpp if memory serves), one example where the cURL backend is used is authentication (user/password). Just follow the path this data takes through the layers. Never include any WebCore header in the browser code and you should be fine.

As far as were to store the list, only the browser can actually store anything. Like I mentioned, you could follow the code path that the cookie stuff takes. I hope I wasn't lazy and hardcoded some path, but I believe the browser tells the cURL backend, via a WebKit method of course, where to load the cookies from. But be aware that I was lazy with the cookie stuff, since I knew they were very incomplete and needed a lot more work. So I only put some stuff in place to quickly get it working in most cases. But for example the constant failures in GMail to connect to the chat are probably because of the shallow cookie implementation. In any case, it could work similarily for the list of accepted servers with bad SSL certificates.

[kallisti5]

I think this one may of been solved... I know i've visited sites with self-signed certificates without any issues.. PulkoMandy?

[pulkomandy]

Oops, didn't comment on this. Currently, our network backend will blindly accept SSL connections without checking the certificate. That's not a proper solution, what we need is to abort the connection, and warn the user about it. But, we must also allow the user to add an exception for that certificate.

[pulkomandy]

(In #10865) This is already tracked in #6493, although the ticket summary there is out of date.

[pulkomandy]

Fixed in ​https://github.com/haiku/webkit/commit/0ac58519fe0f400930225a83575f0dc0cb5ea2ae.

UI is still rather crude and not very practical ,working on that next.