[webkit-gtk] TLS API in WebKit2

[Carlos Garcia Campos]

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. 

We want to support at least:

 - Set SOUP_SESSION_SSL_STRICT property. 
 - Set SOUP_SESSION_USE_SYSTEM_CA_FILE property
 - Set SOUP_SESSION_TLS_DATABASE property or at least provide a file to
create a database object from the file
 - 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?

For SOUP_SESSION_SSL_STRICT, SOUP_SESSION_USE_SYSTEM_CA_FILE and
SOUP_SESSION_TLS_DATABASE we could add specific api to
WebKitWebContext, or maybe even WebKitSettings, but I think it fits
better in WebKitWebContext rather than settings.

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

GTlCertificateFlags and GTlsCertificate are also properties of
SoupMessage, but in case of error we don't have access to the message,
so we would need to include them as part of the ResourceError generated
for the SSL error. The problem is how to expose it in the API, the
load-error signal provides a GError already, but we can't extend GError
to include tls error information. We could add a new parameter to the
signal for that, but it would only make sense in case of SSL error.
Another possibility would be to add an specific signal for ssl errors
that includes the GTlCertificateFlags and GTlsCertificate as signal
arguments.

The certificate is already sent from the web process to the UI process
as a  PlatformCertificateInfo (not yet implemented in the gtk port) in
DidCommitLoad message, so in this case we could add it to the uri
request or response before emitting the committed signal and it could be
obtained using uri request/response api. The same it's done with the
SOUP_MESSAGE_CERTIFICATE_TRUSTED flag.

An alternative solution for these two use cases would be to expose a
common way to get the certificate and the flags, for example as part of
the web view api, something like webkit_web_view_get_tls_certificate(),
webkit_web_view_get_tls_certificate_flags() for example. With this, in
case of ssl error we get the certificate and flags from the received
error and save it in the view before emitting load-error signal and we
save the certificate received from the DidCommitLoad before emitting
committed signal. It looks a bit weird having the certificate and the
flags in the view though, but it would be a common api and very
convenient to use.

I'm not network expert nor security expert either, so maybe I'm missing
something obvious here. Any help with this would be very welcome :-)

Opinions?

-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.webkit.org/pipermail/webkit-gtk/attachments/20120620/3d3d11f1/attachment.bin>