• FristValidator (unregistered)

    private static bool ValidateFrist( object sender, System.Security.Cryptography.X509Certificates.X509Certificate certificate, System.Security.Cryptography.X509Certificates.X509Chain chain, System.Net.Security.SslPolicyErrors sslPolicyErrors) { return true; }

  • LCrawford (unregistered)

    private static bool ValidateFrist() { try { return true; } catch (ErrNotFrist) { return true; } }

    Really, the management at Laura's company didn't see the need to pay for one of those fancy "Certificate things".
  • WTFGuy (unregistered)

    If they have any kind of unit testing it probably only contains a test using a good certificate since it's hard to immediately buy an expired certificate. Besides, those cost money. So the stupid function passes its only unit test. "We're showing all green! Push to production!"

  • (nodebb) in reply to WTFGuy

    It's not hard to build an invalid certificate: just take a valid one and change a single bit.

  • Geoff (unregistered) in reply to WTFGuy

    Yes its hard probably impossible to buy and expired cert from a third party CA. Its not difficult to make one though with a few openssl commands. Really just testing with a self singed cert with fake CA you just made the server won't trust is probably sufficient. After all your tests need to cover the code you wrote. As long as your passing the work off to the platform certificate validation and not rolling your own, your tests only need to check that you are actually 1) doing that and 2) interpreting the result as valid and invalid correctly.

    For unit tests on something like ValidateServerCertificate it should be good enough to pass in a cert and chain that will pass all checks and cert that should fail any cert check. You don't and probably should not try to create tests for every permutation of why a cert might be invalid. Clearly they did not test this function at all or only checked with valid certs, which is a fail

  • Tom (unregistered)

    That's a pretty common piece of code. Typically you notice one day that your development server has an expired certificate, so you bypass the validation, and forget to re-enable it before pushing to production...

  • Andrew (unregistered) in reply to WTFGuy

    Use a self signed certificate. Those will throw all sorts of untrusted errors.

  • that other guy (unregistered)

    It was like someone was doing TDD and wanted the test to stop failing.

  • Zach (unregistered)

    this is a true wtf. A few months ago this website had an expired certificate, and then again more recently a link to a JavaScript file for unicorns had an expired certificate, so my browser was again telling me this site was unsafe

  • Kleyguerth (github) in reply to Zach

    That would never happen if your browser were developed by Laura's company!

  • Peter (unregistered)

    Hardly rises to the level of a WTF. I see this sort of thing all the time. Just do a google search for SSL connection error and you'll get posts beyond number where someone asks for help with "weird" certificate errors. And on each and every one, someone else "helpfully" explains how to turn off certificate validation.

  • Duston (unregistered)

    Been there and well...done that.

  • Raj (unregistered) in reply to WTFGuy

    You still pay for certs rather than use letsencrypt? Are you allergic to saving money?

  • siciac (unregistered) in reply to Peter

    The fact that large numbers of people are doing something stupid doesn't make this not stupid.

  • Mischa (unregistered)

    Letsencrypt requires an automated update mechanism. Unless the installation is bog standard, this usually involves some shell scripting, and certbot keeps making incompatible changes to their configuration. Sometimes paying for a cert makes up for the time not wasted.

  • Daniil S (google)

    I once solved a very very serious problem that affected hundreds of users.... by doing just that. Not proud of it. Not happy with it. But waiting 6 months (not joking, not exaggerating) for client to do what they had to do was not acceptable... by the client.

    Right now, our whole security is based on a bunch of tokens whose values are either hard to guess, too time consuming to guess, or protected by certificates we chose to trust based on preconfigured values somewhere deep inside the browser protected by an old rusted 'this way' sign with hungry tiger lurking nearby.

  • Quirkafleeg (unregistered)

    Hey someone has copied our code! Wait, ours is public, not private...

    Not always such a WTF, as the function in our code is required to talk to an ancient PBX data stream, which is only accessible from a static IP address on an internal network and only accepts HTTPS requests (very pre-REST). As, such extra logic for whether the PBX's (self-signed) certificate is valid is not required... ...especially as those PBX's stopped being made over 5 years ago...

  • LCrawford (unregistered) in reply to Raj

    This project started in 2013, in the pre-LetsEncrypt days. I'm guessing that with the validity check was removed and free LetsEncrypt became available, no one cared to go back and rework the project.

  • Karl Bielefeldt (github) in reply to Peter

    That's the thing, though. Most ssl libraries you have to proactively turn off validation. You shouldn't have to write your own code to do it.

  • Anon (unregistered) in reply to Karl Bielefeldt

    +1

    TRWTF is rolling your own method.

  • aaa (unregistered)

    It's purely functional too. Doesn't modify the global state nor its arguments.

  • medievalist (unregistered) in reply to Quirkafleeg

    If you can't replace the bad certs, you test for the actual (bad) certificate you know you should be receiving - thus validating it. A commonplace problem with an easy and commonplace solution.

  • Olivier (unregistered) in reply to WTFGuy

    It takes a little bit of work to build an expired certificate, but it is not hard: create your own self signed root CA, add it to your software, create a certificate with only one day duration, sign it with your own root CA, tomorrow you'll have an expired certificate.

    That way, you can also try to do a lot of manipulation on the certificate, creating ad-hoc certificates for each and every error case you want to test.

  • P (unregistered)

    Yes, this is not a WTF at all. In fact it has been a widely spread practice to explicitly specify not to validate SMTP server cert with

    client.ServerCertificateValidationCallback = (s, c, h, e) => true;

    because even if you explicitly set to not use SSL when creating the SmtpClient object, sometimes it fails the server cert check for no reasons. I've seen this with Office 365 SMTP server.

    TRWTF is writing such a simple function with so many characters. Why can't they just use (s, c, h, e) => true?

  • Loren Pechtel (google)

    I'm going to guess management wouldn't cough up for a real certificate while they were writing this.

  • Friedrice the Great (unregistered)

    My cheap little old phone could do text-only web browsing - until the manufacturer's own cert (burned into the non-updatable phone's ROM) expired. Now the browser announces that the cert expired and won't even start up.

    Great way to secure your browser.

    The browser also runs a very-limited subset of Javascript and the phone has neither Java nor Flash. I think this phone might just about be the only secure phone around for web browsing. ;)

  • WTFGuy (unregistered) in reply to Anon

    Ref Karl Bielefeldt & the immediately following Anon ...

    That code is .Net. Their API design for http doesn't have a simple settable bool property for "validate ssl or not". If you do nothing, then the API automatically and inevitably fully validates the cert against the machine's system- & user-level trusted certs, group policies, etc.

    If your use case needs any different behavior, either more restrictive or more permissive, the API demands that you write your own callback function and register it.

    Ref https://docs.microsoft.com/en-us/dotnet/api/system.net.http.webrequesthandler.servercertificatevalidationcallback?view=netframework-4.7.2#System_Net_Http_WebRequestHandler_ServerCertificateValidationCallback for one such endpoint in their API. There are several others using the same approach.

    The WTF in this case is them apparently needing to carve out a small exemption for some oddity unique to their environment (e.g. as in Daniil S' example) and choosing instead to lazily just throw all the doors to the castle wide open.

    It's unsurprising (but saddening) that plenty of end users think of security as simply an obstacle to productivity to be ignored or circumvented wherever & whenever possible.

    It's appalling to find that attitude in people who're paid to know better and paid to build secure-enough systems. But not surprising given the pitiful state of "professionalism" in our ranks and the pitiful state of "management" in our managers.

  • Simon (unregistered)

    Yeah, this kind of thing is pretty common... particularly for testing environments. But I've seen it done at least once in production code for semi-legitimate reasons... namely, a situation where for obscure technical reasons, we couldn't control the certificate trust store on our client, but where the server certificate couldn't be verified without importing an in-house CA certificate.

    Since this was all internal systems with no access from the internet, it was deemed acceptable to use TLS without verifying the certificates... they weren't concerned about MitM, just about making sure data couldn't easily be read by packet sniffing.

  • Paul (unregistered) in reply to Peter

    Not sure why you put helpful in quotes, because it is indeed often helpful. And as a system administrator I implore you, developers, to include an option to skip certificate checks, preferably on a per-server basis.

    I know what certificates are, I know what they are used for, I know what they protect against. What I don't know is how to replace certificates on bits and pieces of hardware where the supplier can't be bothered to release new firmware, can't be bothered to let me change the certificate myself, or doesn't really know what certificates are in the first place.

    In a perfect world I would be able to replace the certificate with something not using SHA-1, something within it's validity period, something with a matching CN/ SAN, something signed by a CA that is being trusted by the computer I'm running your software on...

    But we don't live in a perfect world, and an option to bypass certain checks (especially things that check if the clock of my computer is within a fairly arbitrary range) is often needed.

  • I dunno LOL ¯\(°_o)/¯ (unregistered)

    My favorite certificate expirations are the certificates burned into the disc images for OS X releases. Because of course that OS X 10.10 image is somehow less secure if you use it in 2015 than if you use it in 2014. Also, if you try to mount the image yourself (which is nested inside an app bundle), you will see that the error is an expired certificate, but if you try to boot from the disc and use the installer, it will merely tell you that there is "an error", and refuse to install.

    Expiring certificates are fine for something dynamic like a web site, but completely stupid for signing a static data image that gets pressed into a DVD-ROM.

  • jay (unregistered) in reply to I dunno LOL ¯\(°_o)/¯

    I always assumed that the purpose of expiration dates on certificates was so that the company that sold you the certificate could collect from you again when you get a new one.

  • (nodebb)

    Isn't that what certificate timestamping is for? The stuff that says "Hey, I certify this object was signed at a time the certificate was valid".

Leave a comment on “Certifiable Success”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article