3 ms·

>And if you're speaking X.509 or something on both sides I'm intensely curious to see how vulnerable the attack surface is. Very. ASN.1 vulnerabilities have be

by q3k 8y ago

>And if you're speaking X.509 or something on both sides I'm intensely curious to see how vulnerable the attack surface is. Very. ASN.1 vulnerabilities have been exploited multiple times in the wild, in mainstream libraries (like OpenSSL). Now imagine every hardware vendor writes their own shitty implementation and ships it as a blob to phone manufacturers. And that's all without going into the full blown X.509 PKI part of the spec, which adds yet another layer of complexity - all under control of chargers you plug into. Now imagine this is implemented by the kind of companies who wish to perform DRM on what charger you are allowed to use. This spec is a recipe for disaster and implementing it will seriously reduce the security of devices.

wahern 8y ago
1) There's no practical alternative to X.509 for PKI because the standards, tooling, and libraries simply don't exist and arguably never will given the momentum of X.509. A PKI infrastructure won't even make it out the gate if it can't interoperate with the existing X.509-based CA ecosystem. 2) Historically you never wrote ad hoc parsers. ASN.1 describes a grammar to be consumed by a compiler generator. The X.509 specification and extensions are almost entirely ASN.1 grammars with interspersed commentary. You can feed those grammars directly into the generator, and IIRC I've seen builds where the grammars were extracted directly from the RFCs. OpenSSL and other open source projects suffered from parsing exploits because historically all ASN.1 compiler generators were closed source, commercial products. I don't disagree that it will likely be ugly. Open source options for properly working with ASN.1 are still poor, and these days even commercial vendors principally rely on open source toolchains. I've used the amazing asn1c which can be fed the official X.509 grammar and spit out a clean, strongly-typed BER, DER, or PER parser. But I've never seen it used by other open source projects. IIRC the mailing-list is mostly chatter from telecommunications contractors. Bad ASN.1 support doesn't need to be the case. Hand rolling DER parsers is a choice. If we can write good generators for gRPC, we can write them for ASN.1. And from the perspective of C and C++ asn1c largely suffices.[1] [1] My biggest grip with asn1c is that, IIRC, it still requires dynamic memory for grammars like X.509 with variably sized arrays and strings. It would be nice to see a compiler that supports generating statically sized fields and which simply errors out if an object doesn't fit within the field. Then you could use asn1c for really low-level, embedded firmware, and more importantly could greatly simplify application code traversing the data structures. ASN.1 supports specifying maximum sizes which could be used to size fields (and maybe are in asn1c) but that's a separate thing, and in any event X.509 doesn't make use of this (though I suppose it would be easy to amend the specification, formally or informally.)
- wahern 8y ago
  EDIT: s/compiler generator/parser generator/. Though, ASN.1 parser generators are also typically compiler generators, I guess, in the sense of generating code to "compile" data structures to the encoded form, which is probably what was going through my head when I muddled the terminology. The benefit of fixed-size, pointer-free structure fields in C is more pronounced when initializing a structure to be serialized.

by q3k 8y ago

wahern 8y ago

1) There's no practical alternative to X.509 for PKI because the standards, tooling, and libraries simply don't exist and arguably never will given the momentum of X.509. A PKI infrastructure won't even make it out the gate if it can't interoperate with the existing X.509-based CA ecosystem. 2) Historically you never wrote ad hoc parsers. ASN.1 describes a grammar to be consumed by a compiler generator. The X.509 specification and extensions are almost entirely ASN.1 grammars with interspersed commentary. You can feed those grammars directly into the generator, and IIRC I've seen builds where the grammars were extracted directly from the RFCs. OpenSSL and other open source projects suffered from parsing exploits because historically all ASN.1 compiler generators were closed source, commercial products. I don't disagree that it will likely be ugly. Open source options for properly working with ASN.1 are still poor, and these days even commercial vendors principally rely on open source toolchains. I've used the amazing asn1c which can be fed the official X.509 grammar and spit out a clean, strongly-typed BER, DER, or PER parser. But I've never seen it used by other open source projects. IIRC the mailing-list is mostly chatter from telecommunications contractors. Bad ASN.1 support doesn't need to be the case. Hand rolling DER parsers is a choice. If we can write good generators for gRPC, we can write them for ASN.1. And from the perspective of C and C++ asn1c largely suffices.[1] [1] My biggest grip with asn1c is that, IIRC, it still requires dynamic memory for grammars like X.509 with variably sized arrays and strings. It would be nice to see a compiler that supports generating statically sized fields and which simply errors out if an object doesn't fit within the field. Then you could use asn1c for really low-level, embedded firmware, and more importantly could greatly simplify application code traversing the data structures. ASN.1 supports specifying maximum sizes which could be used to size fields (and maybe are in asn1c) but that's a separate thing, and in any event X.509 doesn't make use of this (though I suppose it would be easy to amend the specification, formally or informally.)

wahern 8y ago
EDIT: s/compiler generator/parser generator/. Though, ASN.1 parser generators are also typically compiler generators, I guess, in the sense of generating code to "compile" data structures to the encoded form, which is probably what was going through my head when I muddled the terminology. The benefit of fixed-size, pointer-free structure fields in C is more pronounced when initializing a structure to be serialized.