Deprecate TLS1.0 support in emacs

classic Classic list List threaded Threaded
48 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Deprecate TLS1.0 support in emacs

Robert Pluim
Hi,

whilst investigating another bug, I noticed that
https://lists.gnu.org/ is still using TLS1.0, which is seriously
deprecated. I propose the following patch to make emacs not use TLS1.0
anymore unless explicitly requested (and someone should update the
settings on lists.gnu.org).

Perhaps this warrants a NEWS entry as well, let me know.

Regards

Robert


From e0526d6ac7a2622a1b8781be4825fbef985a5ed3 Mon Sep 17 00:00:00 2001
From: Robert Pluim <[hidden email]>
Date: Wed, 12 Jul 2017 14:59:35 +0200
Subject: [PATCH] Remove TLS1.0 from default gnutls connection parameters

        * lisp/net/gnutls.el (gnutls-boot-parameters): Remove TLS1.0
        from default parameters.
        * src/gnutls.c (Fgnutls_boot): Likewise.
---
 lisp/net/gnutls.el | 4 ++--
 src/gnutls.c       | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/lisp/net/gnutls.el b/lisp/net/gnutls.el
index 5db87329c3..3386dc5efc 100644
--- a/lisp/net/gnutls.el
+++ b/lisp/net/gnutls.el
@@ -264,11 +264,11 @@ gnutls-log-level
         (priority-string (or priority-string
                              (cond
                               ((eq type 'gnutls-anon)
-                               "NORMAL:+ANON-DH:!ARCFOUR-128")
+                               "NORMAL:+ANON-DH:!ARCFOUR-128:-VERS-TLS1.0")
                               ((eq type 'gnutls-x509pki)
                                (if gnutls-algorithm-priority
                                    (upcase gnutls-algorithm-priority)
-                                 "NORMAL")))))
+                                 "NORMAL:-VERS-TLS1.0")))))
         (verify-error (or verify-error
                           ;; this uses the value of `gnutls-verify-error'
                           (cond
diff --git a/src/gnutls.c b/src/gnutls.c
index 2078ad88f2..c3d7f54b73 100644
--- a/src/gnutls.c
+++ b/src/gnutls.c
@@ -1333,7 +1333,7 @@ PROPLIST is a property list with the following keys:
 
 :hostname is a string naming the remote host.
 
-:priority is a GnuTLS priority string, defaults to "NORMAL".
+:priority is a GnuTLS priority string, defaults to "NORMAL:-VERS-TLS1.0".
 
 :trustfiles is a list of PEM-encoded trust files for `gnutls-x509pki'.
 
@@ -1389,7 +1389,7 @@ one trustfile (usually a CA bundle).  */)
   gnutls_certificate_credentials_t x509_cred = NULL;
   gnutls_anon_client_credentials_t anon_cred = NULL;
   Lisp_Object global_init;
-  char const *priority_string_ptr = "NORMAL"; /* default priority string.  */
+  char const *priority_string_ptr = "NORMAL:-VERS-TLS1.0"; /* default priority string.  */
   char *c_hostname;
 
   /* Placeholders for the property list elements.  */
--
2.13.0.rc0

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deprecate TLS1.0 support in emacs

Lars Ingebrigtsen
Robert Pluim <[hidden email]> writes:

> whilst investigating another bug, I noticed that
> https://lists.gnu.org/ is still using TLS1.0, which is seriously
> deprecated. I propose the following patch to make emacs not use TLS1.0
> anymore unless explicitly requested (and someone should update the
> settings on lists.gnu.org).

As you point out, removing TLS1.0 support from Emacs will make it
impossible for people to access common resources like
https://lists.gnu.org/ (and many other sites), so I don't think that's a
good idea.

It might make sense to warn people about these resources not being
"secure", though.

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deprecate TLS1.0 support in emacs

Robert Pluim
Lars Ingebrigtsen <[hidden email]> writes:

> Robert Pluim <[hidden email]> writes:
>
>> whilst investigating another bug, I noticed that
>> https://lists.gnu.org/ is still using TLS1.0, which is seriously
>> deprecated. I propose the following patch to make emacs not use TLS1.0
>> anymore unless explicitly requested (and someone should update the
>> settings on lists.gnu.org).
>
> As you point out, removing TLS1.0 support from Emacs will make it
> impossible for people to access common resources like
> https://lists.gnu.org/ (and many other sites), so I don't think that's a
> good idea.

TLS1.0 is a seriously insecure protocol. I refrained from doing what I
actually wanted to do, which is deprecate TLS1.1 as well. I think it's
a disservice to allow TLS1.0 to continue to be used.

> It might make sense to warn people about these resources not being
> "secure", though.

That could be done with nsm, but only if you'll accept setting the
default network-security-level to 'high, or adding a specific check
for protocol version at 'medium. Option 1 looks something like this:

Warn about TLS1.0 and TLS1.1

        * lisp/net/nsm.el (network-security-level): Change default to
        'high so that we check protocol parameters
        (nsm-check-protocol): Warn if we detect TLS1.0 at level 'high,
        and TLS1.1 at level 'paranoid

diff --git a/lisp/net/nsm.el b/lisp/net/nsm.el
index 8d3463ef0a..f4d1fbb301 100644
--- a/lisp/net/nsm.el
+++ b/lisp/net/nsm.el
@@ -35,7 +35,7 @@ nsm
   :version "25.1"
   :group 'comm)
 
-(defcustom network-security-level 'medium
+(defcustom network-security-level 'high
   "How secure the network should be.
 If a potential problem with the security of the network
 connection is found, the user is asked to give input into how the
@@ -231,6 +231,27 @@ nsm-check-protocol
      host port protocol)))
       (delete-process process)
       nil)
