Holes discovered in SSL certificate validation

Posted Nov 2, 2012 12:25 UTC (Fri) by pflugstad (subscriber, #224)
In reply to: Holes discovered in SSL certificate validation by zmower
Parent article: Holes discovered in SSL certificate validation

Having seen some of the Ada code that makes up a flight management system (not controls, but still responsible for important stuff like flight speed indicators and other displays), I can easily say that it was as bad as any other language. Ada may be strongly typed, but that doesn't make bad programmers any better. And bad programmers create bad code in ANY language.

to post comments

Holes discovered in SSL certificate validation

Posted Nov 3, 2012 10:26 UTC (Sat) by brouhaha (subscriber, #1698) [Link]

Certainly it's possible to write bad code in any language, and that's what usually happens. (Consequence of Sturgeon's Law?) However, that doesn't mean that choosing a language with better semantics (such as strong typing) won't dramatically reduce the occurrence of certain kinds of bugs.

IMHO, C doesn't even qualify as a high-level language. C++ perhaps does, but being nearly a superset of C, has basically all of the problems of C, plus some new ones. Javascript... don't even get me started on that one.

I was an Ada enthusiast many years ago, but haven't kept up with it because there's so little paying Ada work available. If I could find the time, I'd like to learn Scala. However, the work I can find is almost entirely C, C++, and Java.

Holes discovered in SSL certificate validation

Posted Nov 3, 2012 21:36 UTC (Sat) by dvdeug (subscriber, #10998) [Link] (2 responses)

I get the feeling that some drivers drive around cars that don't have mirrors; I mean, a bad driver can crash any car, so why do you need these things that make it easier not to crash the car?

Holes discovered in SSL certificate validation

Posted Nov 4, 2012 0:48 UTC (Sun) by pflugstad (subscriber, #224) [Link] (1 responses)

Just to be clear, I like strong typing as much as the next guy. I think it's one of the primary ways to show how you expect various types of variables to be used, which is one of the primary ways you reduce bugs.

But I've seen BAD Ada code - in safety serious situations. I've also seen really bad C & C++ code, where *attempting* to make the code strongly typed actually made the code worse. For example:

if ( classInstance == MANIFEST_CONSTANT )

the classInstance had an int operator(), so the compiler implicitly called that, and everything was fine. But because lint complained about different types, we ended up with:

if ( classInstance == (ClassType)MANIFEST_CONSTANT )

This instantiated a new instance of ClassType on the stack and then invoked operator==. This happened in 100's of places. And it even worked - until it ran out of stack. This was actually fairly painful to track down.

So - a fool with a (bad) tool is the main lesson here, but the tool is attempting to enforce strong typing, and the programmer blindly followed it.

I've seen similar stupidities in Ada code, so it doesn't save you any.

My point (I think) is that bad programmers easily trump strongly typed languages. It *might* lesson the problem - marginally. But in my experience, you OFTEN get the kind of stupidity I describe above, especially when development processes BLINDLY mandate running lint on your code and fixing all the warnings.

So I don't look to strongly typed languages as any kind of panacea. You can type silly things like converting a boolean to a 1 even there. You want good code: hire good, experienced programmers, and make them test their code.

On topic: I've tried to program against SSL's APIs. I totally agree with the article - they are HORRIFIC and I was just trying to do something trivial, nothing difficult like certificate verification.

Holes discovered in SSL certificate validation

Posted Nov 4, 2012 17:20 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

> But I've seen BAD Ada code - in safety serious situations. I've also seen really bad C & C++ code, where *attempting* to make the code strongly typed actually made the code worse. For example:

This is just an instance of fast-and-loose type casting (which is one of the major problems with languages like PHP and JS) in C++, so I don't think your example is saying anything spectacular about C or C++. Same sheep, different wool.

> So I don't look to strongly typed languages as any kind of panacea. You can type silly things like converting a boolean to a 1 even there.

They're not a panacea, but they certain do help. At least in Haskell, such things either involve "unsafe" in the function name or start putting the IO monad all through your code. Those are both things I stand out as "something fishy" to me. That casting in the example would be a red flag for me as well. Casting constants, especially if it's an enum (and you're not in some dark corner of the project dealing with marshalling between languages or the network) is a pretty bad code smell.

> You want good code: hire good, experienced programmers, and make them test their code.

Agreed.