The SHA1 sunset

The SHA1 sunset

[Lars Magne Ingebrigtsen]

SHA1 is considered to be likely to be "broken" sometime this year (i.e.,
the NSA will be able to create SHA1 collisions that may enable them to
issue SHA1 certificates to themselves at will for any domain (some
people are very sceptical of this claim)), so I've added warnings about
SHA1 certificates to the "high" `network-security-level' setting in
Emacs 25.1 now.

Other browser makers have announced their intention to refuse to make
any TLS connection using SHA1-signed certificates on January 1st, but
I'm not sure whether they actually went through with this?

We might consider at some point in the future to move this check to the
"medium" (default) setting.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: The SHA1 sunset

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 03 Jan 2016 10:55:36 +0100
> 
> We might consider at some point in the future to move this check to the
> "medium" (default) setting.

Why not now?

Re: The SHA1 sunset

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

>> We might consider at some point in the future to move this check to the
>> "medium" (default) setting.

> Why not now?

Let's move it to the medium setting now. The writing has been on the wall for
SHA1 for a little while now.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: The SHA1 sunset

[Lars Magne Ingebrigtsen]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> We might consider at some point in the future to move this check to the
>>> "medium" (default) setting.
>
>> Why not now?
>
> Let's move it to the medium setting now. The writing has been on the
> wall for SHA1 for a little while now.

It has, but warning users about something that isn't a thing yet is
doing the users a disservice.  Bogus security warnings make people
ignore real security warnings.

If you look at the time line for MD5, for instance, it took quite a few
years between people thought that it was wonky and somebody exploited
that to create "innovative" certificates...

On the fourth hand, we release Emacs so seldomly that we have to plan
for the future, so perhaps it should be in "medium" anyway.

It would have been nice if Emacs had a way to retroactively change these
things.  I mean, "push" very, very selective security-related updates on
users...  Hm...  could we imagine using the package system for doing
security updates?  It would mean that Emacs would "call home" once in a
while...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: The SHA1 sunset

[John Wiegley]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> On the fourth hand, we release Emacs so seldomly that we have to plan for
> the future, so perhaps it should be in "medium" anyway.

Yeah, that was my thinking.

> It would have been nice if Emacs had a way to retroactively change these
> things. I mean, "push" very, very selective security-related updates on
> users... Hm... could we imagine using the package system for doing security
> updates? It would mean that Emacs would "call home" once in a while...

Or associate your warnings with times, and after a certain date being
proclaiming that doom is likely upon them.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: The SHA1 sunset

[Lars Magne Ingebrigtsen]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> On the fourth hand, we release Emacs so seldomly that we have to plan for
>> the future, so perhaps it should be in "medium" anyway.
>
> Yeah, that was my thinking.

Mm.  I wonder what the percentage of TLS certificates are SHA-1 these
days...  anybody have statistics?

A user just discovered that the (self-signed) certificate on
news.gmane.org is SHA-1, for instance.  :-)

>> It would have been nice if Emacs had a way to retroactively change these
>> things. I mean, "push" very, very selective security-related updates on
>> users... Hm... could we imagine using the package system for doing security
>> updates? It would mean that Emacs would "call home" once in a while...
>
> Or associate your warnings with times, and after a certain date being
> proclaiming that doom is likely upon them.

:-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: The SHA1 sunset

[Mike Gerwitz]

[-- Attachment #1: Type: text/plain, Size: 621 bytes --]

On Mon, Jan 04, 2016 at 01:53:56 +0100, Lars Magne Ingebrigtsen wrote:
> It has, but warning users about something that isn't a thing yet is
> doing the users a disservice.  Bogus security warnings make people
> ignore real security warnings.

The date that browsers implement warnings is arbitrary; this is still
certainly "a thing".

https://sites.google.com/site/itstheshappening/

Such a warning will not be bogus, and it would be a service to warn
users even if others don't.

-- 
Mike Gerwitz
Free Software Hacker | GNU Maintainer
https://mikegerwitz.com
FSF Member #5804 | GPG Key ID: 0x8EE30EAB

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: The SHA1 sunset

[Lars Magne Ingebrigtsen]

Mike Gerwitz <mtg@gnu.org> writes:

> The date that browsers implement warnings is arbitrary; this is still
> certainly "a thing".
>
> https://sites.google.com/site/itstheshappening/

I'm not sure why you're linking to that site?

The question isn't whether the NSA are able to do SHA-1 collisions
(which I think everybody assumes that they can, albeit expensively), but
whether they can create certificates.  The jury is out on that one, and
many people think that it's not a thing (yet) (with certificates with
the recommended entropy in serial numbers and dates).

https://blog.cloudflare.com/why-its-harder-to-forge-a-sha-1-certificate-than-it-is-to-find-a-sha-1-collision/

> Such a warning will not be bogus, and it would be a service to warn
> users even if others don't.

It will almost certainly be bogus (now).  Next year, perhaps not.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: The SHA1 sunset

[Mike Gerwitz]

[-- Attachment #1: Type: text/plain, Size: 2260 bytes --]

On Mon, Jan 04, 2016 at 23:14:06 +0100, Lars Magne Ingebrigtsen wrote:
>> https://sites.google.com/site/itstheshappening/
>
> I'm not sure why you're linking to that site?

This was the recent paper describing the only SHA-1 collision which was
directly addressed in Ballot 152 in determining whether to continue
issuing SHA-1 certs through 2016:

  https://www.grc.com/sn/sn-529-notes.pdf

> The question isn't whether the NSA are able to do SHA-1 collisions
> (which I think everybody assumes that they can, albeit expensively), but
> whether they can create certificates.  The jury is out on that one, and
> many people think that it's not a thing (yet) (with certificates with
> the recommended entropy in serial numbers and dates).

That's all good when those suggestions are actually implemented.

> https://blog.cloudflare.com/why-its-harder-to-forge-a-sha-1-certificate-than-it-is-to-find-a-sha-1-collision/
>
>> Such a warning will not be bogus, and it would be a service to warn
>> users even if others don't.
>
> It will almost certainly be bogus (now).  Next year, perhaps not.

SHA-1 is broken, which we can agree on.  The proposal by CloudFlare to
randomize serial numbers with at least 20 bits of entropy is a band aid
atop of a broken cryptosystem.  It should work for the meantime---for
those CAs that actually implement it---but
this is not an alternative to issuing SHA-2 certificates, and it won't
help already issued certs.  Personally, I prefer not to rely on bandages
for my crypto.

Since this mitigation attempt is dependent on CAs adopting it, that can
only get _better_ with time.  Considering SHA-1 to be broken (period),
then presumably, a year from now, we'd only be in a better position if
new SHA-1 certs are issued with a randomized serial number, given the
relative increase in computing cost/power.  We would be in a worse
position for SHA-1 certs that haven't expired a year from now, since
they'll be cheaper to exploit.

CloudFlare also wrote about browser support for SHA-2:

  https://blog.cloudflare.com/sha-1-deprecation-no-browser-left-behind/

-- 
Mike Gerwitz
Free Software Hacker | GNU Maintainer
https://mikegerwitz.com
FSF Member #5804 | GPG Key ID: 0x8EE30EAB

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: The SHA1 sunset

[Lars Magne Ingebrigtsen]

Mike Gerwitz <mtg@gnu.org> writes:

> Personally, I prefer not to rely on bandages for my crypto.

It is, of course, up to you what you do for yourself.

What we're discussing is what the defaults should be in Emacs.  Issuing
warnings to users about something that isn't (yet) a probable issue is a
disservice to our users.  If they feel that these security mechanisms
get in the way of getting stuff done, they will, of course, just disable
those mechanisms altogether.

Which is why I asked to statistics of SHA-1 certificates in use today.
The newest one I could find was from April 2015, and at that point 20%
of Alexa Top 1000 web sites were using SHA-1 certificates.  If that's
still the case, it's way more than is reasonable to warn our users
about.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: The SHA1 sunset

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 04 Jan 2016 01:53:56 +0100
> 
> John Wiegley <jwiegley@gmail.com> writes:
> 
> >>>>>> Eli Zaretskii <eliz@gnu.org> writes:
> >
> >>> We might consider at some point in the future to move this check to the
> >>> "medium" (default) setting.
> >
> >> Why not now?
> >
> > Let's move it to the medium setting now. The writing has been on the
> > wall for SHA1 for a little while now.
> 
> It has, but warning users about something that isn't a thing yet is
> doing the users a disservice.

My understanding is that it's already a thing, but I'm not an expert
on those issues.

Re: The SHA1 sunset

[James Cloos]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

LMI> Other browser makers have announced their intention to refuse to make
LMI> any TLS connection using SHA1-signed certificates on January 1st, but
LMI> I'm not sure whether they actually went through with this?

No, they are rejecting and cert which uses sha1 and claims to have been
issued after 2016-01-01T00:00:00.

The latter part is important.

The commercial CAs have agreed not to issue any sha1 certs starting on
that date, so the refusal does not affect anything using mainstream
commercial certs.

So the browser vendors are not doing anything of actual value, just
engaging in some theatre.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6