+     ((and protocol
+   (string-match "TLS1.0" protocol)
+   (not (memq :tls1.0 (plist-get settings :conditions)))
+   (not
+    (nsm-query
+     host port status :tls1.0
+     "The connection to %s:%s uses the %s protocol, which is unsafe."
+     host port protocol)))
+      (delete-process process)
+      nil)
+     ((and protocol
+           (eq network-security-level 'paranoid)
+   (string-match "TLS1.1" protocol)
+   (not (memq :tls1.0 (plist-get settings :conditions)))
+   (not
+    (nsm-query
+     host port status :tls1.1
+     "The connection to %s:%s uses the %s protocol, which is unsafe."
+     host port protocol)))
+      (delete-process process)
+      nil)
      (t
       process))))
 


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deprecate TLS1.0 support in emacs

Andreas Schwab
On Jul 12 2017, Robert Pluim <[hidden email]> wrote:

> @@ -231,6 +231,27 @@ nsm-check-protocol
>       host port protocol)))
>        (delete-process process)
>        nil)
> +     ((and protocol
> +   (string-match "TLS1.0" protocol)
> +   (not (memq :tls1.0 (plist-get settings :conditions)))
> +   (not
> +    (nsm-query
> +     host port status :tls1.0
> +     "The connection to %s:%s uses the %s protocol, which is unsafe."
> +     host port protocol)))
> +      (delete-process process)
> +      nil)
> +     ((and protocol
> +           (eq network-security-level 'paranoid)
> +   (string-match "TLS1.1" protocol)

Why string-match?

Andreas.

--
Andreas Schwab, SUSE Labs, [hidden email]
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deprecate TLS1.0 support in emacs

Robert Pluim
Andreas Schwab <[hidden email]> writes:

> On Jul 12 2017, Robert Pluim <[hidden email]> wrote:
>
>> @@ -231,6 +231,27 @@ nsm-check-protocol
>>       host port protocol)))
>>        (delete-process process)
>>        nil)
>> +     ((and protocol
>> +   (string-match "TLS1.0" protocol)
>> +   (not (memq :tls1.0 (plist-get settings :conditions)))
>> +   (not
>> +    (nsm-query
>> +     host port status :tls1.0
>> +     "The connection to %s:%s uses the %s protocol, which is unsafe."
>> +     host port protocol)))
>> +      (delete-process process)
>> +      nil)
>> +     ((and protocol
>> +           (eq network-security-level 'paranoid)
>> +   (string-match "TLS1.1" protocol)
>
> Why string-match?

It's what the surrounding code uses to check for ssl. You'd prefer
string-equal ?

Robert


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deprecate TLS1.0 support in emacs

Lars Ingebrigtsen
In reply to this post by Robert Pluim
Robert Pluim <[hidden email]> writes:

> TLS1.0 is a seriously insecure protocol. I refrained from doing what I
> actually wanted to do, which is deprecate TLS1.1 as well. I think it's
> a disservice to allow TLS1.0 to continue to be used.

It's no more "insecure" to read lists.gnu.org via HTTPS than it is via
HTTP, which is also an option.  Denying the former while allowing the
latter is rather nonsensical.

And if it had been available only via HTTPS, then refusing Emacs users
to access it would also have a security impact: Refusing access to
information is not "security", but the opposite.

> That could be done with nsm, but only if you'll accept setting the
> default network-security-level to 'high, or adding a specific check
> for protocol version at 'medium. Option 1 looks something like this:

No, `high' should be reserved for people that want higher than normal
network security.

It might make sense to warn for TLS1.0 on `medium', though, but I'd have
to check what other web browsers do here.  I think, for instance, that
Firefox still supports TLS1.0, and gives no warning, either.  So unless
I've misunderstood the Firefox situation, I don't think we should do
anything here.

More long-term, I think it may make sense to just treat these "insecure"
protocols as if they were unencrypted, user interface wise, but that
would be up to each individual application (eww, package-list, etc) and
not further down in the network stack?  Perhaps?

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deprecate TLS1.0 support in emacs

Andreas Schwab
In reply to this post by Robert Pluim
On Jul 12 2017, Robert Pluim <[hidden email]> wrote:

> Andreas Schwab <[hidden email]> writes:
>
>> On Jul 12 2017, Robert Pluim <[hidden email]> wrote:
>>
>>> @@ -231,6 +231,27 @@ nsm-check-protocol
>>>       host port protocol)))
>>>        (delete-process process)
>>>        nil)
>>> +     ((and protocol
>>> +   (string-match "TLS1.0" protocol)
>>> +   (not (memq :tls1.0 (plist-get settings :conditions)))
>>> +   (not
>>> +    (nsm-query
>>> +     host port status :tls1.0
>>> +     "The connection to %s:%s uses the %s protocol, which is unsafe."
>>> +     host port protocol)))
>>> +      (delete-process process)
>>> +      nil)
>>> +     ((and protocol
>>> +           (eq network-security-level 'paranoid)
>>> +   (string-match "TLS1.1" protocol)
>>
>> Why string-match?
>
> It's what the surrounding code uses to check for ssl. You'd prefer
> string-equal ?

Is TLS1.10 or TLS101 unsafe?

Andreas.

--
Andreas Schwab, SUSE Labs, [hidden email]
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deprecate TLS1.0 support in emacs

Robert Pluim
Andreas Schwab <[hidden email]> writes:

>
> Is TLS1.10 or TLS101 unsafe?

Good point. The next version will be better.

Robert


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deprecate TLS1.0 support in emacs

Robert Pluim
In reply to this post by Lars Ingebrigtsen
Lars Ingebrigtsen <[hidden email]> writes:

> Robert Pluim <[hidden email]> writes:
>
>> TLS1.0 is a seriously insecure protocol. I refrained from doing what I
>> actually wanted to do, which is deprecate TLS1.1 as well. I think it's
>> a disservice to allow TLS1.0 to continue to be used.
>
> It's no more "insecure" to read lists.gnu.org via HTTPS than it is via
> HTTP, which is also an option.  Denying the former while allowing the
> latter is rather nonsensical.

This is not about reading lists.gnu.org specifically, this is about
all TLS protocol use from emacs. That should not use protocols that
contain known serious security flaws if we can avoid it. When you
choose to use https you have an expectation of security, unlike with
http, so we should attempt to fulfill that expectation.

> And if it had been available only via HTTPS, then refusing Emacs users
> to access it would also have a security impact: Refusing access to
> information is not "security", but the opposite.

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.

>> That could be done with nsm, but only if you'll accept setting the
>> default network-security-level to 'high, or adding a specific check
>> for protocol version at 'medium. Option 1 looks something like this:
>
> No, `high' should be reserved for people that want higher than normal
> network security.

OK, then we should integrate a check like this into `medium'. TLS1.0
should be warned about in the default configuration. I'd argue that
TLS1.1 should be as well, but we can always revisit that later.

I'll see if I can come up with a patch tomorrow.

> It might make sense to warn for TLS1.0 on `medium', though, but I'd have
> to check what other web browsers do here.  I think, for instance, that
> Firefox still supports TLS1.0, and gives no warning, either.  So unless
> I've misunderstood the Firefox situation, I don't think we should do
> anything here.

Firefox still allows TLS1.0, unless you configure it in paranoid mode,
like yours truly.

> More long-term, I think it may make sense to just treat these "insecure"
> protocols as if they were unencrypted, user interface wise, but that
> would be up to each individual application (eww, package-list, etc) and
> not further down in the network stack?  Perhaps?

No, we should just attempt to eradicate the use of TLS1.0 (and
TLS1.1), not allow people to keep using them :-)

I appreciate that's a strong opinion, but I definitely think we should
strongly encourage people to move away from both of these protocols.

Robert


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deprecate TLS1.0 support in emacs

Lars Ingebrigtsen
Robert Pluim <[hidden email]> 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.

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.

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 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.

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.

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deprecate TLS1.0 support in emacs

Robert Pluim
Lars Ingebrigtsen <[hidden email]> writes:

> Robert Pluim <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deprecate TLS1.0 support in emacs

Richard Stallman
In reply to this post by Lars Ingebrigtsen
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > 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.

I agree -- our software should not absolutely refuse to communicate
a way that we judge risky.  We should explain the situation and state
how to enable that method (perhaps with a user option).

  > tell the user "you tried to access this via a secure channel.  It's not,
  > but here's the ... anyway".

I agree.

  > but here's the content anyway".

Please don't use the word "content" to refer to works or publications.
The term disparages all publications.
See https://gnu.org/philosophy/words-to-avoid.html.


--
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deprecate TLS1.0 support in emacs

Robert Pluim
Richard Stallman <[hidden email]> writes:

>   > 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.
>
> I agree -- our software should not absolutely refuse to communicate
> a way that we judge risky.  We should explain the situation and state
> how to enable that method (perhaps with a user option).
>

OK. NSM provides the requisite infrastructure for that already, we
just have to enable some more checking. Here's an initial patch, we
can now decide exactly which checks we should do at medium security
level, and update the manuals. Personally I feel we should warn for
ssl, tls1.0, tls1.1, RC4, and SHA1. Diffie-Hellman I'm not too sure
about, although I'll note that Google Chrome switched to 1024 bits two
years ago.

Regards

Robert


From 6587993f682544fa2314a0d41101274a1c004ab5 Mon Sep 17 00:00:00 2001
From: Robert Pluim <[hidden email]>
Date: Thu, 13 Jul 2017 15:06:07 +0200
Subject: [PATCH] Check for SSL, TLS1.0 and TLS1.1 and warn user

* lisp/net/nsm.el (nsm-check-tls-connection): Check protocol
 parameters at the default `medium' security level
 (nsm-check-for-deprecated-protocols): New function. Abstract
 protocol version checks out of nsm-check-protocols and check for
 TLS1.0 and TLS1.1
 (nsm-check-protocol): Use it
* etc/NEWS (libraries): Document the change in tls connection
  behaviour
---
 etc/NEWS        |  7 +++++++
 lisp/net/nsm.el | 40 +++++++++++++++++++++++++++-------------
 2 files changed, 34 insertions(+), 13 deletions(-)

diff --git a/etc/NEWS b/etc/NEWS
index a00760c2f8..1880847048 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -459,6 +459,13 @@ Linum mode and all similar packages are henceforth becoming obsolete.
 Users and developers are encouraged to switch to this new feature
 instead.
 
+** Network connections which use ssl, tls1.0 or tls1.1 will now be
+warned about by the network security manager. The user will be
+prompted to allow/disallow the connection on a per-connection/per-host
+basis.  These 3 protocols have myriad proven exploits against them and
+should be avoided whenever possible.  Set network-security-level to
+'low' to disable these new checks.
+
 
 * Editing Changes in Emacs 26.1
 
diff --git a/lisp/net/nsm.el b/lisp/net/nsm.el
index 8d3463ef0a..03670957a5 100644
--- a/lisp/net/nsm.el
+++ b/lisp/net/nsm.el
@@ -120,8 +120,8 @@ nsm-verify-connection
 (defun nsm-check-tls-connection (process host port status settings)
   (let ((process (nsm-check-certificate process host port status settings)))
     (if (and process
-     (>= (nsm-level network-security-level) (nsm-level 'high)))
- ;; Do further protocol-level checks if the security is high.
+     (>= (nsm-level network-security-level) (nsm-level 'medium)))
+ ;; Do further protocol-level checks if the security is medium.
  (nsm-check-protocol process host port status settings)
       process)))
 
@@ -199,7 +199,7 @@ nsm-check-protocol
    (not
     (nsm-query
      host port status :diffie-hellman-prime-bits
-     "The Diffie-Hellman prime bits (%s) used for this connection to %s:%s is less than what is considered safe (%s)."
+     "The Diffie-Hellman prime bits (%s) used for this connection to %s:%s is less than what is considered safe (%s). Accept at your own risk."
      prime-bits host port 1024)))
       (delete-process process)
       nil)
@@ -208,7 +208,7 @@ nsm-check-protocol
    (not
     (nsm-query
      host port status :rc4
-     "The connection to %s:%s uses the RC4 algorithm (%s), which is believed to be unsafe."
+     "The connection to %s:%s uses the RC4 algorithm (%s), which is unsafe. Accept at your own risk."
      host port encryption)))
       (delete-process process)
       nil)
@@ -217,23 +217,37 @@ nsm-check-protocol
    (not
     (nsm-query
      host port status :signature-sha1
-     "The certificate used to verify the connection to %s:%s uses the SHA1 algorithm (%s), which is believed to be unsafe."
+     "The certificate used to verify the connection to %s:%s uses the SHA1 algorithm (%s), which is unsafe. Accept at your own risk."
      host port signature-algorithm)))
       (delete-process process)
       nil)
-     ((and protocol
-   (string-match "SSL" protocol)
-   (not (memq :ssl (plist-get settings :conditions)))
-   (not
-    (nsm-query
-     host port status :ssl
-     "The connection to %s:%s uses the %s protocol, which is believed to be unsafe."
-     host port protocol)))
+     ((let ((what (nsm-check-for-deprecated-protocols protocol settings)))
+        (and protocol
+             what
+     (not
+      (nsm-query
+       host port status what
+       "The connection to %s:%s uses the %s protocol, which is unsafe. Accept at your own risk."
+       host port protocol))))
       (delete-process process)
       nil)
      (t
       process))))
 
