Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple's SSL/TLS bug

imperialviolet.org

Post reply on HN
Print view View original

21–30 of 295 posts

Re: Apple's SSL/TLS bug

#21

Post by 0x0 »

rdl wrote: post #8

It's interesting watching all the speculation about "was it a backdoor, or just a bug?" Lots of points in favor or against: 1) It's a huge compromise, and "open" to anyone to exploit, which would ultimately get caught and fixed faster. But it's also not targeting anything specific, so there's less of a signature of the attacker. 2) Incredibly simple, and thus a plausible mistake. 3) Hidden in plain sight I'd generall…

Why would you need to regenerate keys? How does mitm ssl attacks compromise keys?

Re: Apple's SSL/TLS bug

#22

Post by shurcooL »

badman_ting wrote: post #3

If blocks without curly braces ಠ_ಠ

Interesting that, if there was a source code formatting tool (like gofmt for go), it would've made the bug easier to spot because the 2nd goto would lose it's misleading indentation.

Re: Apple's SSL/TLS bug

#23

Post by apaprocki »

Worth noting that static analysis finds bugs like this immediately. TLS code seems like the perfect candidate to run through static analysis on every checkin. There are products such as Coverity and PVS-Studio that would have immediately flagged this and probably some open-source ones built around LLVM as well (unsure about this one, though). I personally use Coverity and have it hooked up in the same way everyone connects Travis CI.

Re: Apple's SSL/TLS bug

#24

Post by Pacabel »

danieljh wrote: post #18

Emerging tools such as gofmt and clang-format are able to automatically re-format your code based on the language rules rather than the human behind the monitor. Using those tools this specific category of issues should at least be visible in the formating diff. Interesting. Never thought about it that way before.

Those kinds of tools aren't new or emerging. The "indent" utility for C has been around for decades. I first remember using it on 4.3BSD, but it may have been around before that.

Re: Apple's SSL/TLS bug

#25

Post by rdl »

0x0 wrote: post #21
rdl wrote: post #8

It's interesting watching all the speculation about "was it a backdoor, or just a bug?" Lots of points in favor or against: 1) It's a huge compromise, and "open" to anyone to exploit, which would ultimately get caught and fixed faster. But it's also not targeting anything specific, so there's less of a signature of the attacker. 2) Incredibly simple, and thus a plausible mistake. 3) Hidden in plain sight I'd generall…

Why would you need to regenerate keys? How does mitm ssl attacks compromise keys?

Compromise system (via update mechanism or other things secured with SSL, VPN software clients, ...); use that to steal keys.

I don't believe I've been a victim, and most of the ways you'd exploit this would leave enough traces to be high-risk-of-detection, I think.

But, it's hard to prove a negative, so it's safer to act as if it had been compromised.

(I'm also updating keys anyway, so this is just a matter of waiting a day or two to do so.)

Re: Apple's SSL/TLS bug

#26

Post by taylodl »

Dijkstra always contended GOTOs were harmful!

In all seriousness it's unfortunate the C family of languages even allow this kind of bug - we've all been bitten by it at one time or another.

Re: Apple's SSL/TLS bug

#27

Post by [deleted] »

0x0 wrote: post #21
rdl wrote: post #8

It's interesting watching all the speculation about "was it a backdoor, or just a bug?" Lots of points in favor or against: 1) It's a huge compromise, and "open" to anyone to exploit, which would ultimately get caught and fixed faster. But it's also not targeting anything specific, so there's less of a signature of the attacker. 2) Incredibly simple, and thus a plausible mistake. 3) Hidden in plain sight I'd generall…

Why would you need to regenerate keys? How does mitm ssl attacks compromise keys?

[deleted]

Re: Apple's SSL/TLS bug

#29

Post by Aissen »

apaprocki wrote: post #23

Worth noting that static analysis finds bugs like this immediately. TLS code seems like the perfect candidate to run through static analysis on every checkin. There are products such as Coverity and PVS-Studio that would have immediately flagged this and probably some open-source ones built around LLVM as well (unsure about this one, though). I personally use Coverity and have it hooked up in the same way everyone co…

Regarding Adam Langley's comment about -Wall in gcc: -Wextra is what you want to have many more tests analysing your code. I wonder if this would have caught it.
Post reply on HN