Slashdot Mirror
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.
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.
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.
Custom electronics and digital signage for your business: www.evcircuits.com
This is a function of libraries, not languages. People are getting dumber in this industry.
The article makes this clear and lists the libraries from these languages that were used in the testing. The IQ drop seems to be on the slashdot end.
'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
This is not something that should be held against the programming languages or their standard libraries. Cert revocation has never worked and will never work. All reasonable developers have given up on it. Trying to make it work is an exercise in futility and can only do more harm than good. That's why Let's Encrypt only issues very short lived certificates and plans to reduce the lifetime of certificates even more.
Oh, no, wait, I they did try Requests and it mostly passed EXCEPT for revocation. I simply checked the github repo that was posted and only saw the urllib/ssl test.
"Most languages do OK while these few aren't" isn't a news story. I think you don't understand how clicks on the internet work. Alarmism gets people to click, reporting facts doesn't.
Shutting down free speech with violence isn't fighting fascism. It IS fascism!
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.
I am TheRaven on Soylent News
The point is use a different library then if you need the functionality. It has nothing to do with "Python" or "PHP" or "Go". And if there isn't a library that does it for your language, then write your own librarary. Don't expect everyone to implement everything under the sun.