Live data from Hacker News

Validating SSL Certificates in Non-Browser Software (2012) [pdf]

cs.utexas.edu

11–20 of 29 posts

Re: Validating SSL Certificates in Non-Browser Software (2012) [pdf]

#13
Oh god, this is one of my biggest peeves.

SSL/TLS in anything that's not a browser is a total shit-show, and this is ignored by security professionals, ISVs, developers, and network architects alike.

As an example, take a look at something like a Citrix NetScaler, a popular network load balancer and security appliance (similar to an f5 BIGIP LTM):

Until recently, it was flat out unable to validate host names because like all network devices, it assumes that "IP address == the host".

Some dingbat put the "host name" part of the SSL validation into the SSL Profile. So you now have to make a separate profile for each and every host name, making this feature practically unusable.

By default it'll accept any certificate for a back end, signed by any CA. Or self-signed. Or whatever. 512 bits? No worries! It's a cert! It's good! We're SSL now!

Recently "server authentication" was added so you can actually validate the cert chain of a back-end service. Except for one minor flaw: it lets you pick exactly one signing certificate to validate against. So even if you know ahead of time that a back-end server is about to have its intermediate CA change, you're facing at least a temporary outage while you quickly switch out this parameter on the NetScaler.

For some retarded reason, the back-end and front-end SSL capabilities are wildly different. You read the manual and think: Yay, there's TLS 1.3 support now! Nope... front-end only.

The stupid things still generate 512-bit keys by default, and this can't be overridden for some scenarios, making them so insecure out of the box that Chrome refuses to talk to one.

Validating CRLs or OCSP is so difficult that I've never seen it set up on a NetScaler. I tried once and gave up.

Sure, you're keen. You want to validate CRLs and use OCSP like a good boy. Bzzt... chances are that some Security Troll has blocked outbound port 80 from the NetScaler because everybody knows that it's an "insecure protocol". So you're now facing a multi-month argument with a whole team of people convinced that you're trying to undermine their precious firewall rules.

There's no supported way of renewing a certificate automatically on one of these things, so of course, certificate expiry is like the #1 reason for outages in any NetScaler deployment.

Etc... it just goes on and on.

A lot of SSL/TLS design for network appliances was very obviously hacked in to support one scenario only, and anything else is going to be dangerously insecure. NetScaler was originally designed to do front-end SSL offload for HTTP-only servers in the same broadcast domain on a physically secured network. For any topology or scenario more complex than that it just falls apart and provides essentially zero protection against a MitM attack or anything similar.

Re: Validating SSL Certificates in Non-Browser Software (2012) [pdf]

#14
post #12

Often, unlike in a browser, there is no user to show a dialog to. "Cert is broken, Proceed: yes/no"

Those dialogs were a bad idea in browsers (and have been gradually going away) too. Never do this in new software.

Treat "Cert is broken" the exact same way you'd handle not being able to connect. Don't treat it as something you can just cross your fingers and ignore.

Re: Validating SSL Certificates in Non-Browser Software (2012) [pdf]

#16
post #12

Often, unlike in a browser, there is no user to show a dialog to. "Cert is broken, Proceed: yes/no"

Those dialogs were a bad idea in browsers (and have been gradually going away) too. Never do this in new software. Treat "Cert is broken" the exact same way you'd handle not being able to connect. Don't treat it as something you can just cross your fingers and ignore.

As a user i really dislike this because more often than not certs are broken because the server is temporarily badly configured (instead of some malicious reason) and i do not even care about it (or even if it was compromised really) as all i care about is read some page's content, connect to some messaging server (Pidgin often had issues with -IIRC- MSN servers), etc.

Of course if it is about, e.g., downloading some application (like an auto-upgrade mechanism) then sure treat it like that. But in other cases let the user decide, even if such sort of decision is made opt-in.

Re: Validating SSL Certificates in Non-Browser Software (2012) [pdf]

#18

And somehow, some people thought DNS over TLS was a smart thing to do.

Er, sure?

If you think the lesson here is "SSL/TLS is terrible, look at the bad implementations people have done" then you screwed up.

What's notable is that TLS is good enough that this even matters. Compare the situation with PGP and S/MIME. Instead of a list of bad examples, as a contrast to how it should be done, all you can say for those entire ecosystems is "Well, this is terrible, never do any of this".

The same story applies for the Web PKI. There have been a bunch of problems with the Web PKI over the years. But rather than "This PKI is terrible" the lesson is actually "This PKI is so good that it actually matters if things go wrong".

Re: Validating SSL Certificates in Non-Browser Software (2012) [pdf]

#19

And somehow, some people thought DNS over TLS was a smart thing to do.

Er, sure? If you think the lesson here is "SSL/TLS is terrible, look at the bad implementations people have done" then you screwed up. What's notable is that TLS is good enough that this even matters. Compare the situation with PGP and S/MIME. Instead of a list of bad examples, as a contrast to how it should be done, all you can say for those entire ecosystems is "Well, this is terrible, never do any of this". The sa…

I have to agree with Frank. TLS has proven itself to be extremely hard to implement or use correctly. And why use certificates If you can use plainkeys? There are other choices, like Noise.

Re: Validating SSL Certificates in Non-Browser Software (2012) [pdf]

#20
post #16

Earlier quoted context omitted.

Those dialogs were a bad idea in browsers (and have been gradually going away) too. Never do this in new software. Treat "Cert is broken" the exact same way you'd handle not being able to connect. Don't treat it as something you can just cross your fingers and ignore.

As a user i really dislike this because more often than not certs are broken because the server is temporarily badly configured (instead of some malicious reason) and i do not even care about it (or even if it was compromised really) as all i care about is read some page's content, connect to some messaging server (Pidgin often had issues with -IIRC- MSN servers), etc. Of course if it is about, e.g., downloading some…

but if there was no easy way to circumvent it, the website admin is much more inclined to fix it up...
Post reply on HN