Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

cs.utexas.edu

Post reply on HN
Print view View original

21–29 of 29 posts

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

#21

Post by tialaramex »

baby wrote: post #19
tialaramex wrote: post #18

Earlier quoted context omitted.

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.

> why use certificates If you can use plainkeys?

TLS is for use to connect arbitrary peers on the Internet, which means you're going to need a PKI. So that means certificates.

I don't happen to agree with Noise's philosophy about agility, but that's one of those things where we'd have to agree to disagree in the short term. In terms of replacing TLS, Noise just isn't in the picture at all.

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

#22

Post by Eun »

_visgean wrote: post #20
Crinus wrote: post #16

Earlier quoted context omitted.

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

What about local management software listening on some ip address? (e.g. routers?) There will never be a valid certificate for a local ip address.

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

#23

Post by baby »

tialaramex wrote: post #21
baby wrote: post #19

Earlier quoted context omitted.

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.

> why use certificates If you can use plainkeys? TLS is for use to connect arbitrary peers on the Internet, which means you're going to need a PKI. So that means certificates. I don't happen to agree with Noise's philosophy about agility, but that's one of those things where we'd have to agree to disagree in the short term. In terms of replacing TLS, Noise just isn't in the picture at all.

For browsers sure. But if you're not using a browser and you're using TLS it's just a bad idea.

You can do PKI with plainkeys. You definitely don't need the complexity or x509 certs.

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

#24

Post by tialaramex »

baby wrote: post #23
tialaramex wrote: post #21

Earlier quoted context omitted.

> why use certificates If you can use plainkeys? TLS is for use to connect arbitrary peers on the Internet, which means you're going to need a PKI. So that means certificates. I don't happen to agree with Noise's philosophy about agility, but that's one of those things where we'd have to agree to disagree in the short term. In terms of replacing TLS, Noise just isn't in the picture at all.

For browsers sure. But if you're not using a browser and you're using TLS it's just a bad idea. You can do PKI with plainkeys. You definitely don't need the complexity or x509 certs.

Nope. As I said, if you need a transport layer to connect arbitrary peers over the Internet, TLS is exactly what the doctor ordered and it already exists. Already studied, already got libraries that implement it, already got test frameworks, everything is in place. An alternative even if it was technically no worse (which isn't guaranteed) and available today (impossible) doesn't have those things.

> You can do PKI with plainkeys.

Nope. A PKI specifically involves the binding of keys to identity, that's what the certificates are for. You don't have to have X.509 (though I'll argue you might as well) but you need that binding.

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

#25

Post by tialaramex »

Eun wrote: post #22
_visgean wrote: post #20

Earlier quoted context omitted.

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

What about local management software listening on some ip address? (e.g. routers?) There will never be a valid certificate for a local ip address.

The device doesn't _need_ a certificate for a "local" (presumably RFC1918) IP address.

It needs a certificate for its name, and arranging to have a valid (by which I'm assuming you mean trusted in browsers) certificate for a name isn't hard. Sectigo and DigiCert both offer vendors a suitable product for that purpose last I checked. If you're making a short run hobby product you could just use Let's Encrypt.

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

#26

Post by Eun »

tialaramex wrote: post #25
Eun wrote: post #22

Earlier quoted context omitted.

What about local management software listening on some ip address? (e.g. routers?) There will never be a valid certificate for a local ip address.

The device doesn't _need_ a certificate for a "local" (presumably RFC1918) IP address. It needs a certificate for its name, and arranging to have a valid (by which I'm assuming you mean trusted in browsers) certificate for a name isn't hard. Sectigo and DigiCert both offer vendors a suitable product for that purpose last I checked. If you're making a short run hobby product you could just use Let's Encrypt.

In a typical consumer network every device is getting a (more/less) random ip address by dhcp. So there is no guarantee that the dns name will always point to the right ip address, therefore it is impossible to use a fixed dns name. This fact makes it impossible to get a valid certificate. Especially not from let’s encrypt.

In easy words: You use example.com for your IoT device. Where should example.com point to? To all possible ip addresses? I don’t think so...

Besides that you need a private key on the iot device for decrypting the tls traffic, imagine somebody gets access to the device and now can basically mitm all other devices...

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

#27

Post by waddlesplash »

tialaramex wrote: post #15
billpg wrote: post #11

bool ValidateCertificate(cert) { return true; }

https://github.com/haiku/haiku/blob/master/src/kits/network/...

This is the default implementation; our WebKit port (the main consumer of this API) has a subclass of this which shows a "this certificate is invalid, do you want to continue?" message and actually returns false.

But it's been multiple years since that comment was added, probably more than time to fix that. Thanks for the (inadvertent) reminder :)

EDIT: done. https://git.haiku-os.org/haiku/commit/?id=a830ec9a1c5f0e359b...

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

#28

Post by waddlesplash »

tialaramex wrote: post #9
ncmncm wrote: post #4

2012. It would not be surprising if most of the vulnerabilities cited are still there, though now likely harder to see.

Hostname verification got much better. It's default-on in a lot of common software these days where it might have been optional or even entirely broken back in 2012. People do struggle with IDNs. The key trick here is to understand that SANs are mandatory in the Web PKI and by definition they are in DNS's own internal A-label format ("punycode") because the character set used for SANs deliberately isn't Unicode capab…

> The obscure Haiku operating system is an example, they offer a "secure socket" abstraction but it doesn't implement hostname validation so in essence it's worthless

I just fixed this in https://git.haiku-os.org/haiku/commit/?id=8d63a9060e66aa69c0....

In the future, please actually report such problems on the bugtracker instead of just randomly shaming us on HN :p

Post reply on HN