On Mon, Jul 10, 2017 at 08:19:11PM +0200, Niklas Keller wrote: > > What's your threat model, and how does it justify this effort? > > The same as for browsers I guess. Could you explain why browsers and Java > disable SHA1, but it's not worth for me doing so? The browsers and Java do this because they can (they control the underlying libraries) and in order to prod the CAs into action, and to force server operators to move to SHA2. There is no immediate threat, but the goal is to move the ecosystem away from SHA-1. Now that they've done that, you don't need to refuse SHA-1 in every piece of legacy software (e.g. OpenSSL 1.0.x). Your contribution to purging SHA-1 from the public Internet would be negligible. On Mon, Jul 10, 2017 at 12:07:42PM -0700, Michael Sierchio wrote: > > Collision attacks don't directly lead to certificate forgery. There are > > no known 2nd-preimage attacks on SHA-1. > > I'm pretty sure, but are you saying you would rather wait for a > demonstration of the weakness being turned into a practical attack? Making your code more complex is a far higher risk than a practical certificate forgery based on a collision attack on SHA-1. > Second pre-image attacks against reduced SHA-1 have been demonstrated. It's > only a matter of time before second pre-image resistance for full SHA-1 is > dead and buried. We don't even have 2nd-preimage attacks on MD5 yet. I'm not holding my breath for 2nd-preimage attacks on full SHA-1. Anyway, you can, if you wish, implement a verification callback that makes the appropriate checks for OpenSSL 1.0.x, but my advice is to just let the CAs get rid of SHA-1 under pressure from the browsers, Java, ... In OpenSSL 1.2.0 (not sure about 1.1.1) we can designate SHA-1 as too weak for security level 1, and at that time, OpenSSL applications linked with OpenSSL will by default refuse to validate certificate signatures based on SHA-1. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
