Holes discovered in SSL certificate validation

Posted Nov 3, 2012 21:36 UTC (Sat) by dvdeug (subscriber, #10998)
In reply to: Holes discovered in SSL certificate validation by pflugstad
Parent article: Holes discovered in SSL certificate validation

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?

to post comments

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.