Linked by Thom Holwerda on Tue 8th Apr 2014 22:06 UTC
Privacy, Security, Encryption

Heartbleed, a long-undiscovered bug in cryptographic software called OpenSSL that secures Web communications, may have left roughly two-thirds of the Web vulnerable to eavesdropping for the past two years. Heartbleed isn't your garden-variety vulnerability, so here's a quick guide to what it is, why it's so serious, and what you can do to keep your data safe.


Thread beginning with comment 586802
To read all comments associated with this story, please click here.
Maybe This Will Wake people up.
by oiaohm on Thu 10th Apr 2014 00:33 UTC
Member since:

Closed and Open Source SSL libraries have all had bugs of different levels of disaster.

We have acid tests for html. There is no vendor neutral tests for SSL.

Remember with the GNUTLS issue it was like go use openssl. Reality we do need more than 1 SSL library/solution. Bugs will come. Yes those anti-open source will forget this.

At some point we have to get serous about secuirty.

1) If there is not a validation suite it cannot be secure.

Reply Score: 2

BallmerKnowsBest Member since:

Closed and Open Source SSL libraries have all had bugs of different levels of disaster.
[...] Yes those anti-open source will forget this.

Maybe because it was a fairly forgettable issue that didn't have anywhere near the same impact as the OpenSSL flaw?

This security update resolves one publicly disclosed vulnerability and one privately reported vulnerability in the Secure Channel (SChannel) security package in Windows. The more severe of these vulnerabilities could allow remote code execution if a user visits a specially crafted Web site that is designed to exploit these vulnerabilities through an Internet Web browser. In all cases, however, an attacker would have no way to force users to visit these Web sites. Instead, an attacker would have to convince users to visit the Web site, typically by getting them to click a link in an e-mail message or in an Instant Messenger message that takes users to the attacker's Web site.


Not to mention being a flaw in the TLS/SSL protocol itself, rather than a flaw specific to Microsoft's implementation:

Edited 2014-04-10 02:46 UTC

Reply Parent Score: 3

oiaohm Member since:

BallmerKnowsBest read your own link. It details a flaw that does not come from protocol alone. No matter how badly you implement SChannel you should not end up with means to do remote code execution. If you can execute code you can request particular pages of memory. Microsoft had buffer overflow into executable space if you left protocol back in 2010. Should not have been possible if NX extensions and memory allocation in cpu had been used correctly.

MS10-049 is in fact for means to collect data worse than the current OpenSSL flaw. Current openssl flaw you get random blocks of data not exact data requests. The SChannel flaw in windows back in 2010 also worked in reverse from client to server. Luckily there are not many MS Windows servers on the internet.

Yes on scale of SSL screwups in implementations the current OpenSSL is not the worst that has happened. Heck even the Microsoft SChannel flaw is not the worst.

Yes you are right its was a flaw in the TLS/SSL protocol but Microsoft implementation managed to handle it worse than everyone else. Insanely worse.

The problem here is every SSL implementation closed or open has been having major issues. Still there is no unified test suite to confirm that a implementation is to standard. You will have some idiots come out and say its because of lack of professional management... Reality its more lack of conformance testing. Like most web browsers should not be SSL conforming because they don't check if SSL certificates are revoked or not.

Reason why SSL works is more good luck than management.

Are we going to wake up now and demard good management. I don't think would be a good idea to attempt to hold by breath waiting.

Reply Parent Score: 1