Detect insecure/ mixed certificates [$50]

[Cris Dywan]

We should recognize that http and SSL or valid and unknown certificates are being mixed. libsoup doesn't do anything to that effect out of the box.

Test case https://sslfp.rya.nc/test.php

Semi-related lp:~kalikiana/midori/gtk2gcr

[Donte Greene (flykidd)]

Approved 1 minute ago.

[Cris Dywan (kalikiana)]

This bug has no reason to be private, there's no sensitive data attached.

Incidentally the bug was opened almost two years ago and we've had at least two unsuccessful attempts at fixing it, so I'll sum up the current situation, in the hopes it may get this solved eventually:
*with WebKit1* libSoup exposes ssl-strict, if TRUE it's impossible to load anything that's absent from the root certificates, otherwise it's up to the user of the API.
WebKitGTK+ doesn't enforce certificate validation.
Midori verifies the certificate of the WebView, and if GCR is available considers pinned certificates errors out depending on that, otherwise there's no way to act on it because it would be impossible to opt out.
Attempts at making GCR mandatory were met with little interest - if it were required, and somebody figured out why the backend doesn't work on some systems, ssl-strict could be used *with WebKit1*.
Resources within the WebView aren't validated separately by WebKit or Midori. There was an attempt at implementing that some time ago, it didn't work, so time went on, and the related branch tried something similar, again it didn't work without regressions.
Part of this being tricky is that, from my experience, it's hard to associate resources, requests and the view they relate to - anything blocking the current main page from loading effectively breaks the browsing experience.
Note the *with WebKit1* annotations, WebKit2 exposes no stable API that allows Midori to address the issue, that I'm aware of - I would be very happy to be corrected.

[Lewis Goddard (lewisgoddard)]

WebKit2 should provide this commodity somewhere, as both Chrome (back when it was used) and Safari detect insecure certificates and other mixed content, blocking it by default. It's obviously quite a serious security flaw if I can load any insecure content on a supposedly secure domain.

[Michael Catanzaro (mike-catanzaro)]

Safari doesn't use WebKitGTK+ and Chrome doesn't even use WebKit anymore; the proper comparison is to Epiphany.

Anyway since ~2.6.3, by default all insecure content will be blocked and if the main resource uses an unacceptable certificate the load will be treated as a network error; you have to go out of your way to allow loading content with unacceptable certificates. I guess you probably want to do that, to allow users to bypass certificate errors. Relevant API is webkit_web_view_get_tls_info(), WebKitWebView::load-failed-with-tls-errors, WebKitWebResource::load-failed-with-tls-errors, webkit_web_context_allow_tls_certificate_for_host(), and webkit_web_context_[get,set]_tls_errors_policy(). That's enough for Epiphany and hopefully it's enough for you too; if not, please holler.

In WebKit1, I caution that if you try to do your own certificate verification, you have to be very careful to prevent session cookies from being sent to the attacker (make sure to block the connection _before_ any HTTP request is sent); last time I checked a year ago, neither Midori nor Epiphany got this right (but nowadays Epiphany is fine). But in the grand scheme of things, that is the least of your problems, since WebKit1 doesn't get security updates anymore....

[Cris Dywan (kalikiana)]

In the latest code any page that doesn't have TLS and uses only resources with valid TLS certificates will be considered insecure (including regular http://) so I'll consider this fixed.