GNOME Bugzilla – Bug 600447
Insecure default of not validating server certificates
Last modified: 2010-03-01 23:56:03 UTC
libsoup defaults to not validating server certificates, which obviously defeats the purpose of SSL/TLS. It should use the system's default CA certificate bundle, or if that's too difficult, refuse to do SSL/TLS at all unless the application (or user if bug 543455 is implemented) configures a CA file.
(In reply to comment #0) > It should use the system's default CA certificate bundle If you want to do that in your app, you can set the ssl-ca-file property on the session to point to that file. The problem is that libsoup has no API for handling fallback; if you set a CA file, and then a site fails to validate, then it just fails; there's no way to let the user override it and say connect anyway. And for most purposes, that's unfortunately not acceptable for the app; there are too many self-signed, expired, misnamed, etc certificates out there. (Of course, if you're writing something that only talks to a particular web server that you know has a good cert, then you might be able to get away with this.) I'd like to have better APIs, but it's never been a high enough priority for me to actually do it. In general, SSL/TLS is pretty broken security-wise anyway; if the app allows the user to override a bad cert then the user *always* will. :-/ But anyway, this will be fixed when GTlsSocket is finished (bug 588189) and libsoup moves to using that.
(In reply to comment #1) > (In reply to comment #0) > > It should use the system's default CA certificate bundle > > If you want to do that in your app, you can set the ssl-ca-file property on the > session to point to that file. The trouble is, GNOME applications (using the Evolution calendar and gvfs as an unrepresentative sample) don't do that; see, for example, bug 494418. Is it really easier to change all the applications than libsoup? > The problem is that libsoup has no API for > handling fallback; if you set a CA file, and then a site fails to validate, > then it just fails; there's no way to let the user override it and say connect > anyway. And for most purposes, that's unfortunately not acceptable for the app; > there are too many self-signed, expired, misnamed, etc certificates out there. What's unacceptable for me is having Evolution and gvfs risk compromise of my passwords and not even realizing it until I dug up the libsoup documentation and saw that (1) the default was not to check certificates and (2) Evolution and gvfs were not overriding that default. You speak as if SSL/TLS without certificate checking is a useful thing to do. I don't think so. See: http://www.gerv.net/security/self-signed-certs/ > In general, SSL/TLS is pretty broken security-wise anyway; > if the app allows the user to override a bad cert then the user *always* will. > :-/ That's not true: I know my mattmccutchen.net certificate is good, so if Evolution were to raise a "bad certificate" error when downloading my family's calendars, I would definitely cancel the connection. But aside from that, it's not appropriate for the app to make the decision of accepting a bad certificate for the user.
I guess the observation that it's annoying to just fail a connection without possibility of override deserves comparison to ssh's default behavior of accepting unknown host keys when running non-interactively. Then again, ssh lets users elect to preserve security at the cost of some annoyance by setting StrictHostKeyChecking, while libsoup has no such option.
> You speak as if SSL/TLS without certificate checking is a useful thing to do. It protects against passive attacks, but not against active attacks. However, for non-technical users, SSL/TLS *with* certificate checking does not really protect against active attacks either, because they will happily type their online banking password into www.i-am-not-really-your-bank.russian-mafia.com. > http://www.gerv.net/security/self-signed-certs/ Note that that was written for Firefox 3.0, and in 3.5 they made it easier for people to accept bad certificates again. Anyway, I suppose I should just commit bug 543455
(In reply to comment #4) > However, > for non-technical users, SSL/TLS *with* certificate checking does not really > protect against active attacks either, because they will happily type their > online banking password into www.i-am-not-really-your-bank.russian-mafia.com. Even if 99% of users are foolish like that, libsoup shouldn't impose foolishness on the remaining 1%. > Note that that was written for Firefox 3.0, and in 3.5 they made it easier for > people to accept bad certificates again. I'm not sure what you're referring to here. The only step they removed was clicking the "Get Certificate" button in the dialog. In both browsers, one has to expand a section of the error page (done automatically if browser.xul.error_pages.expert_bad_cert is enabled), click "Add Exception", and click "Confirm Security Exception".
(In reply to comment #4) > Anyway, I suppose I should just commit bug 543455 Please do. After a year and a half, I am still patching my copy of libsoup.