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@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk _______________________________________________ webkit-gtk mailing list webkit-gtk@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk