Opened 13 years ago

Closed 9 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


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)

0001-user-option-for-ssl-authentication.patch (6.7 KB ) - added by Freeman 10 years ago.
Basic fix for ssl error

Download all attachments as: .zip

Change History (19)

comment:1 by anevilyak, 13 years ago

Component: - GeneralApplications/WebPositive
Owner: changed from nobody to stippi
Version: R1/alpha2R1/Development

comment:2 by stippi, 13 years ago

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.

comment:3 by archpaladin1, 13 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 scottmc, 12 years ago

Milestone: R1R1/beta1
Priority: normalhigh

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 Freeman, 10 years ago

Basic fix for ssl error

comment:5 by Freeman, 10 years ago

patch: 01

comment:6 by Freeman, 10 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 stippi, 10 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 Freeman, 10 years ago

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

comment:9 by Freeman, 10 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:10 by Freeman, 10 years ago


in reply to:  9 comment:11 by stippi, 10 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 pulkomandy, 10 years ago

Owner: changed from stippi to pulkomandy
Status: newassigned

comment:13 by pulkomandy, 9 years ago

Status: assignedin-progress

comment:14 by kallisti5, 9 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 pulkomandy, 9 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 pulkomandy, 9 years ago

Blocking: 10560 added

comment:17 by pulkomandy, 9 years ago

Blocking: 10865 added

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

comment:18 by pulkomandy, 9 years ago

Resolution: fixed
Status: in-progressclosed

Fixed in

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

Note: See TracTickets for help on using tickets.