[webkit-gtk] Progress about TLS handling in WebKit2

[Carlos Garcia Campos]

After thinking more about it and looking at ephy and other browsers
code, I think that we want to support at least two features regarding
the TLS handling:

 - Provide certificate information to apps, so that they can set the
security level and provide information about the certificate, like
chromium does in the location entry.

 - Allow apps to decide whether accept or deny a website load depending
on the certificate.

Provide certificate information to apps
-------------------------------------------------

In WebKit2 there's already a PlatformCertificateInfo abstraction that is
sent to the UI process as part of the loadCommited message and stored in
the WebFrameProxy. The C API allows to get the certificate info from a
WKFrame. This is always sent, no matter if the are tls errors or not. 

In our case, we could implement the PlatformCertificateInfo based on
GTlsCertificate object and serialize/deserialze it using the
"certificate" property. We should probably include the TLS errors too. 

Current epiphany code, gets the soup message flags from the main
resource request when load status is committed and simply checks whether
SOUP_MESSAGE_CERTIFICATE_TRUSTED is present or not to set the security
level as HIGH or BROKEN. SoupMessage sets that flag depending on whether
tls-errors is empty or not, so including tls-errors as part of the
PlatformCertificateInfo serialization would allow us to decide whether
the certificate can be trusted or not (and it provides more information,
for example, we could make the lock icon clickable and give more details
about the errors in a dialog or in a tooltip).

So, the question is how to expose this in the API. First, we want to
provide both, the certificate info and the tls-errors flags, so we could
give both as parameters of a signal, or we could add a simple wrapper
WebKitCertificateInfo or WebKitCertificate containing both. I think we
have several options:

 a) Use a signal emitted right after the load-changed with committed
providing both the certificate and tls-errors as parameters.
WebKitWebView::received-certificate or something like that.

 b) Before emitting the load-changed signal with committed, we set the
certificate and tls-errors to the WebKitURIResponse of the main
resource. And we add API to WebKitURIResponse to get the certificate and
tls-errors. The ephy code would be mostly the same with this solution.

 c) An alternative to b) would be to always serialize the certificate
info with the ResourceResponse, and the WebKitURIResponse will always be
created with the certificate and tls-errors. This would be simpler, but
we would be including the certificate in all resource responses which
could affect the IPC traffic.

 d) Save the certificate and tls-errors in the web view, similar to what
WK2 does, saving the certificate info in the frame proxy. Then we could
add api to get both from the view, or add a wrapper as I said before
containing both.

what do you think? any other possibility?

Allow apps to decide whether accept or deny a certificate
-------------------------------------------------------------------------

This is not used by current ephy, but it would allow apps to implement
the custom error page that shows information about the certificate and
tls errors, and the user can ignore the errors and continue with the
load or cancel the load. I've started to work on this following Dan
suggestions, and adding support for this in WebCore. The patch has been
rejected because it's soup specific, but I will rework it to make it
available to all other ports More details here:

https://bugs.webkit.org/show_bug.cgi?id=90267

Once we have the required support in WebCore, we'll send a message to
the UI process in case of ssl errors to let the webkit layer decide. In
this case I think we can use the generic permission request api that
Mario added for geolocation. We would only need to add a
WebKitTlsPermissionRequest object that implements the
WebKitPermissionRequest interface and provides API to get the
certificate and tls-errors. Then we simply emit the
WebKitWebView::permission-request signal when we receive the message
from the web process. 

Comments? 
-- 
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/20120705/05d65740/attachment.bin>