Re: Deprecate TLS1.0 support in emacs

[Robert Pluim]

Lars Ingebrigtsen <address@hidden> writes:

> Robert Pluim <address@hidden> writes:
>
>> There is no refusal of access, just refusal of a specific protocol. If
>> we implement your suggestion from below there won't even be refusal.
>
> It is a refusal to access a resource because somebody has determined
> that a specific protocol (HTTP + TLS1.0) is something that our users
> shouldn't be able to use.

Allright. If we implement the checking in nsm, then that becomes
"something our users get warned about but can be overriden, don't
complain to us afterwards".

> lists.gnu.org is, of course, just one example.
>
>> I appreciate that's a strong opinion, but I definitely think we should
>> strongly encourage people to move away from both of these protocols.
>
> Encouragement is fine, but making our users switch to Firefox because of
> this obsession with protocols isn't.

We have no choice about it. People with bad intentions obsess over
protocols far more than this. We should attempt to make their lives as
hard as possible.

> As more and more resources are being made available over encrypted
> channels only, and as more and more of these (as a result of bad
> maintenance and the like) get tagged as "invalid encryption", something
> has to give.
>
> It seems like the current movement is to just to start ignoring whether
> protocols are outdated, use invalid certificates and the like, and just
> tell the user "you tried to access this via a secure channel.  It's not,
> but here's the content anyway".

I happen to disagree with that movement, but if that's what you want
emacs to do it's possible.

> I may be misremembering, but I think the new Chrome beta is going in
> this direction: No explicit refusals to access anything, but just a big
> red X in the menu bar saying "UNSAFE".  It is, you know, not less safe
> than accessing via an unencrypted channel.

It's less safe because some people won't notice the 'UNSAFE'
indication, and will be unpleasantly surprised when things they
thought were encrypted in transit aren't. Hence my preference for the
prescriptive stance of banning TLS1.0 and TLS1.1

> I think this is probably the way Emacs should consider moving, too, for
> eww and package-list.  For other use, we may consider having the NSM
> prompt the user for what to do with TLS1.0.  But probably not just yet.

OK. I'll just patch my emacs locally to disable TLS1.0 and TLS1.1
until then.

At some point we should deprecate lisp/net/tls.el as well (or as a
bare minimum remove its support for ssl), the builtin TLS support
works very well.

Robert