Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Java PHP Python Encryption Google Network Privacy Programming Security Software The Internet News Technology

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

Posted by BeauHD from the problematic-encounters-of-the-SSL/TLS-certificates-kind dept.
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.
This discussion has been archived. No new comments can be posted.

PHP, Python and Google Go Fail To Detect Revoked TLS Certificates More

PHP, Python and Google Go Fail To Detect Revoked TLS Certificates

Comments Filter:

  • Sooo... (Score:2, Insightful)

    by ADRA ( 37398 )

    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.

    • "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.

      • Re: (Score:1)

        by Anonymous Coward

        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)

    by WatchMaster ( 613677 ) on Thursday March 31, 2016 @09:10PM (#51820163)

    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)

      by Anonymous Coward

      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.

    • Not binary. I'm thinking of an asynchronous (because CRL servers can be slow) function that returns a status like "valid", "invalid", "self-signed", "expired", "revoked", "known-bad CA" or "request timed out". That way you can check for validity (result == CertificateCheckResult.Valid) but still react appropriately to specific issues, even if it's just to display the appropriate error message. Something like this (in pseudo-C#):

      Certificate foo; // magically appears from somewhere
      var result = await foo.Chec

  • This is a function of libraries, not languages. People are getting dumber in this industry.

    • 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 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.

  • And the problem is??? (Score:5, Insightful)

    by guruevi ( 827432 ) on Thursday March 31, 2016 @09:23PM (#51820201)

    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)

      by Sneftel ( 15416 )

      I agree with most of that, but

      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.

      if an application is currently connecting to a host with a revoked certificate... maybe it should break?

      • Re: (Score:2)

        by guruevi ( 827432 )

        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

    • There have been good stories about this, like here: http://news.netcraft.com/archi... [netcraft.com]

  • curl | sh (Score:1)

    by Anonymous Coward

    Can we stop it already?

  • Cert revokation is terminally broken. Wontfix. (Score:5, Informative)

    by Anonymous Coward on Thursday March 31, 2016 @09:29PM (#51820225)

    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)

      by Anonymous Coward

      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)

    by Anonymous Coward

    what about zoidberg?

  • 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.

    • 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)

    by Anonymous Coward

    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.

  • Not a suprise (Score:1)

    by Anonymous Coward

    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 o

  • 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)

      by DarkOx ( 621550 )

      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.

    • 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?

  • "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 someth

  • Who Cares ? (Score:1)

    by Anonymous Coward

    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

  • 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... [openstack.org]

Slashdot Top Deals

"The vast majority of successful major crimes against property are perpetrated by individuals abusing positions of trust." -- Lawrence Dalzell

Close