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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

This working group has failed

127 点作者 mmoya超过 11 年前

6 条评论

lazyjones超过 11 年前
Specs designed by committee usually fail when they produce just the "paper" and no reference implementation. Look at W3C, which consistently failed to develop their own reference browser. The same seems true for TLS, actual implementations are too complicated because the committee paid no attention to this. A positive example is MP3, where everyone just copied the reference codec in the beginning.
评论 #7016629 未加载
评论 #7018600 未加载
评论 #7019158 未加载
评论 #7018095 未加载
MichaelGG超过 11 年前
Here&#x27;s an interesting post about TLS compatibility[1]. I guess it explains why no browsers have had TLS 1.2 on by default for such a long time.<p>&quot; To add to this discussion about protocol version intolerance, I&#x27;ve been tracking this problem in my SSL Pulse data set (SSL servers from the Alexa top 1 million).<p>Here&#x27;s what I have for November:<p><pre><code> Total servers: 163,587 TLS 1.0 intolerance 9 TLS 1.1 intolerance 1,388 TLS 1.2 intolerance 1,448 (~ 0.9%) TLS 1.3 intolerance 17,840 (~10.9%) TLS 2.98 intolerance 122,698 (~75.0%) Long handshake intolerance: 4,795 (~2.9%)</code></pre> &quot;<p>1: <a href="https://www.ietf.org/mail-archive/web/tls/current/msg10657.html" rel="nofollow">https:&#x2F;&#x2F;www.ietf.org&#x2F;mail-archive&#x2F;web&#x2F;tls&#x2F;current&#x2F;msg10657.h...</a>
评论 #7018803 未加载
y0ghur7_xxx超过 11 年前
Looks like it&#x27;s down.<p>Cache: <a href="http://webcache.googleusercontent.com/search?q=cache:https://www.ietf.org/mail-archive/web/tls/current/msg10598.html&amp;hl=en&amp;strip=1" rel="nofollow">http:&#x2F;&#x2F;webcache.googleusercontent.com&#x2F;search?q=cache:https:&#x2F;...</a>
makomk超过 11 年前
Given recent revelations, one has to wonder if the working group merely failed by itself or was given a substantial nudge in that direction by someone who wanted TLS to be insecure.
评论 #7016769 未加载
vacri超过 11 年前
Following the thread, the TLS 1.2 spec was completed in 2008, but it wasn&#x27;t supported in OpenSSL until mid-2012 - so anything that depends on OpenSSL had to wait until at least then, then go through the implentation and reshipping, then trickle on down to the end vendors. And with no-one using TLS 1.2 or having a need for it because it wasn&#x27;t available, it was back-burnered by the browsers.<p>The follow-up comments paint a much fuller picture of why things are delayed, where the failures are, and what&#x27;s going on.
评论 #7016650 未加载
parennoob超过 11 年前
Maybe making things more intelligible would help instead of using language that is extremely obfuscated and confusing, and unaccompanied by any actual mathematics?<p>Take this sentence from the email for instance:<p>&quot;Even AES-GCM got screwed up: nonces should be counters, but all implementations make them random, introducing an artificial birthday bound issue due to truncation in the standard.&quot;<p>I have no idea WTF this means, but let&#x27;s go over it:<p>nonce: I know this is a randomly generated number that can be only used once -- now why should it be a counter? No idea.<p>&quot;but all implementations make them random&quot;: wait, aren&#x27;t they supposed to be random by definition? According to the above line though, they are supposed to be random. Damn, what I knew must be wrong. I wonder if this person on the internet has submitted some sort of explanation about this somewhere.<p>&#x27;artificial birthday bound issue&#x27;: Assuming this refers to the birthday attack (<a href="http://en.wikipedia.org/wiki/Birthday_attack" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Birthday_attack</a>). Why is it &quot;artificial&quot;? Can we see some mathematical proofs attached please? I sort of get the idea here -- because the nonce is random, it is vulnerable to being recreated after a certain number of attempts, but there is nothing concrete attached here. Or I could be totally wrong in this interpretation. God knows, and maybe this chap.<p>&quot;...due to truncation in the standard.&quot; -- Do you mean some sort of <i>mathematical</i> truncation, i.e. &quot;my number was truncated to 16 bits&quot;, or truncation of the standard itself &quot;the last section of the standard was removed&quot;? Please be clear.<p>Same goes for most things related to crypto -- if you want stuff like TLS to be examined by more eyeballs and find more bugs, you have to first try and make it more accessible. The sentences above are, in my opinion, a complete communication failure.
评论 #7018434 未加载
评论 #7018391 未加载
评论 #7018865 未加载
评论 #7018292 未加载