Hacker News new | ask | show | jobs
by pseudohadamard 5 days ago
This is what happens when kids today are unaware of history. This was a known problem 30+ years ago, and the Go kids have just rediscovered it for themselves. The most extreme case of this madness was imagining you could re-encode certificates into a DER blob from their stored components and the signature would still validate, something that OER (from memory) guys are now trying to do.

The rules for DNs are "there is only one encoding rule and that is memcpy(); there is only one matching rule and that is memcmp()". Given that Go has fallen into the decades-old trap of trying to re-encode strings, it's bound to be vulnerable to any number of other issues like evading excludedSubtrees through string-encoding tricks.

3 comments

Between this and the IPv6 zone identifier issue, it feels like there's a bit of a trend of commenters more or less assuming Go is doing the wrong thing when it's actually following the standards/best practices more correctly than average. I wonder where this reputation came from.
Most people accessing a site are likely not using Golang and are using Chrome. Thus Chrome is assumed right and Go is the one that's the outlier.
That's a different point, this particular thread is actually about a behavior that Chrome/OpenSSL/etc. have that is actually somewhat undesirable due to being complex and error prone.

Simply following Chrome/OpenSSL/etc. yields the best compatibility, but the Go behavior is much simpler in this very security critical path, and I'm not sure if it really occurs on the web. It seems most people are reporting it for other uses of X.509 like TPM. You can certainly see the argument in favor of Go's vastly simpler approach.

Go has a lot of trade-offs like this. If you can't decode from or encode into UTF-8 a given filename, Go's high level I/O APIs can't deal with it - depending on your exact point of view, the kinds of software you write and certainly some level of taste, you may see this as horrible, or you may see it as a totally reasonable trade-off. Some programs can go ahead and say "Sorry, we only support UTF-8 filenames" and some really can't.

But when being rational and reasoned it's really challenging to make the argument that Go's choices are bad due to inexperience from the language designers or standard library authors or general poor attention to detail. Calling the developers "Go kids" is already amusing considering it is very famously a project originally created by Rob Pike, Ken Thompson and Robert Griesemer - not foolish young developers who are likely to repeat mistakes of the past by way of ignorance. Of course, that doesn't mean say, the TLS stack, deserves to carry some special weight just because the language was designed by computer science stalwarts, but I've dug into the Go TLS stack a fair bit in my leisure and to me personally it definitely does not feel like the work of people who are ignorant or foolish.

I may be over-indexing on two recent comments here, but it does sort of feel like there's an undercurrent of this, and it bums me out because I particularly like Go for the exact opposite reason, I really think a lot of the tradeoffs, love them or hate them, are very well thought out.

edit: For posterity sake, it is worth noting that it was wrong for me to say "Chrome/OpenSSL/etc." as Chrome actually has a similar behavior to Go here.

From the article, it doesn't seem like Go is trying to re-encode strings? Go is saying (correctly, IMO) that a UTF8String field in the Issuer is not the same as a PrintableString field in the Subject.
Ah, you're right, I was a bit confused by the bouncing back and forth between Go and OpenSSL and the title, "Fooling Go's X.509" when in fact on re-read Go appears to be doing the right thing and using a strict compare while OpenSSL uses the open-to-manipulation compare.
Maybe this should be a lesson about the dangers of rolling in hot with a bunch of insults?
The Go "kids" are famous for, among other things, being industry leaders 30 years ago.
Those young whipper snappers with their lifetime of experience!
Them darn youngins[1]!

[1] Ken Thompson (over 80), Rob Pike (around 70), Robert Griesemer (over 60)