Posted on by Michael Catanzaro

Reminder: SoupSessionSync and SoupSessionAsync default to no TLS certificate verification

This is a public service announcement! The modern SoupSession class is secure by default, but the older, deprecated SoupSessionSync and SoupSessionAsync subclasses of SoupSession are not. If your code uses SoupSessionSync or SoupSessionAsync and does not set SoupSession:tls-database, SoupSession:ssl-use-system-ca-file, or SoupSession:ssl-ca-file, then you get no TLS certificate verification. This is almost always worth requesting a CVE.

SoupSessionSync and SoupSessionAsync have both been deprecated since libsoup 2.42 was released back in 2013, so surely they are no longer commonly used, right? Right? Of course not, so please check your applications and make sure they’re actually doing TLS certificate verification. Thanks!

Update: we decided to change this behavior.

8 Replies to “Reminder: SoupSessionSync and SoupSessionAsync default to no TLS certificate verification”

  1. Uhm, yes, this is worth a CVE. Would you please go ahead and file one? There is some automation setup by the guys from the opensource security podcast at https://iwantacve.org, that should make it trivial to file a CVE for this.

    This has to be made known to people using this library. I would do it myself, but I’m actually not familiar enough with the code base to verify it myself

    1. I’m planning to request separate CVEs for several different projects that I’ve identified as affected, after allowing some time for maintainers to assess my reports.

      I’m not planning to request a CVE for libsoup itself. A CVE wouldn’t be very useful since it won’t result in behavior changes: the lack of certificate verification is a documented API guarantee, not a bug. libsoup was created 20 years ago and while this would be wildly unacceptable today, it wasn’t back then. The affected APIs have been deprecated for eight years now, and are removed in libsoup3.

      1. Please file one for libsoup, simply because it’s something that dependency scanners can pick up then.

        It’s a regular case of CWE-295 and that should be pointed out. A CVE doesn’t automatically require a patch to fix it, but spreads the awareness beyond projects you are aware of.

  2. Thank you for this blog post, I had no idea! gtimelog is affected, since I merged a PR making use of Soap.SessionAsync a while ago and it never occurred to me to test whether it does HTTPS validation or not.

  3. How about dropping the API then? I know that API breaks are not nice, but software that hasn’t been updated to fix deprecations at least once in >7 years just asks to get broken, doesn’t it?

    If you don’t want to break ABI, how about hiding it behind a flag / environment variable (e.g. LIBSOUP_UNSAFE)? If this environment variable is not given, it could raise an error or warning and not do the HTTP request. Is there any other valid use case for not checking certificates than debug purposes?

Comments are closed.