TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

My Heart Bleeds for OpenSSL

163 点作者 Tinned_Tuna大约 11 年前

19 条评论

tptacek大约 11 年前
<i>Depending on how deep we go, we could end up throwing everything away, the CA infrastructure, the cipher suite flexibility, the vast quantities of knowledge that surround the OpenSSL ecosystem and allow thousands of developers to work in a more secure manner than would otherwise be possible.</i><p><i>I want to cover the cipher suite flexibility quickly, just to point out how much of a fantastic idea it is. The server and client tell each other what their most-prefered ciphers are, then they agree on the strongest one that they both support.</i><p><i>This has massive benefits, for instance, when BEAST et. al. came along and effectively broke block cipher based OpenSSL for a while, we could jump to RC4 for a little while. When that was broke, we all hauled ass back to AES. This gives incredibly flexibility when dealing with many attacks, by simply being able to circumvent the affected parts.</i><p>This is frustrating.<p>All three of the major ciphersuite problems in SSL&#x2F;TLS (BEAST, RC4, Lucky13) were well-known in the literature prior to their discovery.<p>The BEAST vulnerability --- chaining IVs across messages instead of making them explicit and thus unpredictable --- was described years before BEAST was published, and was presaged by Phil Rogaway in discussions about IPSEC.<p>It is possible that RC4 was known to be vulnerable all the way from the moment it was leaked to Usenet. Certainly, the statistical biases were well-known. Not just apocryphally, but in the academic literature.<p>Lucky13 was a product of MAC-then-encrypt constructions, and an instance of a specific attack Vaudenay described in the early 2000s.<p>TLS has &quot;ciphersuite flexibility&quot; that has enabled the protocol to hop from one vulnerability to another. Meanwhile, fundamental fixes (either explicit encrypt-then-MAC, or AEAD modes like GCM, or secure native stream ciphers) have demanded fundamental protocol changes, not just new entries in a list of ciphersuites.
评论 #7557162 未加载
评论 #7557484 未加载
chomp大约 11 年前
This whole thing was totally mismanaged.<p>Cloudflare had 1 week&#x27;s notice from these codenomicon guys, and they patched it and stayed silent (NDA?).<p>Then the codenomicon came up with a fancy name, bought a domain that I&#x27;m guessing they paid a fair sum for (for publicity?) and publicized it without notifying anyone (Amazon? Yahoo?, any Linux distro?)<p>I mean, openssl.org&#x27;s own website was vulnerable until not too long ago.<p>I don&#x27;t appreciate having to build custom RPMs in the middle of the night because my distribution had no prior warning.<p>I really don&#x27;t appreciate this spectacle to advertise a security services firm.
评论 #7556993 未加载
评论 #7557238 未加载
Aqueous大约 11 年前
&quot;The only way to get that level of assurance would be to build an automated verification suite, or similar.&quot;<p>Wait.....what? OpenSSL doesn&#x27;t have an automated verification suite? What the?<p>Well there you go. That&#x27;s step #1.<p>I completely disagree with others&#x27; calls for a rewrite, and I really don&#x27;t like their attacks on OpenSSL developers (not that I know them or even know who they are.) How many of you have written software that has been tested as thoroughly in the real world as OpenSSL? Some, but not very many, I presume. OpenSSL has an installed base of billions and billions of machines, and it is mostly successful, and any software that sees that much use (and the corresponding scrutiny) is going to have vulnerabilities revealed. We should absolutely not, not, not rewrite the software and open ourselves up to whole new bugs, or worse, bugs that were in OpenSSL and patched years ago. It would be fine to start a <i>new</i> piece of software, with the hope of competing for SSL, but a widespread campaign to replace OpenSSL would be foolish.<p>The only possible caveat to this would be if it was developed more like clean room software a la NASA&#x27;s probe&#x2F;shuttle software, with every change agreed upon by a large committee of people, and no change made without weeks of planning. If it was replaced by a process so rigorous that it would not admit any bugs the new software might have a chance of competing with OpenSSL. And even then, a committee can&#x27;t think of everything.<p>Everyone is starting from the reference point of perfect security and yet perfect security is impossible. Literally the best you can do is to have software that has been subjected to attacks over and over and over again and though it may have been flawed it has also been patched.
评论 #7557304 未加载
dfc大约 11 年前
I would love to know the price tags, ballpark informed guesstimates, for the following:<p><pre><code> * Audit of openssl * Audit of openssl + remediation work * Brand new implementation of ssl library (100% feature parity not required)</code></pre>
评论 #7557827 未加载
评论 #7557844 未加载
jrochkind1大约 11 年前
Is OP intermingling discussion of OpenSSL (a particular codebaes implementation) from SSL&#x2F;TLS the protocol(s), in a confusing way? Or am I confused?
评论 #7557859 未加载
评论 #7558836 未加载
rdl大约 11 年前
If we could throw away CAs, cipher suite flexibility, ASN.1, general baroqueness, C, and the horrible cross-layer pain of SSL, I&#x27;d be fine with the hard incompatibility with legacy SSL.
评论 #7558068 未加载
jeffdavis大约 11 年前
I generally agree that rewrites are a bad idea. However:<p>1. Competition is good. Business, open source... doesn&#x27;t matter; some competition almost always leads to improvements.<p>2. Sometimes a rewrite can be justified when there&#x27;s a real difference of design behind it. For instance, using a different language with greater safety (type safety and&#x2F;or memory safety) might be the only way to get this to the level of security we expect.
评论 #7557710 未加载
ademarre大约 11 年前
The author seems to discuss OpenSSL as if it were the protocol itself, not an implementation of it. OpenSSL != SSL != TLS
jmspring大约 11 年前
This particular breach is very bad.<p>That said, for a piece of software as widely used as this, what is the actual count of vulnerabilities found?<p>I&#x27;ve spent quite a bit of time in the openssl code base for various projects over the years. I find it generally readable, but then I&#x27;ve seen some pretty odd ball C code over the years.
peterwwillis大约 11 年前
I wonder if this author is aware that OpenSSL was once born from a different project, called SSLeay, started way back in 1995. Abbreviated history lesson:<p>--<p>People today get pissed off because RSA got paid by the NSA to make crypto weaker, but try living in a time when RSA literally controlled the entire trade of tools used to run the web securely, and could just prevent anyone in the US from using SSL if they didn&#x27;t pay for it. It&#x27;s funny that actually all the people who originally worked on getting SSL created or its implementation into free software eventually worked for RSA. Ironically, back in the day NSA invested millions in a campaign to destroy RSA by offering its own competing cryptosystem as the new defacto standard.<p>SSL was basically created by Netscape through the work of Taher Elgamal, whose name you might recognize. In the 80s he created a variety of cryptosystems, many of which we still use today in a variety of applications. SSL was created with RSA&#x27;s cryptosystems and patented algorithms to provide the most security in the fastest way possible for web users. Since all of RSA&#x27;s algorithms were patented, nobody could implement them (for commercial purposes) without licensing it from RSA. Strong crypto (anything over 40 bits) was also still considered &#x27;munitions&#x27; and not allowed to be exported out of the country.<p>Back then there wasn&#x27;t a great big free unified toolkit of crypto libraries for anyone to use. The people who were writing crypto software either worked for a university, or a corporation, or a government, and thus all had the tendency to keep their source code to themselves, and code and libraries were licensed instead of given out freely. But a mini revolution had started from the ashes of the homebrew&#x2F;shareware communities. People started to create free software and give it away at no charge, there were people interested in making web servers and the like, and they could all share one standard library (for things like crypto) so they didn&#x27;t all have to implement one themselves for every project.<p>SSLeay was created in order to have a free implementation of SSL and its cryptographic algorithms that wouldn&#x27;t be subject to US export controls. This was reportedly a &quot;clean room&quot; implementation derived only from documentation, written from scratch by Eric Young in Australia in 1995. It was then used by Tim Hudson in America (amongst others) to add SSL support to basically every free application that could use it, like telnet, ftp, ncsa mosaic &amp; httpd, apache, w3c httpd, lynx, mSQL, etc. Both these men later went on to create commerial versions of this library and leave the work on SSLeay behind, and from that was born the OpenSSL project to continue where they left off.<p>At the time it was possible to create and run free software that provided SSL access. Actually, companies like Verisign - the only CA allowed by some browsers, for a while - had to make policy changes to start allowing certs to be generated for Apache-enabled SSL sites. But it was not <i>legal</i> to make free SSL-enabled software in the US because the right algorithms had not been licensed by RSA to use in the states. It also wasn&#x27;t legal to export any strong crypto from the country. You could only use things like Apache with SSL if you purchased a licensed add-on for use in the US, or applied a mod_ssl patch for use outside of the US.<p>Browsers were in a much worse boat [because they all depended on RSA if they wanted strong encryption] and thus were largely commercial ventures. When Netscape released its source code for the first time under the Mozilla label, all its strong crypto was removed to comply with US laws. A new project (Cryptozilla) had to be created to link SSLeay to the sources. It was then that the rest of the world could finally download a robust, modern, open-source browser with strong crypto.<p>All of this changed in 2000 when the RSA patents fell into the public domain and the US relaxed its export controls on crypto software. Right after that, Mozilla bundled its own RSA implementation in its NSS crypto library, and the rest (for Mozilla) had nothing to do with SSLeay or OpenSSL. But SSLeay (now OpenSSL) continued to be used by software all over the world.<p>--<p>There were a lot of different implementations of SSL&#x2F;TLS with varying degrees of compatibility bugs. Most of the time a web server was developed in tandem with a web browser (or other similar client&#x2F;server tools), and a library was created to implement the protocols they needed. This, of course, led to various problems between different implementations, even though if it was web code it was all using the same RSA toolkit for the relevant ciphers.<p>Even since those days in the mid-1990s, it&#x27;s been obvious that a single library to handle all the weird implementations is both difficult to implement and very useful to developers. It&#x27;s never been easy or bug-free. But even at the time, the library was written and re-written to get around things like export controls (the BSAFE SSL-C library was a rewritten version of SSLeay, by its original authors, so their new company could sell it as a non-US-based implementation of a US-patented algorithm).<p>Personally, I don&#x27;t think it&#x27;s offensive to the spirit of the original authors (or current developers) to suggest a fork or a rewrite. The main goals of OpenSSL are to have a free software implementation of SSL and TLS, and secondarily to provide a full-strength general-purpose cryptography library. It&#x27;s not some abominable, indecipherable, impossible task to re-accomplish this. Hell, it was originally done by one ozzie by himself with just docs for reference. I think maybe the entire open source community can handle organizing a do-over.<p>--<p>(Side note: does anyone else realize that the HTML &lt;keygen&gt; tag has been around since Netscape Navigator 3, and still nobody uses it?)
评论 #7559414 未加载
bbwharris大约 11 年前
Look at it this way. If it was closed source, the fix would take longer, and the realization may have never come.<p>Honestly, seems like we are forgetting our roots on this. Dump it? Yeah and throw out years of stability and bug fixes. No thanks!
评论 #7557480 未加载
pohl大约 11 年前
<i>rewriting is almost always a mistake</i><p>I&#x27;d make an exception for rewriting in a language that prioritizes safety towards the top...<p><a href="http://www.reddit.com/r/rust/comments/22gppc/when_life_hands_you_lemons_is_this_rusts_time_to/" rel="nofollow">http:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;rust&#x2F;comments&#x2F;22gppc&#x2F;when_life_hands...</a>
评论 #7557514 未加载
higherpurpose大约 11 年前
Actually, this post reinforced my belief that we should dump SSL and replace it with something better and safer. It&#x27;s just not worth the trouble at this point. The flexibility will arrive over the coming years, if there&#x27;s an alternative with a lot more enthusiasm and resources put into it.
评论 #7557147 未加载
thefreeman大约 11 年前
Someone with more knowledge please correct me if this is inaccurate, but from what I have been able to understand this basically exposed 16kb of random memory each heartbeat? So the fear would be that a persistent attacker I guess could continuously run this and scan the output trying to match things like security certificates?<p>While I am sure this could be used on high value targets with enough resources, as a small web service outside of the tech industry I feel pretty confident that no one would invest those kind of resources to steal our SSL cert. Is that misguided?
评论 #7557477 未加载
评论 #7557395 未加载
评论 #7557390 未加载
blueskin_大约 11 年前
Another &#x27;use namecoin&#x27;s model&#x27; suggestion? Please, please, no. I don&#x27;t want to place authority for issuing certs solely in the hands of people with mining hardware or botnets, or lots of money to buy form the aforementioned.
lnanek2大约 11 年前
&gt; My Heart Bleeds for OpenSSL<p>Looking at their web site, they have a link right at the top to buy a support contract and another to contract a team member. This level of publicity probably equals big consulting dollars for them.
newman314大约 11 年前
Just think, Zuck could have paid $18bil for WhatsApp and used the $1bil leftover as OpenSSL or like bounty.<p>Better use of money and still of use to FB.
na85大约 11 年前
I don&#x27;t think &quot;progenerator&quot; is a word.<p>Did the author mean &quot;progenitor&quot;?
ForHackernews大约 11 年前
Your site (blogspot&#x27;s site?) breaks my back button something fierce.
评论 #7557640 未加载