[deleted]
SLOTH – Security Losses from Obsolete and Truncated Transcript Hashes
11–20 of 22 posts
Re: SLOTH – Security Losses from Obsolete and Truncated Transcript Hashes
#12The link's not working for me, nor is any reference to SLOTH given on http://www.mitls.org/wsgi/tls-attacks .
Try clearing your recent browsing history, cookies, and such. The link wasn't working for me either, but it started working after I had cleared everything.
Re: SLOTH – Security Losses from Obsolete and Truncated Transcript Hashes
#13It's not clear if the JRE6 and the JRE7 are impacted (does the JSSE shipped with them support TLS1.2)? If so, pretty worrying as not supported anymore yet widely deployed.
Re: SLOTH – Security Losses from Obsolete and Truncated Transcript Hashes
#14More interesting than the attack itself is their overall effort of combining formal verification with protocol implementation. Along the way, they've found all these problems in the other protocols because they didn't use such rigorous methods. Quite an argument in favor of using high assurance techniques for at least critical, slow-changing protocols like TLS. Anyway, I found this paper... http://www.ieee-security.o…
Formal verification of protocols like TLS is essentially the research thesis behind this group at INRIA, which was also responsible for Logjam (as well as the paper you linked to).
Oh yeah, they're kicking ass on every front of this sub-field. Then, Leroy et al are doing that for compilers and language analysis at INRIA as well. Then Astree is leading it for static analysis of C.
France, esp INRIA, seems to be in the lead on verified software with a real-world focus. It will be great when more elsewhere follow suit.
Re: SLOTH – Security Losses from Obsolete and Truncated Transcript Hashes
#15Earlier quoted context omitted.
I wonder why you're speculating given they used the attacks against default configurations of Java apps, Firefox, some Chrome builds, BouncyCastle, and more. Amusingly, the clients often accepted the weaker crypto even when it was disabled. Fits my meme's nicely. Then, some of the flaws that led to that were fixed. Not sure how applicable it is now outside a checklist item for a situation that can repeat in a new cli…
I don't understand your question. I'm not doubting the impact of the paper, just one of its conclusions.
That's all I was wondering.
Re: SLOTH – Security Losses from Obsolete and Truncated Transcript Hashes
#16It's not clear if the JRE6 and the JRE7 are impacted (does the JSSE shipped with them support TLS1.2)? If so, pretty worrying as not supported anymore yet widely deployed.
I keep seeing this in a lot of places, but Oracle are still releasing JDK6 and JDK7 updates every quarter. AFAIK TLSv1.2 is not supported on 6.
Edit: ah, but only to customers paying for support.
Re: SLOTH – Security Losses from Obsolete and Truncated Transcript Hashes
#17It's not clear to me that this work establishes that truncated hashes are dangerous, so much as that tls-unique is just not a very good protocol.
I read somewhere that it was being considered for deprecation in the TLS 1.3 spec.
Re: SLOTH – Security Losses from Obsolete and Truncated Transcript Hashes
#18It's not clear to me that this work establishes that truncated hashes are dangerous, so much as that tls-unique is just not a very good protocol.
I am very much a novice, but here goes...
I don't think the paper was trying to speak to truncation generally. Truncation is a weakening of the crypto by definition. (Reduce bits => reduce security.) It is easier (cheaper) to find a collision if one uses a truncated hash. That doesn't make it Dangerous or Safe; just quantitatively reduced.
If the authors are trying to establish anything, it seems to be, "Yes, collisions do matter!"
Re: SLOTH – Security Losses from Obsolete and Truncated Transcript Hashes
#19It's not clear if the JRE6 and the JRE7 are impacted (does the JSSE shipped with them support TLS1.2)? If so, pretty worrying as not supported anymore yet widely deployed.
I keep seeing this in a lot of places, but Oracle are still releasing JDK6 and JDK7 updates every quarter. AFAIK TLSv1.2 is not supported on 6. Edit: ah, but only to customers paying for support.
Java7u79 is supposed to be the last public release. From the SLOTH page, it looks like there might be another release to address this.
Re: SLOTH – Security Losses from Obsolete and Truncated Transcript Hashes
#20Earlier quoted context omitted.
Formal verification of protocols like TLS is essentially the research thesis behind this group at INRIA, which was also responsible for Logjam (as well as the paper you linked to).
Oh yeah, they're kicking ass on every front of this sub-field. Then, Leroy et al are doing that for compilers and language analysis at INRIA as well. Then Astree is leading it for static analysis of C. France, esp INRIA, seems to be in the lead on verified software with a real-world focus. It will be great when more elsewhere follow suit.
Galois just gave a talk on high assurance crypto at RWC (they made cryptol and other open sourced tools to give formal proofs of security)