Using certificates for SSH authentication [LWN.net]

Using certificates for SSH authentication

Posted Nov 8, 2022 22:41 UTC (Tue) by ras (subscriber, #33059)
In reply to: Using certificates for SSH authentication by jonesmz
Parent article: Using certificates for SSH authentication

> There is a patch series to make OpenSSH support x509 certificates, which is available easily on distros like Gentoo.

I'm curious, what is the motivation?

I've struggled for literally days to create x509 certificates that some application (like OpenVPN, or IPSec) will accept. Maybe parsing asn.1 is hard as mjg59 says, but I've had to do it ISO 7816 card and, well, at the end of the day it's just a binary format. It never caused me a real world issue when using x509.

It was the complexity of x509 itself and it myriad of options that cause the issues. You have mind read useless error messages, and go on whumpus hunts for OID's that no one has every heard of to set options or flags some programmer apparently decided was necessary. Yet as far as I could tell, I could tell those options had no effect whatsoever on security. For example flags like "may be used to sign other certificates" may be useful for x509 PKI, but are of no use whatsoever outside of it - yet applications will insist on them being set one way or the other. Trying to get two ends of a IPSec connection to agree on what was a valid x509 cert sometimes seemed like it would be impossible.

After dealing with that, the simplicity of "just give me a raw key pair please" that ssh and wireguard employ is a breath of fresh air. The only reason I could think of for using x509 is you wanted to plug into the existing CA / PKI system.

Using certificates for SSH authentication

Posted Nov 10, 2022 14:27 UTC (Thu) by esemwy (guest, #83963) [Link] (1 responses)

It’s more that the complexity of ASN.1 makes it prone to exploitable bugs in individual implementations. Even mature libraries are regularly patched for common vulnerabilities.

Using certificates for SSH authentication

Posted Nov 10, 2022 21:28 UTC (Thu) by ras (subscriber, #33059) [Link]

There have been vulnerabilities. But I struggle with the "complex" bit. Its just a TLV encoding, which man + dog uses everywhere. There is a some bit twiddling involved. I guess that's because it harks from an era when bits were a precious commodity. But the twiddling is no worse than UTF-8.

The one criticism you can make of it is all that bit twiddling makes decoding slow for a binary format. It's still far faster than JSON.

My problems with ASN.1 have never been due to the format itself. It's simple enough, yet can describe complex data structures with ease. The issue has always been that ISO in particular seems has never been a "less is more" style of place. Their idea of compromise seems to be to accept and every idea into the standard, provided the ideas sponsor throws enough money and man power at them. The problem with ASN.1 is it allows them to get away with that. Which I guess is why they use ASN.1 a lot. Which in turn means as soon as I see something is using ASN.1 I shudder. But not because of ASN.1 itself. It's because the thing it encodes will be a behemoth, with a million different knobs, all of which have to be in exactly the right place for it to work. The icing on the cake is ISO will want to charge you for the document that documents those knobs.