Validating SSL Certificates in Non-Browser Software (2012) [pdf]
1–10 of 29 posts
Re: Validating SSL Certificates in Non-Browser Software (2012) [pdf]
#2Re: Validating SSL Certificates in Non-Browser Software (2012) [pdf]
#3The most clickbait-y title in the world...
Re: Validating SSL Certificates in Non-Browser Software (2012) [pdf]
#4Re: Validating SSL Certificates in Non-Browser Software (2012) [pdf]
#5Re: Validating SSL Certificates in Non-Browser Software (2012) [pdf]
#6Papers that don't include dates on them are very irritating.
>CCS’12,October 16–18, 2012, Raleigh, North Carolina, USA.Copyright 2012
Re: Validating SSL Certificates in Non-Browser Software (2012) [pdf]
#7Reading this I’m fairly happy we do it mainly with C# at my place. All that configuration required in JAVA is simply crazy to me, why the hell would you want unsafe settings that aren’t disabled by default? You can turn them off in C#, opening yourself to the same vulnerabilities, but it’s an active and very obvious choice to do so. Though it’s likely been fixed in the 7 years that’s passed since this article.
I do wish we had a better system to identify IT-systems. When you operate more than a 1000 connections maintaining certificates that expire every 4 years becomes really fucking tedious. We’ve automated most of it, but some of it still requires hands-on, and we’re not perfect, I’ve seen project managers e-mail the private keys when someone bought a system around IT...
Re: Validating SSL Certificates in Non-Browser Software (2012) [pdf]
#8The most clickbait-y title in the world...
Re: Validating SSL Certificates in Non-Browser Software (2012) [pdf]
#92012. It would not be surprising if most of the vulnerabilities cited are still there, though now likely harder to see.
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 capable. You will need to know the A-labels in order to successfully resolve the hostname to get an IP address, so you can re-use those A-labels to match the SANs, and doing so will make your software work how programmers expect it to. You don't need the U-labels at all, they are only for display purposes. If you find yourself providing a separate "Hostname to verify" API distinct from the interface where you learn the name to connect to that's where you're going to trip yourself up, so don't.
But yes hostname checks are still embarrassingly missing in plenty of less obvious places if you go looking, they did not vanish entirely overnight. 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, yet it is used by their native web browser and other software.
Re: Validating SSL Certificates in Non-Browser Software (2012) [pdf]
#102012. It would not be surprising if most of the vulnerabilities cited are still there, though now likely harder to see.