[webkit-gtk] TLS API in WebKit2

[Dan Winship]

On 06/20/2012 11:30 AM, Carlos Garcia Campos wrote:
> As with the cookies, in WebKit2 we need to provide specific API for TLS
> handling, because the network happens in the web process, and it's not
> possible to access the soup session from the UI process.

Right. So, SoupSession's TLS-related properties are a complete disaster,
so you definitely don't want an API that looks anything like that.

> We want to support at least:
> 
>  - Set SOUP_SESSION_SSL_STRICT property. 

I think what you want is a signal basically like
GTlsConnection::accept-certificate; WebKit would always be ssl-strict =
FALSE internally, and when it got a response with a bad certificate, it
would emit some signal to let the app decide whether or not to accept
the response anyway. Or alternatively there could be an "always accept
certs" property. Default should be to not do that though.

>  - Set SOUP_SESSION_USE_SYSTEM_CA_FILE property
>  - Set SOUP_SESSION_TLS_DATABASE property

You definitely want ssl-use-system-ca-file = TRUE by default.

To support the tls-database property, you would have to write a
GTlsDatabase implementation that proxied calls between the two
processes. Then you could pass that tlsdb to libsoup in the network
process, and have it talk to the tlsdb that the application gave you in
the UI process. Since you presumably already have easy ways of
communicating between the processes, this shouldn't be that hard. OTOH,
I'm not really sure that letting the user provide their own tlsdb is
really necessary, so maybe put this one off for now?

(You'd also need to be careful in the proxy GTlsDatabase implementation
that it can't end up blocking the network process while waiting for the
UI process.)

> or at least provide a file to create a database object from the file

There's not really a whole lot of reason to create a database from a
file other than the default system certdb, and if you did need to do
that, you're just as likely to want to create it from a static string,
or a GResource, or a GSetting value, etc. So I don't think we need to
privilege file-based GTlsDatabases.

>  - Check SOUP_MESSAGE_CERTIFICATE_TRUSTED flag
>  - Provide further information in case of SSL error (GTlCertificateFlags
> and GTlsCertificate)
>  - Provide access to the GTlsCertificate
> 
> Am I missing anything?

Client-side certificates, though of course, neither libsoup nor WebKit
nor epiphany/midori/etc support that currently. It works vaguely like
authentication though; the request would fail with
G_TLS_ERROR_CERTIFICATE_REQUIRED, and the app would have to somehow
select a GTlsCertificate and pass it to the network process.

I think the answer here though is that we need to wait until the
underlying APIs are there, and then fit them into WK2.

> SOUP_MESSAGE_CERTIFICATE_TRUSTED flag could be exposed by
> WebKitURIRequest and WebKitURIResponse APIs, something like
> webkit_uri_response_is_certificate_trusted() or something similar.

An enum would probably work better: there's plain http, https with an
untrusted cert, https with a trusted cert, and https with an EV cert.
(Anything else that we need to distinguish in the UI?)

> It looks a bit weird having the certificate and the
> flags in the view though

Yeah, it does.

-- Dan