On Mon, Jan 11, 2016 at 09:38:05PM +0100, Jakob Bohm wrote: > On 08/01/2016 18:43, Salz, Rich wrote: > >Are you going to keep posting and posting until you get a response? :( > > > >Master branch, 1.1, is not released but will not be vulnerable (may already be fixed) > >1.0.2 is not vulnerable. > >1.0.1f and later are not vulnerable. > >1.0.0 might be, and is end of life anyway so you should move of that. > >0.9.8 is also end of life, but does not do TLS 1.2 so is not vulnerable. > If you read the description of SLOTH (linked in the OP), you > will see that it is not limited to TLS 1.2 and probably > affects the TLS/SSL versions implemented by older (end of > life) OpenSSL versions such as 0.9.8. > > Basically, it is a laundry list of ways that backward > compatible hash uses in the SSL/TLS protocols are weaker > than some people assume. Their summary list doesn't even > consider the possibility that some people still need to use > TLS 1.1 or older, so barely mentions those. > > This also means that completely protecting an > implementation against SLOTH is not possible without > breaking interoperability with implementations that > are not or cannot be updated to the latest protocol > versions and features (This happens to include some > widely deployed embedded operating systems). > > Now it so happens that SLOTH also includes an attack on > implementation bugs that can be tricked into > using/accepting MD5-based signatures when they shouldn't. > That *particular* aspect of SLOTH was apparently fixed > in 1.0.1f and 1.0.2. > > The entire discussion would have been easier if the SLOTH > team at INRIA had given specific names and CVE ids for > each of the issues in their report, such that one might say > "SLOTH-1: Never vulnerable, SLOTH-2: Fixed in 1.0.1f, SLOTH-3: > hypothetical for now, can be fixed with a cipher string > setting, etc. etc." But no such names exist. So here are the things mentioned in the paper: 1) Some things that were believed to require preimage resistance need collision resistance. This by itself reduces security bits of the hashes by a factor 2. Assuming MD5 and SHA1 didn't have any problem with collision resistance it would be reduced from 128 and 160 bit to 64 and 80. But they have a problem with collision resistance and so it's worse, specially for MD5. 2) Some implementations support MD5 based signatures in TLS 1.2 3) Some implementations accept the MD5 based signatures in TLS 1.2 while it would appear they didn't. SLOTH really is just about 1). It says that you should stop using MD5 and really look at stopping to use SHA1. And so 2) and 3) are just 2 cases where MD5 is used. But just fixing 2) and 3) is just fixing the problem with MD5, while we should also look at stopping SHA1. TLS 1.0 and 1.1 use MD5 + SHA1, so while those are enabled we're stuck at the level of SHA1. Kurt
