GNOME Bugzilla – Bug 690176
SOUP_STATUS_SSL_FAILED doesn't provide GTls certificate
Last modified: 2013-01-10 15:25:57 UTC
When I enable: SOUP_SESSION_SSL_USE_SYSTEM_CA_FILE, TRUE, on a session and I try to connect to a server with https, but the server uses certificate which is not trusted, like a self-signed certificate, then I get status: SOUP_STATUS_SSL_FAILED but the soup_message_get_https_status() fails, while I would expect having those set, because I want to ask user whether he/she is fine with the certificate and hence I can continue with disabled SOUP_SESSION_SSL_USE_SYSTEM_CA_FILE, FALSE, to connect to the server. Ideally, the SoupMessage/SoupSession should provide a signal for certificate trust prompt, but there are some issues about blocking in GTlsConnection::accept-certificate signal, which may or may not be an issue. Nonetheless, having available certificate and certificate error after receiving SOUP_STATUS_SSL_FAILED is crucial to be able to prompt user for his/her decision. I see the soup_message_set_https_status() being called, but (see comment #1 and comment #2)
for async session it's called as below, with NULL connection:
+ Trace 231293
and with sync it's called here, but the connection's 'sock' is NULL, thus no luck either:
+ Trace 231294
hm... I thought libsoup's tests/ssl-test was ensuring that this worked, but I guess it only makes sure that it works in the success case. Anyway, the way epiphany deals with this (ie, what you can do right now without waiting for a bugfix) is to set "ssl-strict" to FALSE on the session. Then the session will accept all certificates, but tls-errors will still be set on the messages with certificates it doesn't like, so you can call soup_message_get_https_status() on each https response before you actually use the data (eg, from a got-headers handler, or just from notify::tls-certificate), and decide whether or not to accept it. (In reply to comment #0) > Ideally, the SoupMessage/SoupSession should provide a > signal for certificate trust prompt, but there are some issues about > blocking in GTlsConnection::accept-certificate signal, which may or may > not be an issue. As of GNOME 3.6, TLS handshakes always happen in another thread, which was step 1 in addressing the blocking problem. The eventual fix we're slowly moving toward will probably involve extending GTlsInteraction to deal with this case, and then letting you set a GTlsInteraction on the session.
(In reply to comment #3) > Anyway, the way epiphany deals with this... It sounds like it's too late for security, especially when you already sent your credentials to the site.
notify::tls-certificate will be emitted immediately after the handshake, before anything HTTP-level is written, and if you soup_session_cancel_message() from there, then nothing should get written. But yeah, someday there'll be nicer APIs.
I just tried it, and even the SoupMessage's notify::tls-certificate is called, it is never called with filled tls-certificate and tls-errors, in case of an SSL handshake failed error.
Oops, I'm sorry, comment #6 with libsoup-2.40.2-1.fc18.x86_64
OK, fixed in master. (In reply to comment #0) > fails, while I would expect having those set, because I want to ask user > whether he/she is fine with the certificate and hence I can continue with > disabled > SOUP_SESSION_SSL_USE_SYSTEM_CA_FILE, FALSE, > to connect to the server. I was going to say that this wouldn't work, because any persistent connections would still use the old value. But I guess you won't have any persistent connections to this host since they'll have failed with SSL errors, right? So it should work. (Or if not, just do a soup_session_abort() after changing it to close all the old connections.) Also, it would be better to do SOUP_SESSION_SSL_STRICT, FALSE, which is more semantically in-line with what you mean. The fact that having no CA file means "accept everything" rather than "accept nothing" is a historical mistake.
Thanks for the fix. Is the change backportable to stable? I'd like to use it as soon as possible, and it's a pita to depend on a development release of a dependency package (the evo projects usually use to depend on stable releases, to make life of the users/compilers easier). By the way, I guess this is about these two commits: http://git.gnome.org/browse/libsoup/commit/?id=c2ce0f99c1551161f http://git.gnome.org/browse/libsoup/commit/?id=645d0943d61885d71
Never mind, I tried to apply it to stable, but it didn't work, the sources changed too much. I'll do some version checking in evolution/evolution-data-server for libsoup which supports this, aka for 2.41.3.
(In reply to comment #10) > Never mind, I tried to apply it to stable, but it didn't work, the sources > changed too much. I've committed a 2.40-equivalent version of this patch (as well as bug 691399's) to the gnome-3-6 branch. "make check" passes, but further sanity-checking before Monday would be appreciated. (Actually, I guess there's no particular reason I have to put the 2.40.3 release out on Monday, but that's the current plan anyway.)
Thanks, I appreciate it. Both things work with gnome-3-6 branch at commit 8c0dd43. I'll use this libsoup until the release, and report any regression I would notice.