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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Downgrade Attack on TLS 1.3 and Vulnerabilities in Major TLS Libraries

227 点作者 pentestercrab超过 6 年前

15 条评论

axaxs超过 6 年前
Just commenting since I saw and recognized the name next to BearSSL... Thomas Pornin is an absolute treasure, and anyone interested in entry level crypto and beyond should read through his StackOverflow responses. Many of the answers simplify complex topics into more digestable pieces.
评论 #19112706 未加载
pedrocr超过 6 年前
With the amount of TLS vulnerabilities I don't really understand why we're not just replacing it completely. From what I've read a lot of the issues is the complexity of the standard itself that we could do much better now that so much more is known about good crypto practice. Google has already pushed HTTP 2 and now 3 thanks to having very sizeable chunks of both the browser and the sites. Why not also have a much better designed crypto standard in one of those efforts?
评论 #19113611 未加载
评论 #19113586 未加载
评论 #19116503 未加载
Someone1234超过 6 年前
&gt; The cat is not dead yet, with two lives remaining thanks to BearSSL (developed by my colleague Thomas Pornin) and Google&#x27;s BoringSSL.<p>Some kind of award has to go to this sentence, that has to be the most convoluted way to simply say &quot;aren&#x27;t vulnerable.&quot;<p>In context you can only just barely follow it, and it literally involves counting the vulnerable + un-vulnerable libraries to check they all add up to 9...
评论 #19112477 未加载
评论 #19113106 未加载
inetknght超过 6 年前
&gt; <i>The last 20 years of attacks that have been re-discovering Bleichenbacher&#x27;s seminal work in 1998 clearly show that it is close to impossible to correclty implement the RSA PKCS#1 v1.5 encryption scheme. While our paper recommends a series of mitigations, it is time for RSA PKCS#1 v1.5 to be deprecated and replaced by more modern schemes like OAEP and ECEIS for asymmetric encryption or Elliptic Curve Diffie-Hellman for key exchanges.</i><p>RSA PKCS#1 v1.5: <a href="https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc2313" rel="nofollow">https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc2313</a><p>Title: <i>PKCS #1: RSA Encryption version 1.5</i><p>tl;dr: deprecate RSA encryption as a whole?! Did I read this right?
评论 #19111957 未加载
评论 #19112235 未加载
评论 #19130130 未加载
评论 #19112948 未加载
fulafel超过 6 年前
There&#x27;s a big disparity between the level of ambition in transport security implementations, and the big recent archievements in getting crypto more widely deployed...<p>I think the current standard should be memory-safe implementations with proven robustness against known classes of attacks, and optional resistance against traffic analysis (at expense of wasted bandwidth).
hombre_fatal超过 6 年前
Jesus. Imagine being enough of a genius to actually write timing-safe code.
评论 #19112703 未加载
kccqzy超过 6 年前
Why is using RSA for key exchanges acceptable? I thought we had dedicated key exchange algorithms, Diffie–Hellman (DH), the ephemeral variant (DHE), and the elliptic curve variant (ECDHE). So why RSA?<p>Also, what if I disable RSA in my browser and make sure the ClientHello doesn&#x27;t mention RSA? Will I be secure?
评论 #19112563 未加载
wilsonthewhale超过 6 年前
Is LibreSSL affected?
评论 #19111975 未加载
评论 #19113638 未加载
评论 #19120201 未加载
评论 #19111979 未加载
评论 #19112185 未加载
评论 #19111978 未加载
devit超过 6 年前
How about the obvious solution to all timing attacks of sending a network response after a timer set to 2^K milliseconds expires rather than when the data is ready? (with K adaptively incremented and decremented only rarely, outliers managed by starting the timer again so that the time is rounded up to 2^K)<p>This way, the only timing signal available would be which requests take an outlier amount of time, and I doubt that&#x27;s enough to break anything unless you can remotely cause the peer to hit slow disks or make network requests depending on secret data (which is a far more explicit programming choice than CPU timing differences).
评论 #19113977 未加载
badrabbit超过 6 年前
Maybe a one size fits all transport security protocol is a bad idea. Simpler and smaller protocols with less features might provider better stable security?
walrus01超过 6 年前
Downgrading to TLS1.2 isn&#x27;t the end of the world.<p>One of the things you can do to make a significant difference is configure all of your httpd (apache2, nginx, whatever) to specifically disallow SSLv3, TLS1.0 and TLS1.1.<p>There is no longer any relevant population of useragents that don&#x27;t understand TLS1.2.
评论 #19112642 未加载
评论 #19112164 未加载
评论 #19113572 未加载
baybal2超过 6 年前
Now, who was a TLS 1.3 committee member who pushed for removing &quot;hard versioning&quot; from server hello?
merb超过 6 年前
am I vulnerable if I only use TLS 1.2?
评论 #19112455 未加载
java-man超过 6 年前
Is BouncyCastle affected?
bitmadness超过 6 年前
What about LibreSSL?