+(defun nsm-check-for-deprecated-protocols (protocol settings)
+  (cond
+   ((and (string-match "SSL" protocol)
+         (not (memq :ssl (plist-get settings :conditions))))
+    :ssl)
+   ((and (string-equal "TLS1.0" protocol)
+         (not (memq :tls1.0 (plist-get settings :conditions))))
+    :tls1.0)
+   ((and (string-equal "TLS1.1" protocol)
+         (not (memq :tls1.1 (plist-get settings :conditions))))
+    :tls1.1)
+   (t
+    nil)))
+
 (defun nsm-fingerprint (status)
   (plist-get (plist-get status :certificate) :public-key-id))
 
--
2.13.0.rc0

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deprecate TLS1.0 support in emacs

Robert Pluim
Robert Pluim <[hidden email]> writes:

> Richard Stallman <[hidden email]> writes:
>
>> I agree -- our software should not absolutely refuse to communicate
>> a way that we judge risky.  We should explain the situation and state
>> how to enable that method (perhaps with a user option).
>>
>
> OK. NSM provides the requisite infrastructure for that already, we
> just have to enable some more checking. Here's an initial patch, we
> can now decide exactly which checks we should do at medium security
> level, and update the manuals. Personally I feel we should warn for
> ssl, tls1.0, tls1.1, RC4, and SHA1. Diffie-Hellman I'm not too sure
> about, although I'll note that Google Chrome switched to 1024 bits two
> years ago.

