[webkit-gtk] Progress about TLS handling in WebKit2

[Marco Peereboom]

On Thu, Jul 05, 2012 at 12:23:11PM +0200, Carlos Garcia Campos wrote:
> 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.

This would be fantastic!

I'd love to see this go in instead of jumping through the hoops we jump
through now.

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



> _______________________________________________
> webkit-gtk mailing list
> webkit-gtk at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk