Apple's SSL/TLS Bug

2014-02-22 15:27:36 -0500

If you weren't already aware, Apple released iOS update 7.0.6 yesterday to patch a hole in their use of SSL/TLS that could allow an attacker to compromise encrypted communications. If you haven't updated your iOS devices you'll want to do so as soon as possible. A little bird tells me OS X updates are on the way next week, although I imagine that's no surprise and I've seen it speculated elsewhere.

There's a great explanation of the bug here by Adam Langley, but I'd like to point out an interesting comment by John Gruber on Daring Fireball where he links to Langley's post:

I don’t want to start a coding-style war, but I think this bug would not have happened if the code had been written using curly braces after the if statements.

I think there's no doubt about that. A little while ago I gave up my stubborn use of BSD-style in my C and Objective-C code and now wherever I see it I cringe a little and then go about fixing it up to be more "proper" in my mind. It's a nuisance, but worth it. For some time now, I think perhaps at the recommendation of Zed Shaw in his online book Learn C the Hard Way, I've been making sure to always use braces to encapsulate anything depending on an if statement or other conditional to avoid scenarios like the one that caused Apple's exploit. Other rules I now keep are no more braces on the next line, and avoiding blank lines. This gist should give a good example of what I mean, even though it's a bit silly:

I even use braces to encapsulate the branches of switch statements these days! I like to zap blank lines because I think it forces me to review code more closely; it's harder to skim and encourages me to keep things nice and DRY.

A minor aside: Learn C the Hard Way is really great even if you know C already. Worth a couple of hours, it's a fun read and good for tightening up your skills.

Update: I also avoid assignment operators in if statements, and I tend to keep conditional expressions very explicit. This way I know what in my code above, self.fugeez is a BOOL, or returns that type. If I want to check that a pointer is nil, then if (self.fugeez == nil), not if (self.fugeez). If I want to test that my BOOL fugeez is false, then if (self.fugeez == NO), an explicit comparison. Just makes it easier to see what's going on later. I'm not quite as religious about this, but I'm trying to stick to it and adjust where I see my old ways.

blog comments powered by Disqus