On 8.1.2016 16:57, Christian Heimes wrote: > On 2016-01-08 16:49, Petr Spacek wrote: >> On 8.1.2016 13:56, Fraser Tweedale wrote: >>> On Fri, Jan 08, 2016 at 01:26:57PM +0100, Martin Kosek wrote: >>>>> Hi Fraser and other X.509 SMEs, >>>>> >>>>> I wanted to check with you on what we have or plan to have with respect to >>>>> certificate/cipher strength in FreeIPA. >>>>> >>>>> When I visit the FreeIPA public demo for example, I usually see following >>>>> errors with recent browsers: >>>>> >>>>> * Your connection to ipa.demo1.freeipa.org is encrypted using obsolete >>>>> cypher >>>>> suite. >>>>> - The connection uses TLS 1.2 >>>>> - The connection is encrypted ising AES_128_CBC, with HMAC-SHA1 for >>>>> message >>>>> authentication and RSA as the key exchange mechanism >> >> HMAC-SHA1 reminded me recently published paper: >> http://www.mitls.org/pages/attacks/SLOTH >> >> It claims that all MD5 and SHA1 uses should be eliminated if feasible. > > MD5 and SHA-1 should no longer be used for signatures. MACs are a > completely different story. HMAC-SHA1 and even HMAC-MD5 are still fine > and believed to be secure. > > https://en.wikipedia.org/wiki/Hash-based_message_authentication_code#Security
Christian, have you read the page (or even better the paper) I linked above? The page starts with this: > Introduction > > In response to recent high-profile attacks that exploit hash function > collisions, software vendors have started to phase out the use of MD5 and > SHA1 in third-party digital signature applications such as X.509 > certificates. However, weak hash functions continue to be used in various > cryptographic constructions within mainstream protocols such as TLS, IKE, and > SSH, because practitioners argue that their use in these protocols relies > only on second preimage resistance, and hence is unaffected by collisions. We > systematically investigate and debunk this argument. > > We identify a new class of transcript collision attacks on popular > cryptographic protocols such as TLS, IKE, and SSH, that significantly reduce > their expected security. Our attacks rely on the use of obsolete hash > constructions in these protocols. If you open the paper, it has this on the very first page: [...] > This leaves open the question of what to do about > other uses of MD5 and SHA-1 in popular crypto- > graphic protocols. Practitioners commonly believe that > collisions only affect non-repudiable signatures (like > certificates), but that signatures and MACs used within > protocols are safe as long as they include unpredictable > contents, such as nonces [16], [15].In these cases, > protocol folklore says that a second preimage attack > would be required to break these protocols, and such > attacks are still considered hard, even for MD5. > Conversely, theoretical cryptographers routinely as- > sume collision-resistance in proofs of security for > these protocols. For example, various recent proofs of > > TLS [17], [22], [11] assume collision-resistance even > though the most popular hash functions used in TLS > are MD5 and SHA-1. Whom shall we believe? Either it > is the case that cryptographic proofs of these protocols > are based on too-strong (i.e. false) assumptions that > should be weakened, or that practitioners are wrong and > collision resistance is required for protocol security. > This paper seeks to clarify this situation by systemat- > ically investigating the use of hash functions in the key > exchanges underlying various versions of TLS, IPsec, > and SSH. We demonstrate that, contrary to common > belief, collisions can be used to break fundamental secu- > rity guarantees of these protocols. One thing I remember from my cryptography courses I had on university is that I should not try to outsmart professional cryptographers when it comes to assessing security properties :-D Judging from this: Claims on the Wikipedia page are not sufficient guarantee for me, sorry. -- Petr^2 Spacek -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
