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.
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.
Bye!
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.
Am I the only one who feels stupid reading this? I have used python extensively for this in the past and never once considered that it wouldn't throw some kind of exception if that were to occur.
CAPTCHA: goofed
This is a function of libraries, not languages. People are getting dumber in this industry.
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
Can we stop it already?
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.
what about zoidberg?
Security Now podcast covered how browsers don't always notify. Check yours at https://revoked.grc.com
For Python they used urllib and ssl which, yeah, are in the standard library, but Requests is kind of the de facto HTTP library. Requests does do SSL cert verification, although it doesn't mention revocation specifically.
At least Apache has OCSP support. I wonder how many things can do SCVP, though?
Oddly enough, the federal government does PKI far better than most private industries, at least those I interact with.
Isn't cert revocation done by os updates these days? You cannot expect a language to maintain it's own ca store. Though it would be excellent if it did, and validated automatically.
PHP is utter dog shit developed by clueless dumbfucks.
Python is slightly better than utter dog shit.
Google is flat out incompetent.
I think the main reason is that the software is useless if it cannot connect. So developers are forced to make clients which work first and then give options for "enabling" security. It is left up to the user to decide what level of security they want to use to connect. The servers and clients can easily decide as far as management is concerned if they want to implement strict security or not. So the main reason why some browsers do implement is because people want to be aware. Until major attacks do not occur, and customers do not care, then there is no real reason to implement stricter security. It costs developers time and makes the software unnecessarily complex. Also it runs the risk of not working which in some customer cases is not acceptable. So this issue shall be around for ever as long as people do not need security is applications running on secure and controlled networks. Technically SSL is rumoured to be breakable so only OTP could be considered for serious applications. Regards, Khawar Nehal
Firefox and other browsers robustly support revoked certificates, as they should.
I can personally speak about PHP. Although this language is hated by people who have to maintain poorly-written code by web designers who shouldn't be programming in the first place, it's actually a great language for experienced programmers who know what they're doing. I see that the only weakness cited for PHP is the lack of support for revoked certificates.
You would never write a general-purpose web browser in PHP. If you're doing B2B programming, as is typical with PHP, there is a known set of certificates and a known set of end points. You don't have to use programmatic channels to do certificate revocation. E-mail and trouble tickets will suffice to have the certificate replaced sufficiently quickly.
I haven't personally programmed in Python or Go but I would imagine the situation there is quite similar. You aren't writing a general purpose web browser that is connecting to arbitrary sites on the Internet. Instead you're mainly writing code to connect known end points with each other. Simply having a support mechanism for certificates would be adequate.
There really is no need to write complex code to handle this situation. As long as you can remove and replace a certificate with your software, then you're good to go. If your credentials are burned into read-only memory, then you have bigger problems than certificate revocation.
Another great reason to use Perl!
I just did a quick test of the bad server list from Sucuri, and the standard Perl module for making network connections (LWP) gives the following results:
"Can't connect to revoked.grc.com:443 (certificate status is revoked)"
"Can't connect to tv.eurosport.com:443 (hostname verification failed)"
"Can't connect to qvica1g3-e.quovadisglobal.com:443 (certificate verify failed)"
"Can't connect to self-signed.badssl.com:443 (certificate verify failed)"
request succeeds for rc4.badssl.com
"Can't connect to dh480.badssl.com:443 (alert handshake failure)"
It's not perfect, because it will still make a connection using RC4, but anybody using Perl is protected from revoked certificates which is by far the worse problem. I have just submitted a bug report about the RC4 problem, so hopefully that will be fixed soon.
At any rate, for those of you who have heard that "Perl is dead" you have heard wrong. It is alive and kicking, and being actively updated.
"revoked by the owner" Who's that, I wonder?
I suspect that most HTTP client implementations bundled with languages aim to be stateless by default. For anything that looks like state, the buck gets passed downstream. There is merit in this -- it gives the downstream developer a lot of flexibility. But then we have the problem: several standard HTTP behaviors that we usually take for granted are unworkable by default (i.e. HTTP cookies, HTTP caching, and CRL/OCSP -- which needs caching to perform reasonably).
Typically, a developer wants to say something simple (http.get("http://example.com/the/data")) rather than
cookieStore = new FileCookieStore("/var/lib/my-app-dir-that-someone-has-to-configure/cookies");
cacheStore = new FileCacheStore("/var/lib/my-app-dir-that-someone-has-to-configure/cache");
certValidator = new CachingCertificateValidator(cacheStore, {crl => true, ocsp => true});
httpClient = new HttpClient(cookieStore, cacheStore, certValidator);
httpClient.get('http://example.com/the/data');
Who wants to be responsible for administering/documenting/supporting all those fiddly bits of state?
I connect to a lot of endpoints published by orgs like government departments which use private certificates issued by private root authorities, oddly enough the original principle behind certificates applies; do I trust the issuer ? If I do then I manually accept the CA and the cert into my certificate store in order for my systems to trust the remote endpoint.
If all you are going to do is blindly accept certificates on the basis that they pass verification checks then you are doing it wrong.
I laugh when I see how many "trusted" root authorities there are and just how many of them are practically untraceable.
agree , it is not the task of a language to check for revoked certificates by default . The programmer need to do that , and if not done you cant fault the language .
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
IE seems frantic about sending requests to Microsoft for CRLs. A) No thanks on that telemetry thing, and B) Stop using my bandwidth stupidly. I filter them at the proxy.
It's not a failing in any of these languages. At worst its a missing feature in their standard libraries.
Also CRLs and the entire Cert system is full of fail and AIDS. Even if your language of choice has fantastic functions/classes, your entire stack grinds to a halt because the CRL server is just too busy/slow/crappy, or doesn't validate properly at all because their data is out of sync.
Don;t worry though, I'm 100% sure the NSA/CIA/FBI/TLA doesn't have copies of every major CAs master keys so you can totally trust them.
April fools!
Online Certificate Status Protocol. Java supports it just fine.
The encryption isn't all that useful if it's between you and a bad guy who is pretending to be the service you wanted to talk to...
He could even be nice and transparently proxy you through. Maybe just look at your private bits while they go by...
CRLs are poorly used and often ignored, largely because there is no simple built in standard for keeping the CRLs updated and having all connections check them. Its bad enough that our team has gone to only issuing certs with very short life spans and just renewing them often. See https://www.openstack.org/summ...