banner image
Sedang Dalam Perbaikan

Lessons of the heartbleed bug for open source software, \(P=NP\)

Two days ago, Neel Mehta of Google’s security team as well as a team of security engineers at Codenomicon have found a dangerous vulnerability of versions of OpenSSL – 1.0.1 and 1.0.2 beta – called the Heartbleed bug that allows the attacker to read pretty much any information from the vulnerable server (keys to encrypt and the actual user passwords and data) in 64-kilobyte packages. See Google News.

It means that the safe "HTTPS" actually makes things more insecure than the ordinary "HTTP".

About 17% servers allowing encryption are running the bad versions of OpenSSL. The most publicized server whose users should surely try to change the passwords as soon as possible (probably in the past) is Tumblr (owned by Yahoo, so probably Yahoo passwords may also be in danger). I really hope that it is really true that Dropbox, Gmail, Facebook etc. are unaffected; try this tool or this one to check the security of particular servers; Jesus Christ, it says that onedrive.live.com is vulnerable.




Just to be sure, "OpenSSL" means that it is an open-source (i.e. communist style or programming) implementation of the SSL protocol. Only the particular implementation of the SSL is at risk, not the paradigm of SSL itself.

SSL is the predecessor of TLS and sometimes, we talk about SSL/TLS. In practice, it's the layer that allows the exchange of information via the HTTPS protocol (HyperText Transfer Protocol Secure). This exchange is encrypted using (both public and symmetric) keys that are only known to the two sides of the communication, and the fancy technology based on hard-to-decrypt hypotheses in computational complexity (RSA...) preserves our belief that it can't be easily hacked.




I think that two groups of people should notice this dangerous bug: those who say that \(P=NP\) would make the world an entirely different place; and those who sell open-source software as a cure for all software illnesses.

The possibility that the cryptographic software may be hacked is the most visible "practical" implication of the scenario that \(P=NP\) – or stronger statements. It's widely believed that those encryption algorithms cannot be hacked in a reasonable time but there's really no proof. Well, even if the fast algorithms exist mathematically (i.e. if the likes of Scott Aaronson are completely wrong), it is very plausible that people won't find them for decades or centuries – or never. But if those methods would be hacked, people would be informed about the bug in a similar way as they are informed about the Heartbleed bug. The reasons would be fundamentally more interesting mathematically but the practical consequences would be similar as those today. A patch switching to a different kind of encoding would be issued and people would be invited to change their passwords etc. The percentage of servers affected would be closer to 99% than to 17% but the difference between 17 and 99 isn't really "qualitative".

Because the implementation of cool mathematical algorithms isn't guaranteed to be perfect, vulnerabilities exist even in the world where \(P\neq NP\) might hold. There are simply many easier tricks in the messy real world for hackers to illegally find some information than to prove (by direct aggressive action) that \(P=NP\), and perhaps stronger statements.

The second group that should notice is the movement defending the open-source software. We are often told that the open-source software must be so safe and secure because the source is, well, open and everyone can have a look and check things. But if everyone can look, it doesn't mean that everyone will look, and even if everyone looked, most people would be completely incapable of finding the vulnerability.

I actually think that the open-source software that doesn't have any particular "responsible people" is less secure than proprietary (closer source) software. The relationship between these two kinds of software is similar to the comparison of products produced by professional companies on one side; and do-it-yourself products on the other side. The second group may often be doing "pretty much the same thing" as the first group and be cheaper for the consumer. However, safety and security is likely to suffer because the non-professional creators spend a greater fraction of their working time by making sure that "it works at all" and a smaller fraction of their time by making sure that "it works flawlessly and securely".

At the end, the percentages of the software that is produced in the open-source and closed-source paradigms are given. We are not drowning in the sea of open-source software that would completely eliminate all closed-source software. And a smaller percentage of the work on open-source software is actually focusing on "checking things" because people are not as responsible for the problems and bugs as they are in commercial software companies producing proprietary software.

So I think that if the proprietary software has been a more frequent victim of attacks by hackers etc., it's just because many or most of these hacker attacks are done by leftists who prefer to attack software corporations over attacking open-source software. But if one looked at the intrinsic vulnerabilities – which are relevant for the hackers who actually want to harm others and help themselves, regardless of the author of the software they attack – the open-source software would probably end up being less secure than the proprietary one.
Lessons of the heartbleed bug for open source software, \(P=NP\) Lessons of the heartbleed bug for open source software, \(P=NP\) Reviewed by MCH on April 09, 2014 Rating: 5

No comments:

Powered by Blogger.