Ping? I'd like to improve the default communication security settings
of Emacs, the current state is too insecure for my liking.

Regards

Robert

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deprecate TLS1.0 support in emacs

Lars Ingebrigtsen
Robert Pluim <[hidden email]> writes:

> Ping? I'd like to improve the default communication security settings
> of Emacs, the current state is too insecure for my liking.

My feeling, as I think I said, is that it's premature to warn about
things like TLS1.0 in an intrusive manner.  There's too many sites out
there that still use that protocol, and warning too much is no help for
our users.

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deprecate TLS1.0 support in emacs

Robert Pluim
Lars Ingebrigtsen <[hidden email]> writes:

> Robert Pluim <[hidden email]> writes:
>
>> Ping? I'd like to improve the default communication security settings
>> of Emacs, the current state is too insecure for my liking.
>
> My feeling, as I think I said, is that it's premature to warn about
> things like TLS1.0 in an intrusive manner.  There's too many sites out
> there that still use that protocol, and warning too much is no help for
> our users.

There are still many sites like that, but if we don't warn people
about them, there will never be any pressure on their owners to
upgrade to TLS1.2, or stop using SHA-1, or increase DH key size.

How about warning as in my patch, but only at network-security-level
>= high? And revisit the level later?

Regards

Robert

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deprecate TLS1.0 support in emacs

