PHP, Python and Google Go Fail To Detect Revoked TLS Certificates (softpedia.com) 64
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.
Re: (Score:1)
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 .
Re:News Flash: (Score:4, Insightful)
Sooo... (Score:2, Insightful)
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.
Re: (Score:3)
Re: (Score:1)
Or, more to the point this retarded summary ignores the fact that the article itself is about libraries supporting those languages.
And of course plenty of other libraries as well, and old versions of browsers, and a ton of other stuff.
In fact working TLS Certificate revocation (not the theory, the actual use) is a relatively new thing, so it is not that surprising that
there is plenty of infrastructure out there that either does not support it, or does it wrong. It is also not exactly simple.
Is it a bad thin
the tools should make this easier (Score:4, Insightful)
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.
Re: (Score:3, Informative)
The only problem with that is many of the CRL servers respond very slowly or not at all. For our customers, especially the ones using a GoDaddy cert, we had to disable CRL and OCSP checks in Java to make connecting to them reliable. For our PHP services, not checking those slow and unreliable lists made our services much faster and more reliable. Until companies like GoDaddy get their act together, I'm glad PHP doesn't check.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: the tools should make this easier (Score:1)
Libraries (Score:1, Troll)
Re: (Score:3)
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.
Re: (Score:3)
Re: (Score:1)
Maybe we need a new term for it all. "Language kit"?
And the problem is??? (Score:5, Insightful)
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: (Score:2)
I agree with most of that, but
if an application is currently connecting to a host with a revoked certificate... maybe it should break?
Re: (Score:2)
The developers should indeed make the program check the certificate IF they deem it necessary. OCSP/CRL's are only useful when SSL is used to authenticate a host, not just to encrypt. SSL IMHO should not be used for authentication in the first place, that's not what the protocol was designed for, we have Kerberos and other encrypted methods of authentication over unsafe channels.
To make outgoing calls just to check OCSP/CRL's which incurs a lot of extra time and resources for every call (although there is s
Re: (Score:3)
There have been good stories about this, like here: http://news.netcraft.com/archi... [netcraft.com]
curl | sh (Score:1)
Can we stop it already?
Cert revokation is terminally broken. Wontfix. (Score:5, Informative)
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.
Re: (Score:1)
OCSP Stapling, and specifically Must-Staple, which is now RFC 7633, mean we can have revocation that actually works one day, perhaps soon. Here's how:
1. When the certificate is issued RFC 7633 is used to assert that this certificate is "Must-Staple" which means it is only valid when accompanied by a stapled OCSP response for the certificate.
2. The web server (or whatever else is doing TLS) on start-up and then periodically (say, once per hour) goes to fetch an OCSP response about its own certificate. If tha
wget? (Score:1)
what about zoidberg?
Requests (Score:2)
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 [python-requests.org], although it doesn't mention revocation specifically.
Re: (Score:3)
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.
Revocation (Score:1)
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.
Re: Revocation (Score:1)
Java does, and it's a pain in the ass sometimes.
Not a suprise (Score:1)
PHP is utter dog shit developed by clueless dumbfucks.
Python is slightly better than utter dog shit.
Google is flat out incompetent.
Main reason (Score:1)
Apples and oranges (Score:1)
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
Re: (Score:2)
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.
And by doing so you have introduced an effective DOS vulnerability ( even if human based ) because you are asking people to make decisions to not trust a certificate based on communication over channels with poor authentication and integrity controls.
Re: (Score:2)
IIRC it is either the http wrappers for the various file functions (file_get_contents, etc) or cURL in PHP that needs a special argument for a self-signed certificate, and it throws an error if you don't use the argument. Wouldn't something similar work for a revoked certificate? Assuming the back end code was updated to do the revocation check?
"the owner" (Score:1)
"revoked by the owner" Who's that, I wonder?
State and the Hot Potato (Score:2)
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 someth
Who Cares ? (Score:1)
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
uh, yeah. You just noticed that? (Score:1)