Live data from Hacker News

Apple's SSL/TLS bug

imperialviolet.org

181–190 of 295 posts

Re: Apple's SSL/TLS bug

#181
post #117

Earlier quoted context omitted.

> Indeed the only secure OS nowadays is Linux Tell that to the people who generated keys on Debian. Programmers are simply not good enough at writing secure code. Full stop. If you say anything else, you're just flaunting your own unreliability as a source of security advice.

At least that was public and fixed. I think the point is that keys could be completely deterministic on closed source systems and there is no way to know. It's very easy to have deterministic "random" sources that pass statistical tests for randomness.

Not true. IIRC, the way the Debian bug was found was by some parties noticing a bunch of collisions of SSH public keys.

(For example, Github lets you push/pull via SSH as git@github.com, and they determine your identity by the SSH key used.)

Re: Apple's SSL/TLS bug

#182
post #49

I just made this - it'll tell you if you're vulnerable. https://gotofail.com/ Not very well tested, please let me know if it works for you. If you're on OS X Mavericks or on iOS 7 and haven't patched you should get big scary red text. Edit: posted here https://news.ycombinator.com/item?id=7282164

"If you're on OS X Mavericks or on iOS 7 and haven't patched" how do I patch on OS X Mavericks? Software update shows nothing to update

> how do I patch on OS X Mavericks

Install Ubuntu.

I kid, I kid.

Re: Apple's SSL/TLS bug

#183

Earlier quoted context omitted.

I hate omitting braces, but Javascript semicolon omission is a totally different argument. It's easy to show simple cases where omitting braces causes problems. It's actually quite difficult and artificial to find cases where (especially with "use strict") semicolons confer any benefit at all, and in some cases they make things worse (e.g. multi-line variable declarations). Also, "correct" use of semicolons in Javasc…

I used to believe as you do that semicolon issues were contrived and unlikely in JavaScript. But over the years I've been bitten by it enough times to know better. IIFEs are the most common source of semicolon problems: for(i = 0; i A less common sort of pattern that I still use pretty often as a DRY measure: init() [x, y, z].forEach(function(a){ if(a.length > 5) { process(a) } }) This is clean and readable, and with…

Good examples actually. (Makes me feel better about my ingrained semicolon habit.)

Your examples will crash immediately and at the right spot though. The problems I see caused by excessive use of semicolons are often far weirder.

That said, inadvertent errors caused by semicolon insertion are still more common and baffling (especially by people addicted to jslint who use a variable declaration idiom particularly easy to screw up with errant semicolons).

Re: Apple's SSL/TLS bug

#184

Earlier quoted context omitted.

I hate omitting braces, but Javascript semicolon omission is a totally different argument. It's easy to show simple cases where omitting braces causes problems. It's actually quite difficult and artificial to find cases where (especially with "use strict") semicolons confer any benefit at all, and in some cases they make things worse (e.g. multi-line variable declarations). Also, "correct" use of semicolons in Javasc…

"It's actually quite difficult and artificial to find cases where (especially with "use strict") semicolons confer any benefit at all," Hence these are the cases where more time and resources will be wasted because of it. "I certainly see far more bugs caused by an improperly inserted semicolon" What would be an example of this? Because I've seen exactly zero bugs of this type (not counting typos, of course)

var a = 17, b = 13; c = 5;

(usually this will be across multiple lines)

...just overwrote c in a different scope. This kind of bug is common, idiomatic, baffling, and actually more likely among coders subscribing to javascript "best practices".

Re: Apple's SSL/TLS bug

#185

Earlier quoted context omitted.

If you have a programmer on your team who is likely to modify if (condition) { doSomething(); } into if (condition) { doSomething(); } { doAnotherThing(); } instead of if (condition) { doSomething(); doAnotherThing(); } then that person needs some serious mentoring right away. 'Cuz. . . just wow. As far as the original example goes, if it's an error it's most likely a copy/paste error. Curly braces help there, too. W…

As far as the original example goes, if it's an error it's most likely a copy/paste error. Right, and this demonstrates the major problem with verbosity in languages and APIs and design patterns. When you have to repeat yourself many times, it's very easy to make a mistake in one of the near-copies, and you or a code reviewer can miss it because you'll tend to quickly skim over the boilerplate. For cases like this, u…

Not possible in C, and I'm not even certain that high-level exceptions are desirable in a language like C.

But I wonder if there's still room to tighten up the code. Perhaps something like

  if (   (err = SSLHashSHA1.update(&hashCtx, &serverRandom) != 0)
      || (err = SSLHashSHA1.update(&hashCtx, &signedParams) != 0)
      || (err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0))
  {
     goto fail;
  }

Re: Apple's SSL/TLS bug

#186
Umm .. Code-coverage, Apple? That's the most scary aspect of this issue - that there is clear evidence that Apple aren't testing with coverage. At all. Or else this wouldn't have ever made it to release ..

Re: Apple's SSL/TLS bug

#187
post #181

Earlier quoted context omitted.

At least that was public and fixed. I think the point is that keys could be completely deterministic on closed source systems and there is no way to know. It's very easy to have deterministic "random" sources that pass statistical tests for randomness.

Not true. IIRC, the way the Debian bug was found was by some parties noticing a bunch of collisions of SSH public keys. (For example, Github lets you push/pull via SSH as git@github.com, and they determine your identity by the SSH key used.)

How is what I said not true? If the same thing as the Deb prng bug happened in a closed source system, it could sit for a couple of years exposing thousands/millions of systems and then be patched quietly to avoid embarrassment, leaving everyone vulnerable.

Re: Apple's SSL/TLS bug

#189

Earlier quoted context omitted.

"It's actually quite difficult and artificial to find cases where (especially with "use strict") semicolons confer any benefit at all," Hence these are the cases where more time and resources will be wasted because of it. "I certainly see far more bugs caused by an improperly inserted semicolon" What would be an example of this? Because I've seen exactly zero bugs of this type (not counting typos, of course)

var a = 17, b = 13; c = 5; (usually this will be across multiple lines) ...just overwrote c in a different scope. This kind of bug is common, idiomatic, baffling, and actually more likely among coders subscribing to javascript "best practices".

use strict? jshint / jslint your code?

This doesn't justify playing a guessing game and skipping semicolons just because you think you know all the rules about not using them.

Re: Apple's SSL/TLS bug

#190

Earlier quoted context omitted.

I used to believe as you do that semicolon issues were contrived and unlikely in JavaScript. But over the years I've been bitten by it enough times to know better. IIFEs are the most common source of semicolon problems: for(i = 0; i A less common sort of pattern that I still use pretty often as a DRY measure: init() [x, y, z].forEach(function(a){ if(a.length > 5) { process(a) } }) This is clean and readable, and with…

Good examples actually. (Makes me feel better about my ingrained semicolon habit.) Your examples will crash immediately and at the right spot though. The problems I see caused by excessive use of semicolons are often far weirder. That said, inadvertent errors caused by semicolon insertion are still more common and baffling (especially by people addicted to jslint who use a variable declaration idiom particularly easy…

The first example won't crash if the rvalue preceding the IIFE is a higher-order function (specifically, one that outputs a function).

A relatively rare scenario, but a brutal one to debug.

As for errors caused by extra semicolons, they can be weird, but I don't think I've ever actually hit one in practice. They'd also be a little easier to spot, since you tend to develop a reasonable instinct for where semicolons belong.

Post reply on HN