Paul Eggert
In reply to this post by Lars Ingebrigtsen
Lars Ingebrigtsen wrote:
> it's premature to warn about
> things like TLS1.0 in an intrusive manner.  There's too many sites out
> there that still use that protocol, and warning too much is no help for
> our users

Last year I would have agreed, but nowadays I think it'd be better to warn about
TLS 1.0 somehow. According to https://www.ssllabs.com/ssl-pulse/ from July 2016
to July 2017 TLS v1.2 support climbed from 78.3% to 87.3%, whereas support for
TLS v1.0 dropped from 97.3% to to 93.4% as the higher-end sites tighten up
security. By the time the next version of Emacs comes out, it looks like a mild
warning about TLS v1.0 will be appropriate.

For what it's worth, I surf the web mostly via Firefox configured to use only
TLS v1.1 or higher, which is stricter than what's being proposed for Emacs. Only
once in the last month did I run into problems with this - it was an older
internal UCLA website that hadn't been upgraded, and which upgraded immediately
after I notified its administrators.  So at least for me, a warning from Emacs
would have been more helpful, had I been using Emacs.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deprecate TLS1.0 support in emacs

Lars Ingebrigtsen
Paul Eggert <[hidden email]> writes:

> Last year I would have agreed, but nowadays I think it'd be better to
> warn about TLS 1.0 somehow. According to
> https://www.ssllabs.com/ssl-pulse/ from July 2016 to July 2017 TLS
> v1.2 support climbed from 78.3% to 87.3%, whereas support for TLS v1.0
> dropped from 97.3% to to 93.4% as the higher-end sites tighten up
> security. By the time the next version of Emacs comes out, it looks
> like a mild warning about TLS v1.0 will be appropriate.

