PHP, Python and Google Go Fail To Detect Revoked TLS Certificates (softpedia.com)

An anonymous reader writes: Four years after the release of a groundbreaking study on the state of SSL/TLS certificates in non-browser applications (APIs [to be exact]), some programming languages fail to provide developers with the appropriate tools to validate certificates. Using three simple test scripts connected to a list of known vulnerable HTTPS servers, researchers logged their results to see which programming languages detected any problems. According to the results, all tested programming languages (PHP, Python, Go), in various configurations, failed to detect HTTPS connections that used revoked SSL/TLS certificates. This is a problem for HTTPS-protected APIs since users aren't visually warned, like in browsers, that they're on an insecure connection. "PHP, Python, and Google Go perform no revocation checks by default, neither does the cURL library. If the certificate was compromised and revoked by the owner, you will never know about it," noted Sucuri's Peter Kankowski.

Comments

Sooo...

[ADRA]

I don't use any of these programming languages. Maybe a little more exhaustive list of working / no-working languages and libraries would be a great resource.

the tools should make this easier

[WatchMaster]

in java at least, it is quite a project to properly validate a chain of certificates to a root with full support for the several types of certificates. These libraries should provide a simple binary function that can validate a certificate, including revocation. That is - this is an area where experts in this subject should provide standard libraries. Much like one should be wary of writing your own encryption, one should be wary of writing certificate validation code without the required expertise.

And the problem is???

[guruevi]

TLS/SSL certificate revocation has historically never been and still isn't very robust. It's been around for decades, I remember trying to work with Verisign (I think they're still around although their certificates were awfully expensive) in the early 2000's when CRL's were introduced and more down than up and they didn't think it was very important, I simply ignored it then since most CRL servers either didn't exist, didn't work or were overloaded.

In API's the certificates that may be accepted are typically well defined where any random certificate on the other side just won't work, valid or not. I know PHP, Python and Perl allow/require you to define a certificate store where trusted certs live and it is relatively well documented not to use the systems' store unless you trust all the root certificates in it.

In addition, you can't just change a commonly used API like cURL and suddenly require things that were previously not required for no good reason. It's the same reason SSL libraries support(ed) old versions of SSL that were dead decades ago (RC4, SSLv2/v3) until an actual protocol flaw comes up.

TLDR: It's not a problem for anyone knowledgeable of the situation, API's don't just connect to random sites on the Internet and trust their data (or shouldn't) and those that do should be using the built-in features to check OCSP/CRL's.

Re:News Flash:

[TheRaven64]

If you hit your thumb with a hammer, then it's your fault. If you cut your hand with a hammer designed by someone who thinks that razor blades are an ideal decoration to hammer handles, then it's probably the tool's fault. It's not the fault of the language, but it is the fault of whatever library you are using to handle the SSL connections if the simplest and recommended use of a library designed to establish a secure connection does not, in fact, establish a secure connection (or, at least, provide an easy-to-check error condition if it has failed to do so). If the language bundles this library as part of the standard library, then it's definitely a problem with the language.