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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ webkit-gtk mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