Yes, I agree.  eww, for instance, could remove the green URL when using
TLS 1.0, etc.  But the proposed NSM warning (which would make the user
answer "y" to a direct question about the TLS-ness) is too heavy, in my
opinion.

But having the warning on the `high' NSM setting is fine with me, and
I'll see what I can do about removing green URLs from eww...

Other services, like SMTP/IMAP/etc will have to invent other
"lightweight" ways to tell the user that the content is on the insecure
side.

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deprecate TLS1.0 support in emacs

Robert Pluim
Lars Ingebrigtsen <[hidden email]> writes:

> Paul Eggert <[hidden email]> writes:
>
>> Last year I would have agreed, but nowadays I think it'd be better to
>> warn about TLS 1.0 somehow. According to
>> https://www.ssllabs.com/ssl-pulse/ from July 2016 to July 2017 TLS
>> v1.2 support climbed from 78.3% to 87.3%, whereas support for TLS v1.0
>> dropped from 97.3% to to 93.4% as the higher-end sites tighten up
>> security. By the time the next version of Emacs comes out, it looks
>> like a mild warning about TLS v1.0 will be appropriate.
>
> Yes, I agree.  eww, for instance, could remove the green URL when using
> TLS 1.0, etc.  But the proposed NSM warning (which would make the user
> answer "y" to a direct question about the TLS-ness) is too heavy, in my
> opinion.

OK. I happen to like NSM, mainly because I like explicit and detailed
messages from my tools, rather than having them change visual
indicators, but mileage obviously varies.

> But having the warning on the `high' NSM setting is fine with me, and
> I'll see what I can do about removing green URLs from eww...

Is that an offer to commit my patch? :-)

There's 🔐 and 🔓 you can use if you feel like getting fancy. Changing
the colour of the URL doesn't speak to me very much.

> Other services, like SMTP/IMAP/etc will have to invent other
> "lightweight" ways to tell the user that the content is on the insecure
> side.

I'm not sure how you can signal that someone's SMTP/IMAP session is
using an insecure protocol without ending up back at NSM.

Robert

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deprecate TLS1.0 support in emacs

Stefan Monnier
In reply to this post by Lars Ingebrigtsen
> Yes, I agree.  eww, for instance, could remove the green URL when using
> TLS 1.0, etc.  But the proposed NSM warning (which would make the user
> answer "y" to a direct question about the TLS-ness) is too heavy, in my
> opinion.

Could we replace the prompt with a simple message (and if the message
gets overwritten too soon, maybe adding a short delay)?


        Stefan


123
Loading...