Opened 14 years ago
Closed 10 years ago
#6493 closed enhancement (fixed)
WebPositive should be able to load pages with unverified SSL certs
Reported by: | archpaladin1 | Owned by: | pulkomandy |
---|---|---|---|
Priority: | high | Milestone: | R1/beta1 |
Component: | Applications/WebPositive | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | #10560, #10865 | |
Platform: | All |
Description
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.
Attachments (1)
Change History (19)
comment:1 by , 14 years ago
Component: | - General → Applications/WebPositive |
---|---|
Owner: | changed from | to
Version: | R1/alpha2 → R1/Development |
comment:2 by , 14 years ago
comment:3 by , 14 years ago
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.
comment:4 by , 14 years ago
Milestone: | R1 → R1/beta1 |
---|---|
Priority: | normal → high |
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.
by , 12 years ago
Attachment: | 0001-user-option-for-ssl-authentication.patch added |
---|
Basic fix for ssl error
comment:5 by , 12 years ago
patch: | 0 → 1 |
---|
comment:6 by , 12 years ago
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.
comment:7 by , 12 years ago
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.
comment:8 by , 12 years ago
Thanks for the input, I will hopefully be starting the credentials storage system soon.
follow-up: 11 comment:9 by , 12 years ago
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?
comment:11 by , 12 years ago
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.
comment:12 by , 11 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:13 by , 11 years ago
Status: | assigned → in-progress |
---|
comment:14 by , 11 years ago
I think this one may of been solved... I know i've visited sites with self-signed certificates without any issues.. PulkoMandy?
comment:15 by , 11 years ago
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.
comment:16 by , 11 years ago
Blocking: | 10560 added |
---|
comment:17 by , 10 years ago
Blocking: | 10865 added |
---|
comment:18 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | in-progress → closed |
Fixed in https://github.com/haiku/webkit/commit/0ac58519fe0f400930225a83575f0dc0cb5ea2ae.
UI is still rather crude and not very practical ,working on that next.
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.