A couple of questions and concerns about Emacs network security

A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

Hi everyone,

I've been digging around Emacs' network security settings lately and
I've noticed a couple of oddities. I was wondering what the reasos are
and if there are any plans to improve them.

For `--with-gnutls` builds using GnuTLS 3.5.18:

1. `gnutls-verify-error` is set to nil by default, so server certs
   aren't verified by default.
2. `gnutls-min-prime-bits` has been 256 by default since 2012, whereas
   a reasonable number should probably be 2048 in 2018.
3. `gnutls-algorithm-priority` is nil by default.

All of this means there's zero network security OTTB for Emacs. After
some experimentation, I've come up with the following settings that
brings the balance of default security and compatibility to as good as I
could:

    (setq gnutls-algorithm-priority
          "SECURE192:+SECURE128:-VERS-ALL:+VERS-TLS1.2:%PROFILE_MEDIUM"
          gnutls-min-prime-bits 2048
          gnutl-verify-error t)

However, this setting still fail the following tests rather alarmingly:

    (mapcar (lambda (host)
              (ignore-errors (url-retrieve-synchronously host)))
            '("https://revoked.badssl.com/"
              "https://pinning-test.badssl.com/"
              "https://invalid-expected-sct.badssl.com/"))

    ;; This should return a list of `'(nil nil nil)`, but doesn't.

My questions are:

1. Can we update the default network security settings?
2. Now that `starttls.el` and `tls.el` are obsolete, and GnuTLS doesn't
   seem to be doing a very good job, can we link to something better
   maintained, such as OpenSSL/LibreSSL/BoringSSL/NSS?

Lastly, I notice there's this thing call `nsm.el` seemingly
doing redundant checks if your TLS settings are reasonable, what's the
history of it and why is it not obsolete when `tls.el` and `starttls.el`
are?

Thanks in advance,

Jimmy Wong

Re: A couple of questions and concerns about Emacs network security

[Paul Eggert]

On 06/22/2018 03:00 PM, Jimmy Yuen Ho Wong wrote:
> 1. Can we update the default network security settings?

Yes, I would think so, in the master branch. As you say, the current 
defaults are inappropriate for today's users.

> 2. Now that `starttls.el` and `tls.el` are obsolete, and GnuTLS doesn't
>     seem to be doing a very good job, can we link to something better
>     maintained, such as OpenSSL/LibreSSL/BoringSSL/NSS?

I would think the answer to that could be "yes" too. Despite its name, 
GnuTLS is no longer GNU code, and we're under no obligation to promote 
it. However, this would take some work. We'd surely want the option to 
link to either GnuTLS or OpenSSL/etc.

> there's this thing call `nsm.el` seemingly
> doing redundant checks if your TLS settings are reasonable, what's the
> history of it and why is it not obsolete when `tls.el` and `starttls.el`
> are?

Lars is the person to ask about that. I'll CC: him.

Re: A couple of questions and concerns about Emacs network security

[Lars Ingebrigtsen]

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 06/22/2018 03:00 PM, Jimmy Yuen Ho Wong wrote:
>> 1. Can we update the default network security settings?
>
> Yes, I would think so, in the master branch. As you say, the current
> defaults are inappropriate for today's users.

They are?  In what way?

>> there's this thing call `nsm.el` seemingly doing redundant checks if
>> your TLS settings are reasonable, what's the history of it and why is
>> it not obsolete when `tls.el` and `starttls.el` are?
>
> Lars is the person to ask about that. I'll CC: him.

They are not redundant checks.  Emacs lets network actions happen, and
then passes the result to nsm.el, which is very similar to how all other
applications do this stuff (Firefox etc).

The Emacs Network Security Manager does the user interface job handling
various classes of (insecure) network access classes.  Are there places
where it fails to do its job?

You'd set `gnutls-verify-error' and friends only if you don't want to
query the user for how to handle TLS-related problems, but fail
immediately.  But that's not a good default for an interactive
application.

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

Re: A couple of questions and concerns about Emacs network security

[Lars Ingebrigtsen]

OK, I've now read the original email message, and there seems to be a
fundamental misunderstanding.

Network security management is done by nsm.el, not by the underlying
libraries.  The NSM provides, as the name implies, network security, and
does stuff like certificate pinning and warns you if a STARTTLS
connection has degraded to a non-TLS connection (which, of course, the
gnutls.el functions can't do on its own).

Perhaps the doc strings of gnutls.el should mention that the variables
is provides are useful only if you don't use `open-network-stream' and
call the low-level functions directly...

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

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

On 23/06/2018 00:33, Lars Ingebrigtsen wrote:
> OK, I've now read the original email message, and there seems to be a
> fundamental misunderstanding.

Ok I see why NSM was written now. It's basically works like browsers
used to work before Snowden. However, while I think the intention was
good, as there are some good checks in there, I think it still falls far
short from ideal.

NSM is heavily dependent on GnuTLS, and it's not particularly good at
presenting NSM good peer status for NSM to do something about it. For
example, leaving all `nsm` and `gnutls` settings at default, this is a
list of URLs where NSM failed to ask me if I wanted to trust the cert.

    (mapcar (lambda (host) (ignore-errors (url-retrieve-synchronously
host)))
         '("https://expired.badssl.com/"
           "https://wrong.host.badssl.com/"
           "https://self-signed.badssl.com/"
           "https://untrusted-root.badssl.com/"
           "https://revoked.badssl.com/"                  ;; fail, very
concerning
           "https://pinning-test.badssl.com/"             ;; fail, very
concerning
           "https://sha1-intermediate.badssl.com/"        ;; fail, very
concerning
           "https://rc4-md5.badssl.com/"
           "https://rc4.badssl.com/"
           "https://3des.badssl.com/"                     ;; fail
           "https://null.badssl.com/"
           "https://mozilla-old.badssl.com/"              ;; fail
           "https://dh480.badssl.com/"                    ;; fail
           "https://dh512.badssl.com/"                    ;; fail
           "https://dh-small-subgroup.badssl.com/"        ;; fail
           "https://dh-composite.badssl.com/"             ;; fail
           "https://invalid-expected-sct.badssl.com/"     ;; fail, a bit
concerning
           "https://subdomain.preloaded-hsts.badssl.com/"
           "https://superfish.badssl.com/"
           "https://edellroot.badssl.com/"
           "https://dsdtestprovider.badssl.com/"
           "https://preact-cli.badssl.com/"
           "https://webpack-dev-server.badssl.com/"
           "https://captive-portal.badssl.com/"
           "https://mitm-software.badssl.com/"
           "https://sha1-2017.badssl.com/"))

If I set `network-security-level` to `'high`, only the dh480 and dh512
tests passed. At the very least, NSM should ask me for the 3 very
concerning certs. Even if I set `gnutls-algorithm-priority` to
`SECURE192:+SECURE128:-VERS-ALL:+VERS-TLS1.2:%PROFILE_MEDIUM`, revoked
and pinning are still failing. I don't see how you are going to get
around that without reinventing CRL and HPKP in ELISP.
> Perhaps the doc strings of gnutls.el should mention that the variables
> is provides are useful only if you don't use `open-network-stream' and
> call the low-level functions directly...
Yes this is a very good idea. I don't think anybody on Reddit
understands how to twiddle Emacs's network security knobs to make it do
what it's supposed to do.

Jimmy

Re: A couple of questions and concerns about Emacs network security

[Lars Ingebrigtsen]

Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:

> NSM is heavily dependent on GnuTLS, and it's not particularly good at
> presenting NSM good peer status for NSM to do something about it. For
> example, leaving all `nsm` and `gnutls` settings at default, this is a
> list of URLs where NSM failed to ask me if I wanted to trust the cert.
>
>            "https://revoked.badssl.com/"                  ;; fail, very
> concerning

Yes, Emacs should support the Online Certificate Status Protocol;
patches welcome...

>            "https://pinning-test.badssl.com/"             ;; fail, very
> concerning

For those who don't know what this is: Some browsers now ship with
built-in lists of certificate hashes, so if you're visiting that site
and presented with a different than expected certificate, you'll know
that somebody else has issued a certificate for the site, and somebody
has hijacked the connection.

Or, perhaps, that they just lost the private key and had to generate a
new certificate and now, oops, everybody that uses the browsers with the
built-in list will be unable to visit the site.

If Emacs is to do the HPKP (HTTP Public Key Pinning) thing, we can't
really do that in the Emacs distribution itself, since Emacs is released
so seldom.  It makes sense for Chrome, which has a new release every
three days (it sometimes seems like), but Emacs could do this via ELPA,
I think.  Whether it's worth doing is another issue; I think the jury is
still out on that one...

HPKP is also a "trust on first use" thing, where there's a HTTP header
that instructs the user agent to pin the certificate.  Since the NSM
already has public key pinning implemented, if we want to support this,
I think it might make sense to implement this on the url.el level --
make it call out to the NSM and ask it to pin a certificate if it
detects the header.

>            "https://sha1-intermediate.badssl.com/"        ;; fail, very
> concerning

We discussed the sha1 authority thing last year and our conclusion was
that we should move the sha1 check to `medium', and then I just forgot
to do it.  Sorry!  I should have filed a bug report to remind myself...

>            "https://3des.badssl.com/"                     ;; fail
>            "https://mozilla-old.badssl.com/"              ;; fail
>            "https://dh-small-subgroup.badssl.com/"        ;; fail
>            "https://dh-composite.badssl.com/"             ;; fail

These are all types of crypto that are now considered to probably be
easy to hack by state actors (and others with a beefy laptop,
probably).  When we discussed these previously, we wondered whether we
should do more layering of how we present these issues beyond warn/don't
warn.

For instance, Firefox happily accepts 3des.badssl.com and gives no
warning, but it's kinda weak.  Should the NSM propagate this information
up to the calling application and then it could do... something?  For
instance, eww will display "secure" content with a green title bar.
Should eww remove that stamp of approval from weak sites, even if we
don't warn the user about it?

I think so.

>            "https://dh480.badssl.com/"                    ;; fail
>            "https://dh512.badssl.com/"                    ;; fail

These ones should be warned about on the `medium' level, I think,
because they're really weak.

>            "https://invalid-expected-sct.badssl.com/"     ;; fail, a bit
> concerning

Oh, geez, another TLA.  This one is Signed Certificate Timestamps
(SCTs), and is something I didn't know existed.  :-)  Neither does
Firefox, so I think we're on the same level here.

> If I set `network-security-level` to `'high`, only the dh480 and dh512
> tests passed.

Oh, there's no test for dh480 and dh512 at all?  That should, indeed, be
fixed. 

> I don't see how you are going to get around that without reinventing
> CRL and HPKP in ELISP.

HPKP is trivail to implement, I think?  Especially in Lisp.

The Certificate Revocation List and the pre-shipped HPKP thing is also
easy to do; you just have to find a volunteer to update an ELPA package
with the info...

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

Re: A couple of questions and concerns about Emacs network security

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> We discussed the sha1 authority thing last year and our conclusion was
> that we should move the sha1 check to `medium', and then I just forgot
> to do it.  Sorry!  I should have filed a bug report to remind myself...

And now I remember why I didn't: I meant to refactor the protocol checks
in nsm.el so that they're more easily extensible and also allow the user
more fine-grained control of what protocol issues they care about.
Something like

(defvar network-security-tls-problems
        '((low-diffie-hellman-prime-bits medium)
          (rc4 low)
          (dh-small-subgroup high)))

or something, and then a separate function for each of these tests to
avoid an ever-growing huge function with a `cond' in it, and also allow
users to add their own tests.

I'll bug report it to remind myself...

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

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

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

There are more problems with NSM than just these tests. One other thing I
can think of is, if I've set `gnutls-min-prime-bits` to 2048, and presented
with a cert with 1536 bits, NSM does nothing for me.

What I'm getting at is, it's all well and fine if you can fix these issues
in LISP, but if you are going to implement a real network security layer
anyway, might as well switch to an underlying library that'll do all these
for you, both from a performance perspective, and the advantage of not
having a emacs-speed cycle for security related issues.


On Sat, Jun 23, 2018 at 11:23 AM, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:
>
> > NSM is heavily dependent on GnuTLS, and it's not particularly good at
> > presenting NSM good peer status for NSM to do something about it. For
> > example, leaving all `nsm` and `gnutls` settings at default, this is a
> > list of URLs where NSM failed to ask me if I wanted to trust the cert.
> >
> >            "https://revoked.badssl.com/"                  ;; fail, very
> > concerning
>
> Yes, Emacs should support the Online Certificate Status Protocol;
> patches welcome...
>
> >            "https://pinning-test.badssl.com/"             ;; fail, very
> > concerning
>
> For those who don't know what this is: Some browsers now ship with
> built-in lists of certificate hashes, so if you're visiting that site
> and presented with a different than expected certificate, you'll know
> that somebody else has issued a certificate for the site, and somebody
> has hijacked the connection.
>
> Or, perhaps, that they just lost the private key and had to generate a
> new certificate and now, oops, everybody that uses the browsers with the
> built-in list will be unable to visit the site.
>
> If Emacs is to do the HPKP (HTTP Public Key Pinning) thing, we can't
> really do that in the Emacs distribution itself, since Emacs is released
> so seldom.  It makes sense for Chrome, which has a new release every
> three days (it sometimes seems like), but Emacs could do this via ELPA,
> I think.  Whether it's worth doing is another issue; I think the jury is
> still out on that one...
>
> HPKP is also a "trust on first use" thing, where there's a HTTP header
> that instructs the user agent to pin the certificate.  Since the NSM
> already has public key pinning implemented, if we want to support this,
> I think it might make sense to implement this on the url.el level --
> make it call out to the NSM and ask it to pin a certificate if it
> detects the header.
>
> >            "https://sha1-intermediate.badssl.com/"        ;; fail, very
> > concerning
>
> We discussed the sha1 authority thing last year and our conclusion was
> that we should move the sha1 check to `medium', and then I just forgot
> to do it.  Sorry!  I should have filed a bug report to remind myself...
>
> >            "https://3des.badssl.com/"                     ;; fail
> >            "https://mozilla-old.badssl.com/"              ;; fail
> >            "https://dh-small-subgroup.badssl.com/"        ;; fail
> >            "https://dh-composite.badssl.com/"             ;; fail
>
> These are all types of crypto that are now considered to probably be
> easy to hack by state actors (and others with a beefy laptop,
> probably).  When we discussed these previously, we wondered whether we
> should do more layering of how we present these issues beyond warn/don't
> warn.
>
> For instance, Firefox happily accepts 3des.badssl.com and gives no
> warning, but it's kinda weak.  Should the NSM propagate this information
> up to the calling application and then it could do... something?  For
> instance, eww will display "secure" content with a green title bar.
> Should eww remove that stamp of approval from weak sites, even if we
> don't warn the user about it?
>
> I think so.
>
> >            "https://dh480.badssl.com/"                    ;; fail
> >            "https://dh512.badssl.com/"                    ;; fail
>
> These ones should be warned about on the `medium' level, I think,
> because they're really weak.
>
> >            "https://invalid-expected-sct.badssl.com/"     ;; fail, a bit
> > concerning
>
> Oh, geez, another TLA.  This one is Signed Certificate Timestamps
> (SCTs), and is something I didn't know existed.  :-)  Neither does
> Firefox, so I think we're on the same level here.
>
> > If I set `network-security-level` to `'high`, only the dh480 and dh512
> > tests passed.
>
> Oh, there's no test for dh480 and dh512 at all?  That should, indeed, be
> fixed.
>
> > I don't see how you are going to get around that without reinventing
> > CRL and HPKP in ELISP.
>
> HPKP is trivail to implement, I think?  Especially in Lisp.
>
> The Certificate Revocation List and the pre-shipped HPKP thing is also
> easy to do; you just have to find a volunteer to update an ELPA package
> with the info...
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>

[-- Attachment #2: Type: text/html, Size: 7432 bytes --]

Re: A couple of questions and concerns about Emacs network security

[Lars Ingebrigtsen]

Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:

> There are more problems with NSM than just these tests. One other
> thing I can think of is, if I've set `gnutls-min-prime-bits` to 2048,
> and presented with a cert with 1536 bits, NSM does nothing for me.

It's not supposed to -- the connection is stopped at the gnutls level.
Which is why that variable defaults to 256, so that the NSM can handle
the problem.

> What I'm getting at is, it's all well and fine if you can fix these
> issues in LISP, but if you are going to implement a real network
> security layer anyway, might as well switch to an underlying library
> that'll do all these for you, both from a performance perspective, and
> the advantage of not having a emacs-speed cycle for security related
> issues.

No, these are user interface issues, and changing libraries does nothing
to help with that.

But instead of me re-arguing that case, you can just read

https://lars.ingebrigtsen.no/2014/12/01/the-emacs-network-security-manager/

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

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

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

On Sat, Jun 23, 2018 at 12:32 PM, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:
>
> > There are more problems with NSM than just these tests. One other
> > thing I can think of is, if I've set `gnutls-min-prime-bits` to 2048,
> > and presented with a cert with 1536 bits, NSM does nothing for me.
>
> It's not supposed to -- the connection is stopped at the gnutls level.
> Which is why that variable defaults to 256, so that the NSM can handle
> the problem.
>

How about moving the min-prime-bits knob over to NSM so it can warn instead
of silently bypassing it by fiddling options directly related to GnuTLS? I
also notice there's a `nsm-noninteractive`  var, it's only used in 1 place
so far. Can we defcustom it and sprinkle a check for this var strategically
such that people who are using Emacs in a script can still do it without
fiddling with the GnuTLS options? In fact, what if we merged all the NSM
and GnuTLS options into NSM so various modules can rely on it as a central
point of control?

[-- Attachment #2: Type: text/html, Size: 1507 bytes --]

Re: A couple of questions and concerns about Emacs network security

[Lars Ingebrigtsen]

Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:

>  It's not supposed to -- the connection is stopped at the gnutls level.
>  Which is why that variable defaults to 256, so that the NSM can handle
>  the problem.
>
> How about moving the min-prime-bits knob over to NSM so it can warn
> instead of silently bypassing it by fiddling options directly related
> to GnuTLS?

The NSM does warn about this.  Unless you've fiddled with the options,
which you've chosen to do yourself.

The low-level variables doc strings should mention that you're not
supposed to fiddle with them unless you have very specific needs and
point you to the NSM instead.

> I also notice there's a `nsm-noninteractive` var, it's only used in 1
> place so far. Can we defcustom it and sprinkle a check for this var
> strategically such that people who are using Emacs in a script can
> still do it without fiddling with the GnuTLS options? In fact, what if
> we merged all the NSM and GnuTLS options into NSM so various modules
> can rely on it as a central point of control?

Well...  The low-level variables (which probably shouldn't be
defcustoms) are useful in some scenarios.  If you're writing an
application that needs very specific connection parameters, you have to
be able to pass them in to the library.  let-binding them provides that
flexibility.

I don't think `nsm-noninteractive' should be a defcustom, but perhaps
there should be a `quit' value to `network-security-level' that just
aborts on any network strangeness without querying the user.

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

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sat, 23 Jun 2018 14:05:29 +0200
> Cc: Paul Eggert <eggert@cs.ucla.edu>, emacs-devel@gnu.org
> 
> The low-level variables doc strings should mention that you're not
> supposed to fiddle with them unless you have very specific needs and
> point you to the NSM instead.

I'd like us to make that change on the emacs-26 branch ASAP.  Can you
point me to those variables, or tell how I decide which ones should
have this note, and also suggest the wording for the reference to NSM?
(Alternatively, feel free to do this yourself ;-)

Thanks.

Re: A couple of questions and concerns about Emacs network security

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I'd like us to make that change on the emacs-26 branch ASAP.  Can you
> point me to those variables, or tell how I decide which ones should
> have this note, and also suggest the wording for the reference to NSM?
> (Alternatively, feel free to do this yourself ;-)

I'll try to get around to doing the doc fixes on the emacs-26 branch
tomorrow, which I hope is sufficiently ASAP.  :-)

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

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: wyuenho@gmail.com,  eggert@cs.ucla.edu,  emacs-devel@gnu.org
> Date: Sat, 23 Jun 2018 14:15:32 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I'd like us to make that change on the emacs-26 branch ASAP.  Can you
> > point me to those variables, or tell how I decide which ones should
> > have this note, and also suggest the wording for the reference to NSM?
> > (Alternatively, feel free to do this yourself ;-)
> 
> I'll try to get around to doing the doc fixes on the emacs-26 branch
> tomorrow, which I hope is sufficiently ASAP.  :-)

It definitely is, TIA.

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> Date: Sat, 23 Jun 2018 15:26:56 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: eggert@cs.ucla.edu, wyuenho@gmail.com, emacs-devel@gnu.org
> 
> > From: Lars Ingebrigtsen <larsi@gnus.org>
> > Cc: wyuenho@gmail.com,  eggert@cs.ucla.edu,  emacs-devel@gnu.org
> > Date: Sat, 23 Jun 2018 14:15:32 +0200
> > 
> > Eli Zaretskii <eliz@gnu.org> writes:
> > 
> > > I'd like us to make that change on the emacs-26 branch ASAP.  Can you
> > > point me to those variables, or tell how I decide which ones should
> > > have this note, and also suggest the wording for the reference to NSM?
> > > (Alternatively, feel free to do this yourself ;-)
> > 
> > I'll try to get around to doing the doc fixes on the emacs-26 branch
> > tomorrow, which I hope is sufficiently ASAP.  :-)
> 
> It definitely is, TIA.

Lars, looks like "tomorrow" never happened?  Is there any ETA?  My
offer to help with this still stands, provided that you point me to
the right variables.

Thanks.

Re: A couple of questions and concerns about Emacs network security

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> > > I'd like us to make that change on the emacs-26 branch ASAP.  Can you
>> > > point me to those variables, or tell how I decide which ones should
>> > > have this note, and also suggest the wording for the reference to NSM?
>> > > (Alternatively, feel free to do this yourself ;-)
>> > 
>> > I'll try to get around to doing the doc fixes on the emacs-26 branch
>> > tomorrow, which I hope is sufficiently ASAP.  :-)
>> 
>> It definitely is, TIA.
>
> Lars, looks like "tomorrow" never happened?  Is there any ETA?  My
> offer to help with this still stands, provided that you point me to
> the right variables.

I thought I did them?  Did I forget to push them?  Let's see..

Gah!  I did.  I've now pushed the doc fixes to the emacs-26 branch.

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

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: eggert@cs.ucla.edu,  wyuenho@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 08 Jul 2018 16:01:57 +0200
> 
> > Lars, looks like "tomorrow" never happened?  Is there any ETA?  My
> > offer to help with this still stands, provided that you point me to
> > the right variables.
> 
> I thought I did them?  Did I forget to push them?  Let's see..
> 
> Gah!  I did.  I've now pushed the doc fixes to the emacs-26 branch.

Thanks.

This bit confuses me:

  +This variable can be useful for modifying low-level TLS
  +connection parameters (for instance if you need to connect to a
  +host that only accepts a specific algorithm), but general Emacs
  +network security is handled by the Network Security Manager.

The "but" part confuses me: did you mean "however", perhaps?  That is,
did you mean to say that the default is nil so that the NSM could do
its job under user control?

Re: A couple of questions and concerns about Emacs network security

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> This bit confuses me:
>
>   +This variable can be useful for modifying low-level TLS
>   +connection parameters (for instance if you need to connect to a
>   +host that only accepts a specific algorithm), but general Emacs
>   +network security is handled by the Network Security Manager.
>
> The "but" part confuses me: did you mean "however", perhaps?  That is,
> did you mean to say that the default is nil so that the NSM could do
> its job under user control?

Yup.

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

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: eggert@cs.ucla.edu,  wyuenho@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 08 Jul 2018 17:06:29 +0200
> 
> >   +This variable can be useful for modifying low-level TLS
> >   +connection parameters (for instance if you need to connect to a
> >   +host that only accepts a specific algorithm), but general Emacs
> >   +network security is handled by the Network Security Manager.
> >
> > The "but" part confuses me: did you mean "however", perhaps?  That is,
> > did you mean to say that the default is nil so that the NSM could do
> > its job under user control?
> 
> Yup.

OK, I clarified that.

Thanks.

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

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

On Sat, Jun 23, 2018 at 1:05 PM, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:
>
> >  It's not supposed to -- the connection is stopped at the gnutls level.
> >  Which is why that variable defaults to 256, so that the NSM can handle
> >  the problem.
> >
> > How about moving the min-prime-bits knob over to NSM so it can warn
> > instead of silently bypassing it by fiddling options directly related
> > to GnuTLS?
>
> The NSM does warn about this.  Unless you've fiddled with the options,
> which you've chosen to do yourself.
>
> The low-level variables doc strings should mention that you're not
> supposed to fiddle with them unless you have very specific needs and
> point you to the NSM instead.
>


Let me spell this out clearer:

Currently `network-security-level` 'high and above *only* checks for the
case with prime bits < 1024. I can't fine tune the specific checks (very
much necessary given Emacs' release cycle) in `network-security-level` to
something like:

    (setq gnutls-algorithm-priority "SECURE192:+SECURE128:-VERS-AL
L:+VERS-TLS1.2:%PROFILE_MEDIUM"
             gnutls-min-prime-bits 2048)

**AND** have NSM warn me if I'm presented a 3DES cert or a cert with a DH
prime between 1024 and 2048.

What I'm proposing is, very similar to what you think should happen, but
even straighter, and unified in terms of the UX - Emacs should talk to
GnuTLS the C lib using as low a setting as reasonable, so you can do the
checks in NSM, checks such as does the cypher or MAC in this cert satisfy
the GnuTLS priority string? Did DH exchange use a lower than specified
prime bits?



> I don't think `nsm-noninteractive' should be a defcustom, but perhaps
> there should be a `quit' value to `network-security-level' that just
> aborts on any network strangeness without querying the user.
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>


We can keep the current behavior of silencing NSM by `(setq
gnutls-verify-error t)`, but rename it to `nsm-noninteractive` or something
like that.

By unifying NSM and GnuTLS knobs, in interactive sessions, we can still ask
the user whether he should trust the cert if it violates the user's
preference, because as you say, "only the user can really say whether
visiting a web site that has a problematic certificate is justified or
not.". In non-interactive sessions, whatever `gnutls-verify-error` becomes
controls it all.

I'm probably bikeshedding here a bit, but I think having better named
variables and intuitive OTTB behavior is vastly better than documentation.
I hope you don't mind.

[-- Attachment #2: Type: text/html, Size: 4194 bytes --]

Re: A couple of questions and concerns about Emacs network security

[Lars Ingebrigtsen]

Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:

> Currently `network-security-level` 'high and above *only* checks for the case
> with prime bits < 1024. I can't fine tune the specific checks (very much
> necessary given Emacs' release cycle) in `network-security-level` to
> something like:
>
>     (setq gnutls-algorithm-priority
> "SECURE192:+SECURE128:-VERS-ALL:+VERS-TLS1.2:%PROFILE_MEDIUM"
>              gnutls-min-prime-bits 2048)
>
> **AND** have NSM warn me if I'm presented a 3DES cert or a cert with a DH
> prime between 1024 and 2048.

Like I said in a different email, I'll be rewriting the checks to allow
the user to add as fine-grained checks they want to the NSM via
something like:

(defvar network-security-tls-problems
        '((low-diffie-hellman-prime-bits medium)
          (rc4 low)
          (dh-small-subgroup high)))

But you'd leave the gnutls variables alone.

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

Re: A couple of questions and concerns about Emacs network security

[Perry E. Metzger]

Old thread, but I thought I'd reply on it.

On Sat, 23 Jun 2018 12:23:31 +0200 Lars Ingebrigtsen <larsi@gnus.org>
wrote:
> For those who don't know what this is: Some browsers now ship with
> built-in lists of certificate hashes, so if you're visiting that
> site and presented with a different than expected certificate,
> you'll know that somebody else has issued a certificate for the
> site, and somebody has hijacked the connection.
> 
> Or, perhaps, that they just lost the private key and had to
> generate a new certificate and now, oops, everybody that uses the
> browsers with the built-in list will be unable to visit the site.

What you depict there never happens. People don't lose keys in such
circumstances.

Pinning is what is done by sites like gmail to prevent third world
dictatorships from using stolen certificate credentials to spy on
their citizens. People who have been victims of this have had their
email read, been arrested by state security forces for dissent, and
have been tortured to death for lack of certificate pinning working
in their browsers.

This is a matter of life and death for many people.

> do this via ELPA, I think.  Whether it's worth doing is another
> issue; I think the jury is still out on that one...

Do you think it's worth keeping people from quite literally being
tortured to death?

For most of the secure HTTP stuff we've been discussing, I would far
rather be inconvenienced here and there than know my slight extra
convenience was being paid for in human blood.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> Date: Thu, 5 Jul 2018 09:33:46 -0400
> From: "Perry E. Metzger" <perry@piermont.com>
> Cc: Paul Eggert <eggert@cs.ucla.edu>, Jimmy Yuen Ho Wong <wyuenho@gmail.com>,
> 	emacs-devel@gnu.org
> 
> Pinning is what is done by sites like gmail to prevent third world
> dictatorships from using stolen certificate credentials to spy on
> their citizens. People who have been victims of this have had their
> email read, been arrested by state security forces for dissent, and
> have been tortured to death for lack of certificate pinning working
> in their browsers.
> 
> This is a matter of life and death for many people.
> 
> > do this via ELPA, I think.  Whether it's worth doing is another
> > issue; I think the jury is still out on that one...
> 
> Do you think it's worth keeping people from quite literally being
> tortured to death?
> 
> For most of the secure HTTP stuff we've been discussing, I would far
> rather be inconvenienced here and there than know my slight extra
> convenience was being paid for in human blood.

It isn't the Emacs way to second-guess our users' needs, definitely
not to decide for them what is and what isn't a matter of life and
death for them.  We provide options with some reasonable defaults, and
then let users make informed decisions which defaults are not good
enough for them.

It is IMO unreasonable to make our defaults match what happens in
dictatorships that you describe, because that would unnecessarily
inconvenience the majority of the users.  Let's not follow the bad
example of the TSA (whose rationale is, unsurprisingly, also matters
of life and death).

Re: A couple of questions and concerns about Emacs network security

[Perry E. Metzger]

On Thu, 05 Jul 2018 16:49:30 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
> > Date: Thu, 5 Jul 2018 09:33:46 -0400
> > From: "Perry E. Metzger" <perry@piermont.com>
> > Cc: Paul Eggert <eggert@cs.ucla.edu>, Jimmy Yuen Ho Wong
> > <wyuenho@gmail.com>, emacs-devel@gnu.org
> > 
> > Pinning is what is done by sites like gmail to prevent third world
> > dictatorships from using stolen certificate credentials to spy on
> > their citizens. People who have been victims of this have had
> > their email read, been arrested by state security forces for
> > dissent, and have been tortured to death for lack of certificate
> > pinning working in their browsers.
> > 
> > This is a matter of life and death for many people.
> >   
> > > do this via ELPA, I think.  Whether it's worth doing is another
> > > issue; I think the jury is still out on that one...  
> > 
> > Do you think it's worth keeping people from quite literally being
> > tortured to death?
> > 
> > For most of the secure HTTP stuff we've been discussing, I would
> > far rather be inconvenienced here and there than know my slight
> > extra convenience was being paid for in human blood.  
> 
> It isn't the Emacs way to second-guess our users' needs, 

Most users do not know or understand anything about setting
security, so defaults have to do the right thing.

> definitely
> not to decide for them what is and what isn't a matter of life and
> death for them.

Most users depend on software vendors to set the correct amount of
security. They have no understanding of the protocols in use and it
is unreasonable to ask them to make such decisions by default.

I'm dead serious in saying if you do not obey the standards for how
browsers are supposed to behave, you might quite literally kill
someone. People have died this way. Do you want me to start posting
names and incidents? You want descriptions of dissidents having their
genitals electrocuted and being locked upright in freezing cold
rooms, I'll happily start linking to Amnesty International reports
for you.

Many countries now use the internet as an instrument of control and
oppression. We should not be making their job easier.

If people want to remove security on their own, that's their business,
but providing defaults that are not even as secure as what Chrome or
Firefox does is totally irresponsible.

> We provide options with some reasonable defaults,
> and then let users make informed decisions which defaults are not
> good enough for them.
> 
> It is IMO unreasonable to make our defaults match what happens in
> dictatorships that you describe,

You do not understand the issue and are thus incompetent to make a
decision on this.

Certificate pinning has nothing to do with defaults that are set
only for such countries. It is a general mechanism deployed in any
browser you can download today, and was created to prevent people
using browsers who cannot trust their network -- which is to say, all
users -- from having untrustworthy certificates substituted in by
malign actors who intend to man-in-the-middle attack TLS connections.

Various web sites, like gmail, have deliberately requested pinning of
certs used with their sites to prevent this from happening, and it
is not our place to second-guess their security policies.

Do you really want me to describe some of the things that have
happened to people who have had their communications intercepted
because software developers were irresponsible? You can find pretty
graphic descriptions online.

> because that would unnecessarily
> inconvenience the majority of the users.

Certificate pinning is used by Chrome, Firefox, Safari and all other
browsers. Do you think they inconvenience their users? Have you ever
even gotten a single false error from this? No you haven't. I assure
you that the people setting the standards for such things spend a lot
of time making sure that it is invisible to their users.

If a site demands pinning, you should accept that they have made this
decision for good reasons.

> Let's not follow the bad
> example of the TSA (whose rationale is, unsurprisingly, also matters
> of life and death).

Your metaphor is completely inaccurate. The TSA misses something over
95% of weapons in adversarial tests for example.

Security professionals have set standards in bodies like the IETF for
how browsers should behave by default. If you want to allow
consenting adults to turn off such defenses that's one thing, but the
default should be to provide security to the users.

Richard has a blurb in every one of his emails because state security
actors are of that much concern to him, and you honestly propose
ignoring the need to protect users from network based attacks?

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> Date: Thu, 5 Jul 2018 11:29:20 -0400
> From: "Perry E. Metzger" <perry@piermont.com>
> Cc: larsi@gnus.org, eggert@cs.ucla.edu, wyuenho@gmail.com,
>  emacs-devel@gnu.org, rms@gnu.org
> 
> > It isn't the Emacs way to second-guess our users' needs, 
> 
> Most users do not know or understand anything about setting
> security, so defaults have to do the right thing.
> [...]
> > definitely
> > not to decide for them what is and what isn't a matter of life and
> > death for them.
> 
> Most users depend on software vendors to set the correct amount of
> security.
> [...]
> They have no understanding of the protocols in use and it
> is unreasonable to ask them to make such decisions by default.

Emacs always gives users who do understand the freedom to make their
choices.  Paternalism is not our way.  Where something needs to be
explained, we document it in a way that gives the users enough
information to make up their minds.  We don't decide for them, because
such decisions will never be good enough.

> I'm dead serious in saying if you do not obey the standards for how
> browsers are supposed to behave, you might quite literally kill
> someone. People have died this way. Do you want me to start posting
> names and incidents? You want descriptions of dissidents having their
> genitals electrocuted and being locked upright in freezing cold
> rooms, I'll happily start linking to Amnesty International reports
> for you.
> 
> Many countries now use the internet as an instrument of control and
> oppression. We should not be making their job easier.

People die on the roads every day, but restricting free movement due
to that somehow doesn't sound right to me.

> If people want to remove security on their own, that's their business,
> but providing defaults that are not even as secure as what Chrome or
> Firefox does is totally irresponsible.

Emacs is not a Web browser, we have different priorities.  So the
solutions need not be the same.  Blindly copying from browsers is not
a good way of dealing with these issues.  We need to carefully analyze
the potential risks and the preventive measures, and decide what makes
sense as the defaults.  (And Firefox's defaults are sometimes quite
annoying, I turn some of them off for that very reason.)

> > It is IMO unreasonable to make our defaults match what happens in
> > dictatorships that you describe,
> 
> You do not understand the issue and are thus incompetent to make a
> decision on this.

Please drop the attitude if you want me to take you seriously.  You
don't know the first thing about me to talk like this.  If anything,
my familiarity with real dictatorships is much closer and firsthand
than from reading Amnesty International reports.  If you want to
convince, explain, do not try to scare and suppress.

> Do you really want me to describe some of the things that have
> happened to people who have had their communications intercepted
> because software developers were irresponsible? You can find pretty
> graphic descriptions online.

Yes, and 9/11 was also pretty scary and detrimental to health.  But
TSA is not the solution, even if it were more effective than it is.

> you honestly propose ignoring the need to protect users from network
> based attacks?

I said nothing of the kind.  I said that we need to have "the right
amount" of security, that's all.  Dumping all the possible protection
methods on users without careful analysis of what is more and less
important is a bad starting point.

Re: A couple of questions and concerns about Emacs network security

[Paul Eggert]

Eli Zaretskii wrote:
> Emacs is not a Web browser, we have different priorities.  So the
> solutions need not be the same.

Quite true. However, when Emacs is used to browse the web there's a powerful 
argument to model its security practices on those of other web browsers. A lot 
of practical experience has gone into the Firefox and Chrome security models, 
and it would be much, much more efficient for us Emacs developers to reuse those 
wheels instead of reinventing them.

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Thu, 5 Jul 2018 12:26:47 -0700
> Cc: larsi@gnus.org, wyuenho@gmail.com, rms@gnu.org, emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> > Emacs is not a Web browser, we have different priorities.  So the
> > solutions need not be the same.
> 
> Quite true. However, when Emacs is used to browse the web there's a powerful 
> argument to model its security practices on those of other web browsers.

I agree, but even there we should not blindly copy every technique the
browsers use.

More importantly, Web browsing is a niche application in Emacs, while
NSM is about all kinds of network connections, not just those created
on behalf of EWW.

> A lot of practical experience has gone into the Firefox and Chrome
> security models, and it would be much, much more efficient for us
> Emacs developers to reuse those wheels instead of reinventing them.

We reuse most of them anyway, because we use the same security-related
libraries.  And finally, I think the suggestions were use what then
browsers do and then add to that what they don't do.  This means we
don't follow the browsers, but instead make our own decisions what
should and shouldn't be done, so in that case what Firefox etc. do is
less important.

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> Date: Thu, 05 Jul 2018 22:35:24 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: larsi@gnus.org, emacs-devel@gnu.org, wyuenho@gmail.com, rms@gnu.org,
> 	perry@piermont.com
> 
> And finally, I think the suggestions were use what then browsers do
> and then add to that what they don't do.

Sorry, that went out in a confusing way.  What I meant to say is this:

  I think the suggestions were to use what the browsers do and then
  add to that what they don't do.

Re: A couple of questions and concerns about Emacs network security

[Paul Eggert]

Eli Zaretskii wrote:
>> From: Paul Eggert <eggert@cs.ucla.edu>

> Web browsing is a niche application in Emacs, while
> NSM is about all kinds of network connections, not just those created
> on behalf of EWW.

Absolutely. Emacs has a more-general security problem than Firefox does.

However, when Emacs is used to browse the web, Firefox is a good model for what 
Emacs's default security should be. We should not waste our time (and our users' 
security and/or time) reinventing that wheel, nor should we be excessively 
cautious about improving Emacs's default web-browsing security to be something 
more like Firefox circa 2018 instead of like Netscape Navigator circa 1998 (I 
exaggerate for the purposes of conversation :-).

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> Cc: perry@piermont.com, larsi@gnus.org, wyuenho@gmail.com, rms@gnu.org,
>  emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Fri, 6 Jul 2018 10:03:27 -0700
> 
> Eli Zaretskii wrote:
> >> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> > Web browsing is a niche application in Emacs, while
> > NSM is about all kinds of network connections, not just those created
> > on behalf of EWW.
> 
> Absolutely. Emacs has a more-general security problem than Firefox does.
> 
> However, when Emacs is used to browse the web, Firefox is a good model for what 
> Emacs's default security should be.

Once again, this discussion is about the NSM, not about EWW.  NSM is
used for every net connection, not just those on behalf of EWW.  If
you are arguing that NSM should apply different settings to EWW
connections and to the other kind, then this is a separate issue.

Re: A couple of questions and concerns about Emacs network security

[Paul Eggert]

Eli Zaretskii wrote:
> this discussion is about the NSM, not about EWW.  NSM is
> used for every net connection, not just those on behalf of EWW.  If
> you are arguing that NSM should apply different settings to EWW
> connections and to the other kind, then this is a separate issue.

I'm not arguing that, no. All I'm saying is that the EWW defaults should be 
similar to what Firefox and the other browsers use; that's just common sense. If 
there are good reasons for the NSM to use different default settings for non-EWW 
connections, then of course the NSM should do that. Inertia is not a good reason 
here, though, as attacks are now more sophisticated and settings defaults that 
were OK years ago are not OK now.

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> Cc: perry@piermont.com, larsi@gnus.org, wyuenho@gmail.com, rms@gnu.org,
>  emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Fri, 6 Jul 2018 11:15:13 -0700
> 
> All I'm saying is that the EWW defaults should be 
> similar to what Firefox and the other browsers use; that's just common sense.

We agree on that (provided that those browsers don't do something that
is known to be silly).

> If there are good reasons for the NSM to use different default
> settings for non-EWW connections, then of course the NSM should do
> that.

That's exactly the essence of the discussion.  In any case, the
current baseline seems to be that we do quite a lot more than the
browsers, AFAIU.

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

On Sat, Jul 7, 2018 at 8:04 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Cc: perry@piermont.com, larsi@gnus.org, wyuenho@gmail.com, rms@gnu.org,
>>  emacs-devel@gnu.org
>> From: Paul Eggert <eggert@cs.ucla.edu>
>> Date: Fri, 6 Jul 2018 11:15:13 -0700
>>
>> All I'm saying is that the EWW defaults should be
>> similar to what Firefox and the other browsers use; that's just common sense.
>
> We agree on that (provided that those browsers don't do something that
> is known to be silly).
>
>> If there are good reasons for the NSM to use different default
>> settings for non-EWW connections, then of course the NSM should do
>> that.
>
> That's exactly the essence of the discussion.  In any case, the
> current baseline seems to be that we do quite a lot more than the
> browsers, AFAIU.

I keep hearing we are doing more than the browsers, but that's not
straightly comparible. For the 10 low checks for example, I check for
TLS 1.0 in the protocol version check, browsers haven't disabled them
but Mozilla's Telemetry shows that at least on Firefox, TLS 1.0 only
count of 0.02% of all successful TLS handshakes. I've included it only
because PCI DSS has deprecate it back in 2016, and the deadline for
that has just passed on June 30th, 2018. Not that we care about PCI
compliance, but might as well since TLS 1.0 has effectively been
neutered by the other checks.

For the rest of the low level checks other than the cert checks,
browsers have removed all the features or implemented the RFCs to
mitigate the issues, but we still support older version of GnuTLS,
checks for things like RC4 and TLS compression are necessary.
(Speaking of which, I've put in the GnuTLS version numbers in the
docstrings where these checks are applicable to). Similarly, so are
the checks for medium and 3 out of 4 of the high level checks. There's
an extra CBC check on the high level that's not dealt with by browsers
because of compatibility concerns. I throw it in because CBC mode
ciphers are known to be problematic due to padding oracles. This hole
has been plugged by the encrypt-then-MAC TLS extension (RFC 7366), so
the 2 CBC checks are only done when encrypt-then-MAC is not enabled
after the handshake. Basically, all of the checks are tailors to
Emacs' multiple network security levels and GnuTLS version changes.
They take inspirations from browsers but they are not a direct copy.
We don't ever restrict what the users do, if they want to enable RC4,
they can still do it by adjusting `gnutls-algorithm-priority`, we just
warn them when that happens.

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> Date: Sat, 7 Jul 2018 11:30:54 +0100
> Cc: Paul Eggert <eggert@cs.ucla.edu>, "Perry E. Metzger" <perry@piermont.com>, 
> 	Lars Ingebrigtsen <larsi@gnus.org>, rms@gnu.org, Emacs-Devel devel <emacs-devel@gnu.org>
> 
> I keep hearing we are doing more than the browsers, but that's not
> straightly comparible.
> [...]
> Basically, all of the checks are tailors to Emacs' multiple network
> security levels and GnuTLS version changes.  They take inspirations
> from browsers but they are not a direct copy.

That's what I meant, thanks for expressing that more accurately, and
sorry for any potential confusion I could cause with my inaccurate
wording.

Re: A couple of questions and concerns about Emacs network security

[Perry E. Metzger]

On Thu, 5 Jul 2018 12:26:47 -0700 Paul Eggert <eggert@cs.ucla.edu>
wrote:
> Eli Zaretskii wrote:
> > Emacs is not a Web browser, we have different priorities.  So the
> > solutions need not be the same.  
> 
> Quite true. However, when Emacs is used to browse the web there's a
> powerful argument to model its security practices on those of other
> web browsers. A lot of practical experience has gone into the
> Firefox and Chrome security models, and it would be much, much more
> efficient for us Emacs developers to reuse those wheels instead of
> reinventing them.

Exactly.

-- 
Perry E. Metzger		perry@piermont.com

Re: A couple of questions and concerns about Emacs network security

[Perry E. Metzger]

On Thu, 05 Jul 2018 21:55:04 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
> > I'm dead serious in saying if you do not obey the standards for
> > how browsers are supposed to behave, you might quite literally
> > kill someone. People have died this way. Do you want me to start
> > posting names and incidents? You want descriptions of dissidents
> > having their genitals electrocuted and being locked upright in
> > freezing cold rooms, I'll happily start linking to Amnesty
> > International reports for you.
> > 
> > Many countries now use the internet as an instrument of control
> > and oppression. We should not be making their job easier.  
> 
> People die on the roads every day, but restricting free movement due
> to that somehow doesn't sound right to me.

No one's freedom is restricted by providing sane default security in
anything that can be used as a browser. You're not removing the
ability of users to reconfigure things any way they want. They can
turn off the security any time they want. However, by setting
sane defaults, you're making things work reasonably so that, for
example, thugs cannot intercept their email. (Emacs is, after all, a
mail reader for many of us, and we would prefer that random sets of
thugs with torture chambers _not_ be able to intercept our IMAP
connections by default by forging certificates.)

This is no more a "restriction" than configuring a vacuum cleaner so
that, by default, it does not electrocute its users who are just
trying to clean their floors, or, by default, not putting poison into
food. People are still free to add poison to their own food or to
modify their vacuums to electrocute them if they're complete morons.

Emacs even makes it easy to customize things. We're just giving
people reasonable defaults.

As I noted, RMS cares about this stuff enough that the front of every
single email he sends talks about state sponsored espionage on
citizens. Why would we not implement simple, sane things like setting
reasonable minimum keylengths for Diffie-Hellman to prevent known
downgrade attacks?

> > If people want to remove security on their own, that's their
> > business, but providing defaults that are not even as secure as
> > what Chrome or Firefox does is totally irresponsible.  
> 
> Emacs is not a Web browser,

It is if you use it to browse the web. TLS is also used for a variety
of other things -- email, file transfer, etc. -- that Emacs does
pretty regularly for people.

> > you honestly propose ignoring the need to protect users from
> > network based attacks?  
> 
> I said nothing of the kind.  I said that we need to have "the right
> amount" of security, that's all.  Dumping all the possible
> protection methods on users without careful analysis of what is
> more and less important is a bad starting point.

How the heck does obeying a site's explicit request for pinning or CT
"dump all the possible protection methods on users without careful
analysis"? If the site owners want to specify a particular key be
used, why is it up to us to not allow that? How does
requiring a minimum of 1024 bit keys, which is already way too low,
"dump all the possible protection methods on users without careful
analysis"? What careful analysis do you need to know that 256 bit DH
keys can be cracked even by amateurs? How does not allowing the use
of compromised cryptographic algorithms that are no longer accepted
for use by any browser or command line tool "dump all the possible
protection methods on users without careful analysis"?


Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> Date: Thu, 5 Jul 2018 16:45:00 -0400
> From: "Perry E. Metzger" <perry@piermont.com>
> Cc: larsi@gnus.org, eggert@cs.ucla.edu, wyuenho@gmail.com,
>  emacs-devel@gnu.org, rms@gnu.org
> 
> > People die on the roads every day, but restricting free movement due
> > to that somehow doesn't sound right to me.
> 
> No one's freedom is restricted by providing sane default security in
> anything that can be used as a browser.

Restricting free movement on roads doesn't necessarily restrict the
freedom, it usually is a rather large annoyance.  Likewise excess
security: you get annoying prompts, popups and tooltips all over the
place.  I'm saying that the annoyance should be proportionate to the
dangers, and that we should find the fine balance where they are
proportionate.

> You're not removing the ability of users to reconfigure things any
> way they want. They can turn off the security any time they
> want. However, by setting sane defaults, you're making things work
> reasonably so that, for example, thugs cannot intercept their
> email. (Emacs is, after all, a mail reader for many of us, and we
> would prefer that random sets of thugs with torture chambers _not_
> be able to intercept our IMAP connections by default by forging
> certificates.)

I think we should assume people generally know whether thugs with
torture chambers might be after them.  I see no reason to assume each
and every Emacs user is in this situation, and I see no reason to
annoy each and every Emacs user with alerts and prompts based on that
assumption.

As for "they can turn off" part: since the additions are almost all of
them proposed for the 'medium' level of security, the only way of
"turning off" is to go to 'low', which in Emacs means no security at
all, and that makes even less sense to me.

Which brings me to the main comment on everything that you wrote
against my opinions: please read my comments and questions in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31946#89.  Because
that's the only/main thing that bothers me in the patches discussed in
this and other related threads, and without reading that, your
comments will generally miss the point.

> Emacs even makes it easy to customize things. We're just giving
> people reasonable defaults.

We should do that, yes.  I'm questioning whether the proposed defaults
are "reasonable", that's all.

> As I noted, RMS cares about this stuff enough that the front of every
> single email he sends talks about state sponsored espionage on
> citizens. Why would we not implement simple, sane things like setting
> reasonable minimum keylengths for Diffie-Hellman to prevent known
> downgrade attacks?

See above: you are missing my point, because you haven't read my
comments to the patches.

> > > If people want to remove security on their own, that's their
> > > business, but providing defaults that are not even as secure as
> > > what Chrome or Firefox does is totally irresponsible.  
> > 
> > Emacs is not a Web browser,
> 
> It is if you use it to browse the web. TLS is also used for a variety
> of other things -- email, file transfer, etc. -- that Emacs does
> pretty regularly for people.

I'm saying that the defaults used by browsers are not necessarily
correct for non-browser applications, including email and file
transfer.  Some of them might be appropriate, some might be less so.

In any case, please note that the current proposals don't copy what
the browsers do, they add a lot of tests the browsers don't (yet) do,
at least not by default.  So arguments about what the browsers do are
already not very convincing, as we explicitly consider to deviate from
what they do (and rightfully so).

> > I said nothing of the kind.  I said that we need to have "the right
> > amount" of security, that's all.  Dumping all the possible
> > protection methods on users without careful analysis of what is
> > more and less important is a bad starting point.
> 
> How the heck does obeying a site's explicit request for pinning or CT
> "dump all the possible protection methods on users without careful
> analysis"? If the site owners want to specify a particular key be
> used, why is it up to us to not allow that? How does
> requiring a minimum of 1024 bit keys, which is already way too low,
> "dump all the possible protection methods on users without careful
> analysis"? What careful analysis do you need to know that 256 bit DH
> keys can be cracked even by amateurs? How does not allowing the use
> of compromised cryptographic algorithms that are no longer accepted
> for use by any browser or command line tool "dump all the possible
> protection methods on users without careful analysis"?

You are again missing the main point of my concerns.  Please read the
comments for the patches submitted in bug#31946.  In a nutshell, I of
course have nothing against each one of these measures, it's their sum
total that is being put into the 'medium' level that bothers me.

Re: A couple of questions and concerns about Emacs network security

[Richard Stallman]

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

  > I think we should assume people generally know whether thugs with
  > torture chambers might be after them.

I agree, provided we encourage them to ask themselves the question.
Until a dictatorship gets totally and openly vicious, people have a
tendency to think things like, "They couldn't possibly consider me
important enough to do that to me."  So it would be good to ask
a question that would lead people to think about this, dismissing
that tendency.

					   I see no reason to assume each
  > and every Emacs user is in this situation, and I see no reason to
  > annoy each and every Emacs user with alerts and prompts based on that
  > assumption.

I agree.

But we should ask each Emacs user to think about whether perse needs
this level of security.  We should not turn it off by default.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: A couple of questions and concerns about Emacs network security

[Perry E. Metzger]

On Fri, 06 Jul 2018 19:08:58 -0400 Richard Stallman <rms@gnu.org>
wrote:
> [[[ 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. ]]]
> 
>   > I think we should assume people generally know whether thugs
>   > with torture chambers might be after them.  
> 
> I agree, provided we encourage them to ask themselves the question.

There is ample evidence that people in such situations rarely if ever
understand what the right thing to do is.

There's also another issue we've discovered: at one time, people
believed having software provide "levels" of security made sense,but
we now understand based on bitter experience that everyone, whether
their greatest threat is unimportant or whether their greatest threat
is a nation state, uses the same software and same default settings
99% of the time, so software needs to be built with the needs of
people under threat in mind.

And let me repeat, there's excellent field evidence that
people under threat generally have no technical expertise to make
serious security decisions, and that includes people with programming
backgrounds.

The other thing is, in spite of the constant claims, running with the
level of security provided by Firefox or Chrome or Safari isn't the
least bit inconvenient, so there's no obvious reason not to do at
least _that_. It's not like there's any actual tradeoff involved.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> Date: Sat, 7 Jul 2018 08:18:33 -0400
> From: "Perry E. Metzger" <perry@piermont.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, eggert@cs.ucla.edu, emacs-devel@gnu.org,
> 	larsi@gnus.org, wyuenho@gmail.com
> 
> There is ample evidence that people in such situations rarely if ever
> understand what the right thing to do is.

That doesn't necessarily mean we need to assume none of them will
understand that, if the considerations are explained in clear terms
that can be mapped to the user's environment.

> There's also another issue we've discovered: at one time, people
> believed having software provide "levels" of security made sense,but
> we now understand based on bitter experience that everyone, whether
> their greatest threat is unimportant or whether their greatest threat
> is a nation state, uses the same software and same default settings
> 99% of the time, so software needs to be built with the needs of
> people under threat in mind.

I don't see how this is relevant, since we are talking about just one
piece of software: Emacs.  For the purposes of this discussion,
whether they use the same browsers or different ones, because we are
not discussing those browsers.

And my personal experience definitely contradicts your "everyone"
claim: e.g., my home network is set up with several non-default
defenses, and so is my smartphone.  Why should we assume a significant
part of Emacs users is in the "everyone" camp?  They did choose to use
Emacs, didn't they?

> And let me repeat, there's excellent field evidence that
> people under threat generally have no technical expertise to make
> serious security decisions, and that includes people with programming
> backgrounds.

You are entitled to your opinions, but I don't agree that we should
design our defaults based on the assumption that we cannot expect our
users to make informed decisions.  I expect that much from Emacs
developers, and I'm certainly not going to behave differently when
such decisions depend on me.

> The other thing is, in spite of the constant claims, running with the
> level of security provided by Firefox or Chrome or Safari isn't the
> least bit inconvenient, so there's no obvious reason not to do at
> least _that_.

One would think that those "constant claims" might just provide such a
reason.

Besides, we don't really follow what those browsers do, so it's a moot
point to argue anyway.

Re: A couple of questions and concerns about Emacs network security

[Perry E. Metzger]

On Sat, 07 Jul 2018 16:19:40 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
> > Date: Sat, 7 Jul 2018 08:18:33 -0400
> > From: "Perry E. Metzger" <perry@piermont.com>
> > Cc: Eli Zaretskii <eliz@gnu.org>, eggert@cs.ucla.edu,
> > emacs-devel@gnu.org, larsi@gnus.org, wyuenho@gmail.com
> > 
> > There is ample evidence that people in such situations rarely if
> > ever understand what the right thing to do is.  
> 
> That doesn't necessarily mean we need to assume none of them will
> understand that, if the considerations are explained in clear terms
> that can be mapped to the user's environment.

The difference between "none" and "under 5%" is so small as to be
unimportant. In tests, even with very careful explanations, only a
really tiny fraction of users seem to make good decisions some of
the time, and that's even when computer science undergraduates are the
test subjects. Go and check the literature on this if you don't
believe me. Once the decisions are complicated, like figuring out
whether to trust a certificate or not, the ability to make correct
choices, even among security professionals, drops to the noise floor.

> > There's also another issue we've discovered: at one time, people
> > believed having software provide "levels" of security made
> > sense,but we now understand based on bitter experience that
> > everyone, whether their greatest threat is unimportant or whether
> > their greatest threat is a nation state, uses the same software
> > and same default settings 99% of the time, so software needs to
> > be built with the needs of people under threat in mind.  
> 
> I don't see how this is relevant, since we are talking about just
> one piece of software: Emacs.  For the purposes of this discussion,
> whether they use the same browsers or different ones, because we are
> not discussing those browsers.

You may not see the relevance, but others do.

> And my personal experience definitely contradicts your "everyone"
> claim: e.g., my home network is set up with several non-default
> defenses, and so is my smartphone.  Why should we assume a
> significant part of Emacs users is in the "everyone" camp?  They
> did choose to use Emacs, didn't they?

The difference between one person in a hundred and no one is so small
for purposes of deciding on default behavior as to be unimportant.

As for your own configuration, you're free to change the defaults any
way you like, so why are you arguing anyway? No one will stop you
from selecting 256 bit D-H keys or turning off encryption entirely or
turning off CT if that's what you really insist on.

> > And let me repeat, there's excellent field evidence that
> > people under threat generally have no technical expertise to make
> > serious security decisions, and that includes people with
> > programming backgrounds.  
> 
> You are entitled to your opinions

These are not opinions. They're facts. They're based on decades of
field experience and objective studies published in the academic
literature. There is almost universal agreement among the
studies, too -- there are no published outliers that I'm aware of.

So, my statements are not matters of opinion any more than the
claim that most people get hungry if they don't eat for long enough
is a matter of opinion. You are, of course, entitled to claim the
moon is made of green cheese or that most users can make informed
security decisions for themselves about things like key length or
certificate origins. These claims are both wrong, and no one should
pay attention to such claims, but one is entitled to say it. Others
should ignore such statements, however, because they are
counterfactual.

> but I don't agree that we should
> design our defaults based on the assumption that we cannot expect
> our users to make informed decisions.

And this sets you apart from people who have worked in the field for
decades, and from people who have done objective studies in the field.

It's fine to let the tiny fraction of users who understand what
they're doing to go into their .emacs file and set whatever they
prefer. Asking users to make "informed decisions" in real time simply
doesn't work, and this is not opinion, it is fact, and though you are
going to argue until the end of time regardless of evidence, your
opinion is simply wrong.

I strongly suspect, by the way, that I could easily get you to make a
bad security decision in a test environment. I don't trust myself to
evaluate the origin of certificates in real time -- it's just too
difficult to read an x.509 cert's contents and verify everything you
need to (including the hash algorithms used in the entire chain,
figuring out if the CA is one I should be expecting for this
particular host, etc.) That is in spite of the fact that I've been
doing this professionally for a very long time. I suspect I could
easily cook up certs that you wouldn't be able to figure out, and
that you would make the wrong decision if prompted to look at them.

That said, I have no objections to your being able to set whatever
parameters you want by editing your configs. So you see, we can both
have our way. You can run Windows XP until the end of time, and you
can set your default configuration for TLS interactions badly, and
other people can run much more secure free operating systems and can
have strong TLS defaults, and everyone can be happy.

> > The other thing is, in spite of the constant claims, running with
> > the level of security provided by Firefox or Chrome or Safari
> > isn't the least bit inconvenient, so there's no obvious reason
> > not to do at least _that_.  
> 
> One would think that those "constant claims" might just provide
> such a reason.

The only one making this claim is _you_. No one can provide
good examples of how following the usual practice in the rest of the
community would inconvenience anyone, but you keep implying this
anyway. No one else is making this claim, but you are constantly and
consistently implying that it is the case even though there's
basically no evidence for it.

> Besides, we don't really follow what those browsers do,

But we should. It's insane not to. You keep going on and on about how
somehow setting such defaults would be inconvenient, but
there's not the slightest evidence that it would be, and there's
excellent evidence that there's good reason to follow those practices.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> Date: Sat, 7 Jul 2018 09:46:22 -0400
> From: "Perry E. Metzger" <perry@piermont.com>
> Cc: rms@gnu.org, eggert@cs.ucla.edu, emacs-devel@gnu.org, larsi@gnus.org,
>  wyuenho@gmail.com
> 
> On Sat, 07 Jul 2018 16:19:40 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
> > > Date: Sat, 7 Jul 2018 08:18:33 -0400
> > > From: "Perry E. Metzger" <perry@piermont.com>
> > > Cc: Eli Zaretskii <eliz@gnu.org>, eggert@cs.ucla.edu,
> > > emacs-devel@gnu.org, larsi@gnus.org, wyuenho@gmail.com
> > > 
> > > There is ample evidence that people in such situations rarely if
> > > ever understand what the right thing to do is.  
> > 
> > That doesn't necessarily mean we need to assume none of them will
> > understand that, if the considerations are explained in clear terms
> > that can be mapped to the user's environment.
> 
> The difference between "none" and "under 5%" is so small as to be
> unimportant.

I don't know where you took that number.  Any idea what is the
correlation between those 5% and the percentage of people who use
Emacs, btw?

> In tests, even with very careful explanations, only a
> really tiny fraction of users seem to make good decisions some of
> the time, and that's even when computer science undergraduates are the
> test subjects.

We are not talking about the same decisions in the same terms.  Once
again, I suggest to re-read my comments to Jimmy's patches and the
following discussion.

> > And my personal experience definitely contradicts your "everyone"
> > claim: e.g., my home network is set up with several non-default
> > defenses, and so is my smartphone.  Why should we assume a
> > significant part of Emacs users is in the "everyone" camp?  They
> > did choose to use Emacs, didn't they?
> 
> The difference between one person in a hundred and no one is so small
> for purposes of deciding on default behavior as to be unimportant.

I don't think your estimation of the percentage is accurate, wrt Emacs
users.  They are not the typical mass user of computers.

> As for your own configuration, you're free to change the defaults any
> way you like, so why are you arguing anyway?

Because I think there are many others like me.  I'm not special in any
way, neither in my Emacs usage patterns nor in how I approach
security.

> > You are entitled to your opinions
> 
> These are not opinions. They're facts. They're based on decades of
> field experience and objective studies published in the academic
> literature. There is almost universal agreement among the
> studies, too -- there are no published outliers that I'm aware of.

I meant your opinions about how Emacs should design its
security-related UI and treat its users.  They are definitely not
facts, because we are talking about something that doesn't yet exist,
so it couldn't be a subject of decades of studies.

> > but I don't agree that we should
> > design our defaults based on the assumption that we cannot expect
> > our users to make informed decisions.
> 
> And this sets you apart from people who have worked in the field for
> decades, and from people who have done objective studies in the field.

Studies on Emacs users?

> I strongly suspect, by the way, that I could easily get you to make a
> bad security decision in a test environment. I don't trust myself to
> evaluate the origin of certificates in real time -- it's just too
> difficult to read an x.509 cert's contents and verify everything you
> need to (including the hash algorithms used in the entire chain,
> figuring out if the CA is one I should be expecting for this
> particular host, etc.) That is in spite of the fact that I've been
> doing this professionally for a very long time. I suspect I could
> easily cook up certs that you wouldn't be able to figure out, and
> that you would make the wrong decision if prompted to look at them.

You are completely missing the point.  No one claimed we should expect
users to judge certificates.

> > > The other thing is, in spite of the constant claims, running with
> > > the level of security provided by Firefox or Chrome or Safari
> > > isn't the least bit inconvenient, so there's no obvious reason
> > > not to do at least _that_.  
> > 
> > One would think that those "constant claims" might just provide
> > such a reason.
> 
> The only one making this claim is _you_.

My "claims" are facts.  I see these issues every day, using mostly
Firefox and IE.  I'd be surprised if I were the only one, because
there's nothing special in my setups.

> > Besides, we don't really follow what those browsers do,
> 
> But we should. It's insane not to.

Please read Jimmy's comments on this, and respond to them if you want.

Re: A couple of questions and concerns about Emacs network security

[Perry E. Metzger]

On Sat, 07 Jul 2018 17:17:24 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
> > Date: Sat, 7 Jul 2018 09:46:22 -0400
> > From: "Perry E. Metzger" <perry@piermont.com>
> > Cc: rms@gnu.org, eggert@cs.ucla.edu, emacs-devel@gnu.org,
> > larsi@gnus.org, wyuenho@gmail.com
> > 
> > On Sat, 07 Jul 2018 16:19:40 +0300 Eli Zaretskii <eliz@gnu.org>
> > wrote:  
> > > > Date: Sat, 7 Jul 2018 08:18:33 -0400
> > > > From: "Perry E. Metzger" <perry@piermont.com>
> > > > Cc: Eli Zaretskii <eliz@gnu.org>, eggert@cs.ucla.edu,
> > > > emacs-devel@gnu.org, larsi@gnus.org, wyuenho@gmail.com
> > > > 
> > > > There is ample evidence that people in such situations rarely
> > > > if ever understand what the right thing to do is.    
> > > 
> > > That doesn't necessarily mean we need to assume none of them
> > > will understand that, if the considerations are explained in
> > > clear terms that can be mapped to the user's environment.  
> > 
> > The difference between "none" and "under 5%" is so small as to be
> > unimportant.  
> 
> I don't know where you took that number.

Maybe you should learn about the topics you have such strong opinions
on before expressing the strong opinions. If you were actually in the
field or even reading the literature, you wouldn't need to ask such
things.

> > > And my personal experience definitely contradicts your
> > > "everyone" claim: e.g., my home network is set up with several
> > > non-default defenses, and so is my smartphone.  Why should we
> > > assume a significant part of Emacs users is in the "everyone"
> > > camp?  They did choose to use Emacs, didn't they?  
> > 
> > The difference between one person in a hundred and no one is so
> > small for purposes of deciding on default behavior as to be
> > unimportant.  
> 
> I don't think your estimation of the percentage is accurate, wrt
> Emacs users.  They are not the typical mass user of computers.

*I* cannot make such decisions safely, and *I* am one of the people
who created the protocols in question. I'm certain I can construct
certs that will fool *you*. There's no point in pretending
sufficiently educated humans can make such decisions when the
decisions are too complicated and must be made correctly _every
single time_ or you're done for. Humans cannot reliably make
complicated decisions with perfect safety thousands of times in a
row.

> > As for your own configuration, you're free to change the defaults
> > any way you like, so why are you arguing anyway?  
> 
> Because I think there are many others like me.

So the others like you can change the defaults any way you like. WHAT
IS THE PROBLEM.

> > > You are entitled to your opinions  
> > 
> > These are not opinions. They're facts. They're based on decades of
> > field experience and objective studies published in the academic
> > literature. There is almost universal agreement among the
> > studies, too -- there are no published outliers that I'm aware
> > of.  
> 
> I meant your opinions about how Emacs should design its
> security-related UI and treat its users.  They are definitely not
> facts,

So far, I hear a number of people saying "the reasonable thing is to
use the same default behavior that pretty much everything else uses",
and I hear Eli saying "no, no, I want to make things more complicated
because I claim that somehow there will be great inconvenience if
the software rejects obviously forged certificates or obviously
insecure cipher suites by default".

What exactly is the inconvenience you anticipate if an Emacs IMAP
user connecting to google rejects a certificate that isn't vouched
for by the CT mechanism? Can you explain _precisely_ why you insist
that it is necessary to have different defaults than everyone else
uses?

> > > but I don't agree that we should
> > > design our defaults based on the assumption that we cannot
> > > expect our users to make informed decisions.  
> > 
> > And this sets you apart from people who have worked in the field
> > for decades, and from people who have done objective studies in
> > the field.  
> 
> Studies on Emacs users?

Emacs users are for the most part human beings, yes. They browse the
web and read email using the same sorts of brains that evolution gave
everyone else.

> > I strongly suspect, by the way, that I could easily get you to
> > make a bad security decision in a test environment. I don't trust
> > myself to evaluate the origin of certificates in real time --
> > it's just too difficult to read an x.509 cert's contents and
> > verify everything you need to (including the hash algorithms used
> > in the entire chain, figuring out if the CA is one I should be
> > expecting for this particular host, etc.) That is in spite of the
> > fact that I've been doing this professionally for a very long
> > time. I suspect I could easily cook up certs that you wouldn't be
> > able to figure out, and that you would make the wrong decision if
> > prompted to look at them.  
> 
> You are completely missing the point.  No one claimed we should
> expect users to judge certificates.

Then what the hell are you arguing for? What exactly is it about the
defaults that Firefox, Chrome, Safari, Edge and the rest use that you
don't like? If your answer is "I don't know, I haven't looked at
them", shouldn't you be just a trace ashamed of yourself for having a
strong opinion in the absence of any examination?

> > > > The other thing is, in spite of the constant claims, running
> > > > with the level of security provided by Firefox or Chrome or
> > > > Safari isn't the least bit inconvenient, so there's no
> > > > obvious reason not to do at least _that_.    
> > > 
> > > One would think that those "constant claims" might just provide
> > > such a reason.  
> > 
> > The only one making this claim is _you_.  
> 
> My "claims" are facts.

Your claim is not a fact.

> I see these issues every day, using mostly
> Firefox and IE.

Why are you using IE? And what exactly is failing for you? I haven't
hit a single problem connecting to anything which wasn't a legitimate
failure (that is, the browser actually protecting me when it should)
in many months, possibly longer. There are careful studies the
browser vendors make of such things, and failures are currently
pretty damn rare. And yes, that's a fact.

> Please read Jimmy's comments on this, and respond to them if you
> want.

Jimmy is entirely reasonable here. I'm not arguing with him because
he's not saying anything terribly wrong.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> Date: Sat, 7 Jul 2018 11:25:44 -0400
> From: "Perry E. Metzger" <perry@piermont.com>
> Cc: rms@gnu.org, eggert@cs.ucla.edu, emacs-devel@gnu.org, larsi@gnus.org,
>  wyuenho@gmail.com
> 
> > I don't know where you took that number.
> 
> Maybe you should learn about the topics you have such strong opinions
> on before expressing the strong opinions. If you were actually in the
> field or even reading the literature, you wouldn't need to ask such
> things.

Maybe you should learn to talk with people who are not specialists,
and maybe you should learn to recognize "strong opinions" when you see
one.

> > > As for your own configuration, you're free to change the defaults
> > > any way you like, so why are you arguing anyway?  
> > 
> > Because I think there are many others like me.
> 
> So the others like you can change the defaults any way you like. WHAT
> IS THE PROBLEM.

Irrelevant.  We are talking about the defaults.

> > I meant your opinions about how Emacs should design its
> > security-related UI and treat its users.  They are definitely not
> > facts,
> 
> So far, I hear a number of people saying "the reasonable thing is to
> use the same default behavior that pretty much everything else uses",
> and I hear Eli saying "no, no, I want to make things more complicated
> because I claim that somehow there will be great inconvenience if
> the software rejects obviously forged certificates or obviously
> insecure cipher suites by default".

So maybe you should learn to listen more carefully.  And read, for
that matter.

> What exactly is the inconvenience you anticipate if an Emacs IMAP
> user connecting to google rejects a certificate that isn't vouched
> for by the CT mechanism? Can you explain _precisely_ why you insist
> that it is necessary to have different defaults than everyone else
> uses?

I already did.  PLEASE RE-READ WHAT I WROTE, and not necessarily to
in response to your posts.

> > > And this sets you apart from people who have worked in the field
> > > for decades, and from people who have done objective studies in
> > > the field.  
> > 
> > Studies on Emacs users?
> 
> Emacs users are for the most part human beings, yes.

They are not a representative sample of computer users, however.  So
what by and large is correct for the bulk of the users is not
necessarily correct for Emacs users.

> > You are completely missing the point.  No one claimed we should
> > expect users to judge certificates.
> 
> Then what the hell are you arguing for?

READ MY MESSAGES!!

> > I see these issues every day, using mostly
> > Firefox and IE.
> 
> Why are you using IE?

Because I sometimes have to.  And there's nothing special about it, it
actually sometimes works better than Firefox.

> > Please read Jimmy's comments on this, and respond to them if you
> > want.
> 
> Jimmy is entirely reasonable here. I'm not arguing with him because
> he's not saying anything terribly wrong.

Then you don't have any argument with me, either, because I don't have
any argument with Jimmy.

(And please leave out ad-hominem, your unconcealed disdain makes this
a very unpleasant discussion.)

Re: A couple of questions and concerns about Emacs network security

[Richard Stallman]

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

  > What exactly is the inconvenience you anticipate if an Emacs IMAP
  > user connecting to google rejects a certificate that isn't vouched
  > for by the CT mechanism? Can you explain _precisely_ why you insist
  > that it is necessary to have different defaults than everyone else
  > uses?

Here is an idea.  Let's implement the browser-like security in master
as an option disabled by default.  Then Eli and others can try it out
for a few weeks and report each inconvenience.

Then we will see how much, or how little, inconvenience results from
this mode of operation.


-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: A couple of questions and concerns about Emacs network security

[Perry E. Metzger]

On Sat, 07 Jul 2018 19:46:49 -0400 Richard Stallman <rms@gnu.org>
wrote:
>   > What exactly is the inconvenience you anticipate if an Emacs
>   > IMAP user connecting to google rejects a certificate that isn't
>   > vouched for by the CT mechanism? Can you explain _precisely_
>   > why you insist that it is necessary to have different defaults
>   > than everyone else uses?  
> 
> Here is an idea.  Let's implement the browser-like security in
> master as an option disabled by default.  Then Eli and others can
> try it out for a few weeks and report each inconvenience.
> 
> Then we will see how much, or how little, inconvenience results from
> this mode of operation.

This is an excellent suggestion.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sat, 07 Jul 2018 19:46:49 -0400
> Cc: wyuenho@gmail.com, eliz@gnu.org, eggert@cs.ucla.edu, larsi@gnus.org,
> 	emacs-devel@gnu.org
> 
> Here is an idea.  Let's implement the browser-like security in master
> as an option disabled by default.  Then Eli and others can try it out
> for a few weeks and report each inconvenience.
> 
> Then we will see how much, or how little, inconvenience results from
> this mode of operation.

I think the plan is to enable that by default on master, which I think
is even better, since more people will be able to test it.

Re: A couple of questions and concerns about Emacs network security

[Richard Stallman]

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

  > I think the plan is to enable that by default on master, which I think
  > is even better, since more people will be able to test it.

Ok by me.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

>>
>> I don't see how this is relevant, since we are talking about just
>> one piece of software: Emacs.  For the purposes of this discussion,
>> whether they use the same browsers or different ones, because we are
>> not discussing those browsers.
>
> You may not see the relevance, but others do.
>

The relevance is what browsers do is a very good heuristics for
someone like me who wants a starting point to find out what problems
to look out for. Another piece of information these browsers give me
is being able to predict the future. These browsers hold enormous
power in shaping the internet. Just Google deprecating SHA1 certs
alone is enough to make them drop to exactly 0 within a month[1]. I
don't see any other relevance beyond these two.

I know Perry you probably want to copy what browsers do - basically
removing unsafe ciphers and only offer one security levels, and
perhaps drop support for GnuTLS version other than the most recent
stable version. I can tell you now that in practical terms, they make
very little difference. For Gmail, 85% outbound and 91% inbound emails
are secured with TLS[2]. For HTTP, most of the checks I've implemented
is already supported by a vast majority of servers out there, and
given that the time people spend on the web vs the websites' Alexa
rankings follows the Pareto distribution, most of the time you won't
even get a warning. No warning, no decision to make.

For the 20% of time you are not spending on Alexa top 20k, we can
infer from SSLLabs' SSLPulse data to get a sense of how dangerous they
are. SSLPulse tracks the Alexa top 150K websites, with the exception
of protocol downgrade defense, no other problems that I check for
exceed 5% on this list of servers. 5% of 20% is 1%. If you only
consider cipher suites independently, given that browsers have removed
a shit ton of unsafe cipher suites already, the chance of getting an
unsafe cipher suite from a handshake is very very very small.

The whole reason I'm working on fixing Emacs' network security is I
believe Emacs' esoteric user base is probably extreme outliers, and
Emacs' TLS defence is next to useless. I'm not working on this for
normal people here.

[1]: "Certificate Signature Algorithms" Jan 2017 - Feb 2017.
https://www.ssllabs.com/ssl-pulse/
[2]: https://transparencyreport.google.com/safer-email/overview

Re: A couple of questions and concerns about Emacs network security

[Perry E. Metzger]

On Sat, 7 Jul 2018 15:32:19 +0100 Jimmy Yuen Ho Wong
<wyuenho@gmail.com> wrote:
> I know Perry you probably want to copy what browsers do - basically
> removing unsafe ciphers and only offer one security levels, and
> perhaps drop support for GnuTLS version other than the most recent
> stable version. I can tell you now that in practical terms, they
> make very little difference. For Gmail, 85% outbound and 91%
> inbound emails are secured with TLS[2].

My main concern in the case of users reading their mail with Emacs is
certificate forgery, and not the use of TLS itself. (The stats you
are quoting are regardless for the use of TLS with SMTP, not with
IMAP which is the relevant issue, and they don't tell us anything
about the interception of mail by man-in-the-middle attacks against
IMAP TLS connections.) Pinning (or later CT) is needed to prevent
malefactors, including, lets be blunt, several major states, from
using the equipment they've bought from Bluecoat and other vendors to
intercept the TLS connections by using forged certificates. It's not a
theoretical concern, the equipment to do this is deployed, and only
CT and the rest will help.

Downgrade attacks are also a concern of course.

> For HTTP, most of the
> checks I've implemented is already supported by a vast majority of
> servers out there, and given that the time people spend on the web
> vs the websites' Alexa rankings follows the Pareto distribution,
> most of the time you won't even get a warning. No warning, no
> decision to make.

I'm also concerned about pinning or CT for things like
mail.google.com and the like when they're accessed over HTTPS.

> For the 20% of time you are not spending on Alexa top 20k, we can
> infer from SSLLabs' SSLPulse data to get a sense of how dangerous
> they are. SSLPulse tracks the Alexa top 150K websites, with the
> exception of protocol downgrade defense, no other problems that I
> check for exceed 5% on this list of servers. 5% of 20% is 1%. If
> you only consider cipher suites independently, given that browsers
> have removed a shit ton of unsafe cipher suites already, the chance
> of getting an unsafe cipher suite from a handshake is very very
> very small.

The chance of getting an unsafe cipher suite in legitimate use is
essentially zero. The chance of getting a downgrade attack is very
very high because there are companies that sell hardware specifically
to perform such attacks, and there's homemade equipment in deployed
use by a number of state actors that have larger budgets and more
custom interests.

> The whole reason I'm working on fixing Emacs' network security is I
> believe Emacs' esoteric user base is probably extreme outliers, and
> Emacs' TLS defence is next to useless. I'm not working on this for
> normal people here.

So, I'm a security professional, partially responsible for the
creation of some of the protocols in question, I use Emacs for
purposes like reading email and the like, and I'm concerned that I
want my security to be good and that the current mechanisms don't
really give me what I need. And no, I don't want to be asked when I'm
presented with a cert that Google specifically said isn't valid, I
want it to be rejected so I won't accidentally say yes at 3am when
I'm exhausted and not paying attention.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

Can you preempt me with an OCSP patch, or better yet, a CT patch
already... C hurts my head and I spend more time answering emails than
writing code this week...

Stop... both of you....

P.S. If it makes you feel any better, GnuTLS does checks OCSP stapling
automatically already, and I've already submitted a patch to do CRL,
not that IGTF's CRL is particularly good...

On Sat, Jul 7, 2018 at 4:15 PM, Perry E. Metzger <perry@piermont.com> wrote:
> On Sat, 7 Jul 2018 15:32:19 +0100 Jimmy Yuen Ho Wong
> <wyuenho@gmail.com> wrote:
>> I know Perry you probably want to copy what browsers do - basically
>> removing unsafe ciphers and only offer one security levels, and
>> perhaps drop support for GnuTLS version other than the most recent
>> stable version. I can tell you now that in practical terms, they
>> make very little difference. For Gmail, 85% outbound and 91%
>> inbound emails are secured with TLS[2].
>
> My main concern in the case of users reading their mail with Emacs is
> certificate forgery, and not the use of TLS itself. (The stats you
> are quoting are regardless for the use of TLS with SMTP, not with
> IMAP which is the relevant issue, and they don't tell us anything
> about the interception of mail by man-in-the-middle attacks against
> IMAP TLS connections.) Pinning (or later CT) is needed to prevent
> malefactors, including, lets be blunt, several major states, from
> using the equipment they've bought from Bluecoat and other vendors to
> intercept the TLS connections by using forged certificates. It's not a
> theoretical concern, the equipment to do this is deployed, and only
> CT and the rest will help.
>
> Downgrade attacks are also a concern of course.
>
>> For HTTP, most of the
>> checks I've implemented is already supported by a vast majority of
>> servers out there, and given that the time people spend on the web
>> vs the websites' Alexa rankings follows the Pareto distribution,
>> most of the time you won't even get a warning. No warning, no
>> decision to make.
>
> I'm also concerned about pinning or CT for things like
> mail.google.com and the like when they're accessed over HTTPS.
>
>> For the 20% of time you are not spending on Alexa top 20k, we can
>> infer from SSLLabs' SSLPulse data to get a sense of how dangerous
>> they are. SSLPulse tracks the Alexa top 150K websites, with the
>> exception of protocol downgrade defense, no other problems that I
>> check for exceed 5% on this list of servers. 5% of 20% is 1%. If
>> you only consider cipher suites independently, given that browsers
>> have removed a shit ton of unsafe cipher suites already, the chance
>> of getting an unsafe cipher suite from a handshake is very very
>> very small.
>
> The chance of getting an unsafe cipher suite in legitimate use is
> essentially zero. The chance of getting a downgrade attack is very
> very high because there are companies that sell hardware specifically
> to perform such attacks, and there's homemade equipment in deployed
> use by a number of state actors that have larger budgets and more
> custom interests.
>
>> The whole reason I'm working on fixing Emacs' network security is I
>> believe Emacs' esoteric user base is probably extreme outliers, and
>> Emacs' TLS defence is next to useless. I'm not working on this for
>> normal people here.
>
> So, I'm a security professional, partially responsible for the
> creation of some of the protocols in question, I use Emacs for
> purposes like reading email and the like, and I'm concerned that I
> want my security to be good and that the current mechanisms don't
> really give me what I need. And no, I don't want to be asked when I'm
> presented with a cert that Google specifically said isn't valid, I
> want it to be rejected so I won't accidentally say yes at 3am when
> I'm exhausted and not paying attention.
>
> Perry
> --
> Perry E. Metzger                perry@piermont.com

Re: A couple of questions and concerns about Emacs network security

[Paul Eggert]

Jimmy Yuen Ho Wong wrote:
> Can you preempt me with an OCSP patch, or better yet, a CT patch
> already... C hurts my head and I spend more time answering emails than
> writing code this week...

What C code do you need? You mentioned something earlier, but I didn't 
understand the use case. I can easily write and debug C code, if that would help.

> Stop... both of you....

My sentiments too. C'mon, we have active volunteers who are real experts in this 
area. It'd be silly to let this opportunity pass.

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

>
> What C code do you need? You mentioned something earlier, but I didn't
> understand the use case. I can easily write and debug C code, if that would help.
>

Whooo thanks for lending a hand. ATM, in order to implement
`nsm-trust-local-network` properly for IPv6, I need some code to
resolve a hostname to an IP address, preferrably in Emacs' internal
format as documented in make-network-process. There's an ancient
function called dnsResolve that delegates to
url-gateway-nslookup-host. It shells out to the system's nslookup for
an IPv4 address now, but I need to something that'll give me back an
IPv6. I could modify url-gateway-nslookup-host, but the nastiest thing
is translating a short-form IPv6 address into a vector of numbers. I
don't really care if it's C code for this one.

The one thing that I need help the most is implementing the
client-side of RFC 6962. https://tools.ietf.org/html/rfc6962 .

The general idea is you need to implement an X.509 certificate
extension and a TLS extension called Signed Certificate Timestamp
using GnuTLS's API. Once you can extract that from a handshake, just
put the SCT data into the list returned by gnutls_certificate_details
(I have renamed it to emacs_gnutls_certificate_details, but you might
want to change it back). Once you have the SCT on the LISP side, you
can write a check for `nsm-tls-checks` that opens up another
connection to the auditor to validate the SCT. In addition, you may
have to modify how GnutTLS deals with OCSP stapling as well because
that's the third way SCT can be delivered. You can take your time on
this one if you decide to help out, I understand this is a rather
large project on its own.

Thanks!

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> Date: Sat, 7 Jul 2018 11:15:17 -0400
> From: "Perry E. Metzger" <perry@piermont.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, rms@gnu.org, Paul Eggert
>  <eggert@cs.ucla.edu>, Emacs-Devel devel <emacs-devel@gnu.org>, Lars
>  Ingebrigtsen <larsi@gnus.org>
> 
> So, I'm a security professional, partially responsible for the
> creation of some of the protocols in question, I use Emacs for
> purposes like reading email and the like, and I'm concerned that I
> want my security to be good and that the current mechanisms don't
> really give me what I need. And no, I don't want to be asked when I'm
> presented with a cert that Google specifically said isn't valid, I
> want it to be rejected so I won't accidentally say yes at 3am when
> I'm exhausted and not paying attention.

There's nothing to prevent you from customizing your Emacs to do
precisely what you want.  Being a security professional, you are
probably qualified to do that better than moist of us.

My concern is mainly about the rest of us.

Re: A couple of questions and concerns about Emacs network security

[Richard Stallman]

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

  > >   > I think we should assume people generally know whether thugs
  > >   > with torture chambers might be after them.  
  > > 
  > > I agree, provided we encourage them to ask themselves the question.

  > There is ample evidence that people in such situations rarely if ever
  > understand what the right thing to do is.

That seems to be a subtle change of topic.  If we urge users to ask
themselves, "Might thugs with torture chambers be spying on me,"
that question is not technical at all.

"What is the right thing to do about it" is a different question, a
technical question.

I said we should encourage users to pose the first question to
themselves.  I think we all agree that Emacs should DTRT for users
who conclude the answer might be yes.


-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

I'm currently doing a second pass for my patch for bug#31946. I also
have a preliminary OCSP patch. Emacs network security is going to be a
lot better soon, I promise. Meanwhile, GnuTLS doesn't seem to have
support Certificate Transparency (gnutls#232), but you could export the
extension as DER bytes, so feel free to figure out how to deal with that
in elisp.


On 05/07/2018 14:33, Perry E. Metzger wrote:
> Old thread, but I thought I'd reply on it.
>
> On Sat, 23 Jun 2018 12:23:31 +0200 Lars Ingebrigtsen <larsi@gnus.org>
> wrote:
>> For those who don't know what this is: Some browsers now ship with
>> built-in lists of certificate hashes, so if you're visiting that
>> site and presented with a different than expected certificate,
>> you'll know that somebody else has issued a certificate for the
>> site, and somebody has hijacked the connection.
>>
>> Or, perhaps, that they just lost the private key and had to
>> generate a new certificate and now, oops, everybody that uses the
>> browsers with the built-in list will be unable to visit the site.
> What you depict there never happens. People don't lose keys in such
> circumstances.
>
> Pinning is what is done by sites like gmail to prevent third world
> dictatorships from using stolen certificate credentials to spy on
> their citizens. People who have been victims of this have had their
> email read, been arrested by state security forces for dissent, and
> have been tortured to death for lack of certificate pinning working
> in their browsers.
>
> This is a matter of life and death for many people.
>
>> do this via ELPA, I think.  Whether it's worth doing is another
>> issue; I think the jury is still out on that one...
> Do you think it's worth keeping people from quite literally being
> tortured to death?
>
> For most of the secure HTTP stuff we've been discussing, I would far
> rather be inconvenienced here and there than know my slight extra
> convenience was being paid for in human blood.
>
> Perry

Re: A couple of questions and concerns about Emacs network security

[Perry E. Metzger]

On Thu, 5 Jul 2018 14:50:10 +0100 Jimmy Yuen Ho Wong
<wyuenho@gmail.com> wrote:
> I'm currently doing a second pass for my patch for bug#31946. I also
> have a preliminary OCSP patch. Emacs network security is going to
> be a lot better soon, I promise. Meanwhile, GnuTLS doesn't seem to
> have support Certificate Transparency (gnutls#232), but you could
> export the extension as DER bytes, so feel free to figure out how
> to deal with that in elisp.

In spite of the name "gnu" in "gnutls", gnutls is not FSF or Gnu
software. I think Emacs should be using OpenSSL, as it is a much
better maintained library.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: A couple of questions and concerns about Emacs network security

[Stefan Monnier]

> In spite of the name "gnu" in "gnutls", gnutls is not FSF or Gnu
> software. I think Emacs should be using OpenSSL, as it is a much
> better maintained library.

I don't have a strong preference either way, but I've heard the above
argument combined with arguments of security, but AFAIK gnutls is still
maintained and its security track record is no worse than that
of OpenSSL.

IOW someone really concerned about security would likely choose
something else than OpenSSL or gnutls.  E.g. something not written in
a language that makes it hard to write safe code, for instance.


        Stefan

Re: A couple of questions and concerns about Emacs network security

[Perry E. Metzger]

On Thu, 05 Jul 2018 11:36:55 -0400 Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> > In spite of the name "gnu" in "gnutls", gnutls is not FSF or Gnu
> > software. I think Emacs should be using OpenSSL, as it is a much
> > better maintained library.  
> 
> I don't have a strong preference either way, but I've heard the
> above argument combined with arguments of security, but AFAIK
> gnutls is still maintained and its security track record is no
> worse than that of OpenSSL.

It's had CVEs that OpenSSL hasn't, and admittedly vice versa.

> IOW someone really concerned about security would likely choose
> something else than OpenSSL or gnutls.  E.g. something not written
> in a language that makes it hard to write safe code, for instance.

So if one wants to go down that path, Firefox now uses components
of the cryptographic libraries from Project Everest, in which the code
is almost (but not yet) fully formally verified:

https://project-everest.github.io/

(So far they're just using the HACL* component.)

This goes the whole thing one better.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: A couple of questions and concerns about Emacs network security

[Richard Stallman]

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

I don't know what this issue concretely involves, so I don't have
an opinion about what concretely we should do.  But I'd like to suggest
a possible avenue for choosing a good response.

The idea is that we make sure users see a chance to choose between the
alternatives (convenience and safety) early enough that they won't be
unsafe.  The choice should come with an explanation of each option,
first stating what situations it is recommended for, then what it does.



-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Thu, 05 Jul 2018 18:44:14 -0400
> Cc: larsi@gnus.org, eggert@cs.ucla.edu, wyuenho@gmail.com, emacs-devel@gnu.org
> 
> The idea is that we make sure users see a chance to choose between the
> alternatives (convenience and safety) early enough that they won't be
> unsafe.  The choice should come with an explanation of each option,
> first stating what situations it is recommended for, then what it does.

The early enough part is already in place, I think: the NSM pops up
the first time some security related issue is discovered, and asks the
user to decide what to do about that.  The user then is given the
option of making the decision permanent or only for this particular
connection.

The other part of your proposal is exactly what I think we should do,
and that was the motive behind all my comments to the recent related
bug reports and contributions: we should have the issues and their
remedies explained and documented, so that users could make informed
decisions when those matter.

Re: A couple of questions and concerns about Emacs network security

[Paul Eggert]

On 06/22/2018 04:21 PM, Lars Ingebrigtsen wrote:
> Paul Eggert <eggert@cs.ucla.edu> writes:
>
>> On 06/22/2018 03:00 PM, Jimmy Yuen Ho Wong wrote:
>>> 1. Can we update the default network security settings?
>> Yes, I would think so, in the master branch. As you say, the current
>> defaults are inappropriate for today's users.
> They are?  In what way?

I was concerned about Emacs Lisp code that calls the gnutls API 
directly. However, you wrote in a later message that Emacs Lisp code 
desiring network security should use open-network-stream and use NSM, so 
perhaps very little (if any) Emacs code is like what I was worried 
about. If so, the defaults shouldn't matter too much.

I like your suggestion of changing the doc strings of gnutls.el to make 
it less likely to get future bug reports about this (a la bug#17660 
etc.). I'm not expert enough in GnuTLS to know what should go into those 
doc strings, though.

Re: A couple of questions and concerns about Emacs network security

[Stefan Monnier]

> I like your suggestion of changing the doc strings of gnutls.el to make it
> less likely to get future bug reports about this (a la bug#17660 etc.). I'm
> not expert enough in GnuTLS to know what should go into those doc
> strings, though.

Maybe an alternative is to change those default settings to be extremely
strict, and loosen them as needed/appropriate when we go through the NSM.


        Stefan

Re: A couple of questions and concerns about Emacs network security

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I like your suggestion of changing the doc strings of gnutls.el to make it
>> less likely to get future bug reports about this (a la bug#17660 etc.). I'm
>> not expert enough in GnuTLS to know what should go into those doc
>> strings, though.
>
> Maybe an alternative is to change those default settings to be extremely
> strict, and loosen them as needed/appropriate when we go through the NSM.

Hm...  I may be misunderstanding what you mean here, but do you mean
doing things like set `gnutls-min-prime-bits' to, say, 4096 (extremely
strict :-)), and then have the NSM `medium' `network-security-level'
change the setting back to 256 and reconnect?

If so, that would to me seem to achieve little in practice and just make
all (TLS) network connections slower...

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

Re: A couple of questions and concerns about Emacs network security

[Noam Postavsky]

On 22 June 2018 at 18:43, Paul Eggert <eggert@cs.ucla.edu> wrote:
> On 06/22/2018 03:00 PM, Jimmy Yuen Ho Wong wrote:
>>
>> 1. Can we update the default network security settings?
>
>
> Yes, I would think so, in the master branch. As you say, the current
> defaults are inappropriate for today's users.

Can we bump gnutls-min-prime-bits to 1024 on the release branch? I
know it has a reference to Bug#11267 which describes some mail server
that works only with 256 bits primes, but surely people using such
software can set the option themselves. I mean, a 256 bit DH prime is
just a toy example, not real crypto. It's inappropriate for
yesterday's users. Even 1024 is probably a bit low, but at least it's
something.

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Date: Fri, 22 Jun 2018 22:17:56 -0400
> Cc: Lars Magne Ingebrigtsen <larsi@gnus.org>,
> 	Jimmy Yuen Ho Wong <wyuenho@gmail.com>,
> 	Emacs developers <emacs-devel@gnu.org>
> 
> On 22 June 2018 at 18:43, Paul Eggert <eggert@cs.ucla.edu> wrote:
> > On 06/22/2018 03:00 PM, Jimmy Yuen Ho Wong wrote:
> >>
> >> 1. Can we update the default network security settings?
> >
> >
> > Yes, I would think so, in the master branch. As you say, the current
> > defaults are inappropriate for today's users.
> 
> Can we bump gnutls-min-prime-bits to 1024 on the release branch?

No, I don't think so.  Changing these settings needs a prolonged
testing period to uncover any subtle problems with non-conforming
servers that users must be able to access, and such testing is
unlikely to happen on emacs-26 before the next bug-fix release.

If we change this now on emacs-26, we should probably not release
Emacs 26.2 before a year goes by.

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

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

On Sat, Jun 23, 2018 at 7:40 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Noam Postavsky <npostavs@gmail.com>
> > Date: Fri, 22 Jun 2018 22:17:56 -0400
> > Cc: Lars Magne Ingebrigtsen <larsi@gnus.org>,
> >       Jimmy Yuen Ho Wong <wyuenho@gmail.com>,
> >       Emacs developers <emacs-devel@gnu.org>
> >
> > On 22 June 2018 at 18:43, Paul Eggert <eggert@cs.ucla.edu> wrote:
> > > On 06/22/2018 03:00 PM, Jimmy Yuen Ho Wong wrote:
> > >>
> > >> 1. Can we update the default network security settings?
> > >
> > >
> > > Yes, I would think so, in the master branch. As you say, the current
> > > defaults are inappropriate for today's users.
> >
> > Can we bump gnutls-min-prime-bits to 1024 on the release branch?
>
> No, I don't think so.  Changing these settings needs a prolonged
> testing period to uncover any subtle problems with non-conforming
> servers that users must be able to access, and such testing is
> unlikely to happen on emacs-26 before the next bug-fix release.
>
> If we change this now on emacs-26, we should probably not release
> Emacs 26.2 before a year goes by.
>

I don't understand this. Just because a small amount of people need 256 bit
default to connect to some non-conforming servers, you think the trade-off
should be to use a default that put the vast majority of Emacs users at
risk out of the box?

[-- Attachment #2: Type: text/html, Size: 2080 bytes --]

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> Date: Sat, 23 Jun 2018 11:21:49 +0100
> Cc: Noam Postavsky <npostavs@gmail.com>, Paul Eggert <eggert@cs.ucla.edu>, 
> 	Lars Ingebrigtsen <larsi@gnus.org>, emacs-devel@gnu.org
> 
>  > Can we bump gnutls-min-prime-bits to 1024 on the release branch?
> 
>  No, I don't think so.  Changing these settings needs a prolonged
>  testing period to uncover any subtle problems with non-conforming
>  servers that users must be able to access, and such testing is
>  unlikely to happen on emacs-26 before the next bug-fix release.
> 
>  If we change this now on emacs-26, we should probably not release
>  Emacs 26.2 before a year goes by.
> 
> I don't understand this. Just because a small amount of people need 256 bit default to connect to some
> non-conforming servers, you think the trade-off should be to use a default that put the vast majority of Emacs
> users at risk out of the box?

No, you are missing my point, I think.  I'm saying that changes in
these areas tend to cause unintended breakage, and it takes time to
uncover those and fix them.  We cannot risk such breakage on the
release branch without delaying the next bug-fix release too much.

IOW, this is about the relative importance of other bugs we fixed
since 26.1 and need to be released soon, and this particular issue,
which isn't new.

Re: A couple of questions and concerns about Emacs network security

[Noam Postavsky]

On 23 June 2018 at 02:40, Eli Zaretskii <eliz@gnu.org> wrote:

>> Can we bump gnutls-min-prime-bits to 1024 on the release branch?
>
> No, I don't think so.  Changing these settings needs a prolonged
> testing period to uncover any subtle problems with non-conforming
> servers that users must be able to access, and such testing is
> unlikely to happen on emacs-26 before the next bug-fix release.

I'm not sure what testing would be needed: if the connection to a
server fails, the user sets the variable to the previous default.

Also, would this attack published in 2015 make a difference to the decision?

https://weakdh.org/
https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf

    The Logjam attack allows a man-in-the-middle attacker to downgrade
    vulnerable TLS connections to 512-bit export-grade cryptography.

    RECOMMENDATIONS

        Server operators should disable DHE_EXPORT and configure DHE
        ciphersuites to use primes of 2048 bits or larger. Browsers
        and clients should raise the minimum accepted size for
        Diffie-Hellman groups to at least 1024 bits in order to avoid
        downgrade attacks when communicating with servers that still
        use smaller groups. Primes of less than 1024 bits should not
        be considered secure, even against an attacker with moderate
        resources.

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Date: Sat, 23 Jun 2018 18:28:15 -0400
> Cc: Lars Magne Ingebrigtsen <larsi@gnus.org>, Paul Eggert <eggert@cs.ucla.edu>, 
> 	Jimmy Yuen Ho Wong <wyuenho@gmail.com>, Emacs developers <emacs-devel@gnu.org>
> 
> On 23 June 2018 at 02:40, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> >> Can we bump gnutls-min-prime-bits to 1024 on the release branch?
> >
> > No, I don't think so.  Changing these settings needs a prolonged
> > testing period to uncover any subtle problems with non-conforming
> > servers that users must be able to access, and such testing is
> > unlikely to happen on emacs-26 before the next bug-fix release.
> 
> I'm not sure what testing would be needed: if the connection to a
> server fails, the user sets the variable to the previous default.

If too many users will have to reset to previous defaults, then what
exactly did we accomplish, except annoying those users by having stuff
not work OOTB?

> Also, would this attack published in 2015 make a difference to the decision?
> 
> https://weakdh.org/
> https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf
> 
>     The Logjam attack allows a man-in-the-middle attacker to downgrade
>     vulnerable TLS connections to 512-bit export-grade cryptography.
> 
>     RECOMMENDATIONS
> 
>         Server operators should disable DHE_EXPORT and configure DHE
>         ciphersuites to use primes of 2048 bits or larger. Browsers
>         and clients should raise the minimum accepted size for
>         Diffie-Hellman groups to at least 1024 bits in order to avoid
>         downgrade attacks when communicating with servers that still
>         use smaller groups. Primes of less than 1024 bits should not
>         be considered secure, even against an attacker with moderate
>         resources.

Is this relevant to Emacs?  Given the explanations by Lars here:

  http://lists.gnu.org/archive/html/emacs-devel/2018-06/msg00736.html

having the GnuTLS related values low is by design, so that NSM (and
the users) could be in control of what is allowed, instead of silently
failing connections at a low level.  Am I missing something?

Re: A couple of questions and concerns about Emacs network security

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Is this relevant to Emacs?  Given the explanations by Lars here:
>
>   http://lists.gnu.org/archive/html/emacs-devel/2018-06/msg00736.html
>
> having the GnuTLS related values low is by design, so that NSM (and
> the users) could be in control of what is allowed, instead of silently
> failing connections at a low level.  Am I missing something?

I don't think so, but I partially dropped the ball on this one, for
which I apologise.

I had meant to implement warnings for this stuff on the default `medium'
level instead of letting it remain on the `high' level, but I simply
forgot.  I'll be changing that on master hopefully sometime next week.

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

Re: A couple of questions and concerns about Emacs network security

[Noam Postavsky]

On 24 June 2018 at 10:34, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> I had meant to implement warnings for this stuff on the default `medium'
> level instead of letting it remain on the `high' level, but I simply
> forgot.  I'll be changing that on master hopefully sometime next week.

Yeah, I think that's a good way to block this vulnerability. Though
it's unfortunate that we're still going to release a 26.2 which
silently accepts primes smaller than 1024 bits by default.

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Date: Sun, 24 Jun 2018 10:48:10 -0400
> Cc: Eli Zaretskii <eliz@gnu.org>, Paul Eggert <eggert@cs.ucla.edu>,
> 	Jimmy Yuen Ho Wong <wyuenho@gmail.com>,
> 	Emacs developers <emacs-devel@gnu.org>
> 
> On 24 June 2018 at 10:34, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> 
> > I had meant to implement warnings for this stuff on the default `medium'
> > level instead of letting it remain on the `high' level, but I simply
> > forgot.  I'll be changing that on master hopefully sometime next week.
> 
> Yeah, I think that's a good way to block this vulnerability. Though
> it's unfortunate that we're still going to release a 26.2 which
> silently accepts primes smaller than 1024 bits by default.

When the changes are pushed to master, we could look at them and
consider whether they (or some of their parts) are safe enough for
emacs-26.

Re: A couple of questions and concerns about Emacs network security

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> When the changes are pushed to master, we could look at them and
> consider whether they (or some of their parts) are safe enough for
> emacs-26.

Yup.

I'm going through the current recommendations for TLS security, and most
of them are straightforward and require just some added NSM checks.
However, the check for intermediary sha1 certificates checks requires a
C-level change: gnutls.c doesn't expose to Lisp the certificate chain,
so I'll have to add that, too.

It's not a complicated addition, but it's C level, so you'll have to
decide whether something that has the potential for crashing Emacs is
worth the risk for Emacs 26.2.  But I guess we'll see once I've
implemented this (hopefully next week).

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

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

I have just been looking at how to add OCSP as well, I noticed
`gnutls-boot` already accepts `:crlfiles`, I have a `gnutls.el` patch
that'll supply it to `gnutls-boot-parameters`. I'm testing it now, but
I'm haven't a bit of trouble generating a CRL in PEM. Anyway, do you
think it's worth it as a quick win to include in either master to 26.2
if it works?


On 24/06/2018 17:57, Lars Ingebrigtsen wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>> When the changes are pushed to master, we could look at them and
>> consider whether they (or some of their parts) are safe enough for
>> emacs-26.
> Yup.
>
> I'm going through the current recommendations for TLS security, and most
> of them are straightforward and require just some added NSM checks.
> However, the check for intermediary sha1 certificates checks requires a
> C-level change: gnutls.c doesn't expose to Lisp the certificate chain,
> so I'll have to add that, too.
>
> It's not a complicated addition, but it's C level, so you'll have to
> decide whether something that has the potential for crashing Emacs is
> worth the risk for Emacs 26.2.  But I guess we'll see once I've
> implemented this (hopefully next week).
>

Re: A couple of questions and concerns about Emacs network security

[Lars Ingebrigtsen]

Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:

> I have just been looking at how to add OCSP as well, I noticed
> `gnutls-boot` already accepts `:crlfiles`, I have a `gnutls.el` patch
> that'll supply it to `gnutls-boot-parameters`.

I'm not quite sure I follow you here.  OCSP is the online query stuff,
and is something that gnutls doesn't do, I think, and which is probably
not something we want to do either.  (Chrome doesn't, for instance.)

But a certificate revocation list is something we could consider
distributing via ELPA, but that's a bigger project...

Or do you mean OCSP stapling?  There's so much going on in this area
(because it's a clusterfuck to begin with) that it can be challenging
keeping track.  :-)

> I'm testing it now, but I'm haven't a bit of trouble generating a CRL
> in PEM. Anyway, do you think it's worth it as a quick win to include
> in either master to 26.2 if it works?

If you're talking about distributing a certificate revocation list with
Emacs, I don't think that would be all that useful.

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

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

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

>
>
> I'm not quite sure I follow you here.  OCSP is the online query stuff,
> and is something that gnutls doesn't do, I think, and which is probably
> not something we want to do either.  (Chrome doesn't, for instance.)
>
>
GnuTLS has had the ability to do OCSP since 3.1.3 released back in 2012. This
is how you do it
<https://www.gnutls.org/manual/html_node/OCSP-certificate-status-checking.html#OCSP-certificate-status-checking>
according to the manual.

Chrome's primary check OOTB is its own curated CRLSet, but it does use OCSP
for some EV certs, and relies on the underlying library to do OCSP
<https://dev.chromium.org/Home/chromium-security/crlsets>. You can also
enable it in Chrome if you want.



> But a certificate revocation list is something we could consider
> distributing via ELPA, but that's a bigger project...
>
>
No. Emacs has a defined list of CA bundle PEM files (`gnutls-trustfiles`)
it looks for now, the same can be done for CRL files. Users can
periodically update their CA bundle and CRL bundle. The CA bundle on *nix
is typically Mozilla's, which is covered by the default list in
`gnutls-trustfiles`. A complete list of CRL in PEM format typically don't
exists on most systems, but can be generated with `igtf-ca-bundle` +
`fetch-crl`. I just generated them on macOS via MacPorts, Linux should also
be a matter of installing a few packages and running `fetch-crl`.


> Or do you mean OCSP stapling?  There's so much going on in this area
> (because it's a clusterfuck to begin with) that it can be challenging
> keeping track.  :-)
>
>
Nah, it's just a couple more lines of C code. See GnuTLS's manual on OCSP
above.

[-- Attachment #2: Type: text/html, Size: 2531 bytes --]

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> Date: Sun, 24 Jun 2018 19:29:24 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, Noam Postavsky <npostavs@gmail.com>, Paul Eggert <eggert@cs.ucla.edu>, 
> 	emacs-devel@gnu.org
> 
> Emacs has a defined list of CA bundle PEM files (`gnutls-trustfiles`) it looks for now, the same can be
> done for CRL files. Users can periodically update their CA bundle and CRL bundle.

On my system, GnuTLS uses HAVE_GNUTLS_X509_SYSTEM_TRUST, and
gnutls-trustfiles is not used.  The "system trust" is updated whenever
the system is updated.  I think this is a better arrangement than
asking users to maintain their bundles.

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

[-- Attachment #1.1: Type: text/plain, Size: 2476 bytes --]

Here's the patch to get GnuTLS to do CRL checking.

On Debian, you can get a bunch of CRL PEM files by the following:

    $ sudo apt-get install igtf-policy-bundle
    $ sudo apt-get install fetch-crl
    $ sudo fetch-crl -p 8 --format pem

On macOS with MacPorts:

    $ sudo port install igtf-ca-bundle
    $ sudo fetch-crl -p 8 --format pem

Now if you do

  M-: (url-retrieve-synchronously "https://revoked.grc.com/") RET

You should see a prompt from NSM.

Possible improvement:

Checking static CRL is still spotty. "https://revoked.badssl.com" still
fails to trigger a prompt from NSM. For that we'll definitely need OCSP and
some of the newer Certificate Transparency tricks.


On Sun, Jun 24, 2018 at 7:29 PM, Jimmy Yuen Ho Wong <wyuenho@gmail.com>
wrote:

>
>> I'm not quite sure I follow you here.  OCSP is the online query stuff,
>> and is something that gnutls doesn't do, I think, and which is probably
>> not something we want to do either.  (Chrome doesn't, for instance.)
>>
>>
> GnuTLS has had the ability to do OCSP since 3.1.3 released back in 2012. This
> is how you do it
> <https://www.gnutls.org/manual/html_node/OCSP-certificate-status-checking.html#OCSP-certificate-status-checking>
> according to the manual.
>
> Chrome's primary check OOTB is its own curated CRLSet, but it does use
> OCSP for some EV certs, and relies on the underlying library to do OCSP
> <https://dev.chromium.org/Home/chromium-security/crlsets>. You can also
> enable it in Chrome if you want.
>
>
>
>> But a certificate revocation list is something we could consider
>> distributing via ELPA, but that's a bigger project...
>>
>>
> No. Emacs has a defined list of CA bundle PEM files (`gnutls-trustfiles`)
> it looks for now, the same can be done for CRL files. Users can
> periodically update their CA bundle and CRL bundle. The CA bundle on *nix
> is typically Mozilla's, which is covered by the default list in
> `gnutls-trustfiles`. A complete list of CRL in PEM format typically don't
> exists on most systems, but can be generated with `igtf-ca-bundle` +
> `fetch-crl`. I just generated them on macOS via MacPorts, Linux should also
> be a matter of installing a few packages and running `fetch-crl`.
>
>
>> Or do you mean OCSP stapling?  There's so much going on in this area
>> (because it's a clusterfuck to begin with) that it can be challenging
>> keeping track.  :-)
>>
>>
> Nah, it's just a couple more lines of C code. See GnuTLS's manual on OCSP
> above.
>
>

[-- Attachment #1.2: Type: text/html, Size: 4032 bytes --]

[-- Attachment #2: 0001-Check-TLS-certs-against-CRL.patch --]
[-- Type: application/octet-stream, Size: 3140 bytes --]

From 9938360f7388ffe92a6979a409d684bbb2c5d867 Mon Sep 17 00:00:00 2001
From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
Date: Sun, 24 Jun 2018 22:08:28 +0100
Subject: [PATCH] Check TLS certs against CRL

* lisp/net/gnutls.el (gnutls-boot-parameters): Return
  `gnutls-crlfiles' in `:crlfiles'.
  (gnutls-crlfiles): New defcustom.
  (gnutls--get-files): New defun.
  (gnutls-trustfiles, gnutls-crlfiles): Delegate to
  `gnutls--get-files' to return a list of filenames, accepts glob pattern.
---
 lisp/net/gnutls.el | 29 ++++++++++++++++++++++++-----
 1 file changed, 24 insertions(+), 5 deletions(-)

diff --git a/lisp/net/gnutls.el b/lisp/net/gnutls.el
index 09df019e2e..dff3ce2ec6 100644
--- a/lisp/net/gnutls.el
+++ b/lisp/net/gnutls.el
@@ -96,12 +96,25 @@ gnutls-trustfiles
     "/etc/ssl/cert.pem"                      ; macOS
     )
   "List of CA bundle location filenames or a function returning said list.
+If a file path contains a glob pattern, it will be expanded.
 The files may be in PEM or DER format, as per the GnuTLS documentation.
 The files may not exist, in which case they will be ignored."
   :group 'gnutls
   :type '(choice (function :tag "Function to produce list of bundle filenames")
                  (repeat (file :tag "Bundle filename"))))
 
+(defcustom gnutls-crlfiles
+  '(
+    "/etc/grid-security/certificates/*.crl.pem"
+    )
+  "List of CRL file paths or a function returning said list.
+If a file path contains a glob pattern, it will be expanded.
+The files may be in PEM or DER format, as per the GnuTLS documentation.
+The files may not exist, in which case they will be ignored."
+  :group 'gnutls
+  :type '(choice (function :tag "Function to produce list of CRL filenames")
+                 (repeat (file :tag "CRL filename"))))
+
 ;;;###autoload
 (defcustom gnutls-min-prime-bits 256
   ;; Several mail servers send fewer bits than the GnuTLS default.
@@ -263,6 +276,7 @@ gnutls-log-level
 It must be omitted, a number, or nil; if omitted or nil it
 defaults to GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT."
   (let* ((trustfiles (or trustfiles (gnutls-trustfiles)))
+         (crlfiles (or crlfiles (gnutls-crlfiles)))
          (maybe-dumbfw (if (memq 'ClientHello\ Padding (gnutls-available-p))
                            ":%DUMBFW"
                          ""))
@@ -304,13 +318,18 @@ gnutls-log-level
                 :verify-error ,verify-error
                 :callbacks nil)))
 
+(defun gnutls--get-files (files)
+  (cl-loop for f in files
+           if f do (setq f (if (functionp f) (funcall f) f))
+           append (cl-delete-if-not #'file-exists-p (file-expand-wildcards f t))))
+
 (defun gnutls-trustfiles ()
   "Return a list of usable trustfiles."
-  (delq nil
-        (mapcar (lambda (f) (and f (file-exists-p f) f))
-                (if (functionp gnutls-trustfiles)
-                    (funcall gnutls-trustfiles)
-                  gnutls-trustfiles))))
+  (gnutls--get-files gnutls-trustfiles))
+
+(defun gnutls-crlfiles ()
+  "Return a list of usable CRL files."
+  (gnutls--get-files gnutls-crlfiles))
 
 (declare-function gnutls-error-string "gnutls.c" (error))
 
-- 
2.18.0

Re: A couple of questions and concerns about Emacs network security

[Van L]

> Jimmy Yuen Ho Wong wrote:
> 
> On Debian, you can get a bunch of CRL PEM files by the following:
> 
>     $ sudo apt-get install igtf-policy-bundle
>     $ sudo apt-get install fetch-crl
>     $ sudo fetch-crl -p 8 --format pem

On Debian (stretch), do you change sources.list?

  All packages are up to date.
  /etc/apt # apt install igtf-policy-bundle
  Reading package lists... Done
  Building dependency tree
  Reading state information... Done
  E: Unable to locate package igtf-policy-bundle 

There are `igtf-policy-` things but not `bundle`:

  https://packages.debian.org/stretch/igtf-policy-iota

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

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

It's in misc, so yes, you have to edit sources.list.

https://packages.debian.org/source/stretch/igtf-policy-bundle

On Mon, Jun 25, 2018 at 2:25 AM, Van L <van@scratch.space> wrote:

>
> > Jimmy Yuen Ho Wong wrote:
> >
> > On Debian, you can get a bunch of CRL PEM files by the following:
> >
> >     $ sudo apt-get install igtf-policy-bundle
> >     $ sudo apt-get install fetch-crl
> >     $ sudo fetch-crl -p 8 --format pem
>
> On Debian (stretch), do you change sources.list?
>
>   All packages are up to date.
>   /etc/apt # apt install igtf-policy-bundle
>   Reading package lists... Done
>   Building dependency tree
>   Reading state information... Done
>   E: Unable to locate package igtf-policy-bundle
>
> There are `igtf-policy-` things but not `bundle`:
>
>   https://packages.debian.org/stretch/igtf-policy-iota
>

[-- Attachment #2: Type: text/html, Size: 1484 bytes --]

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

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

Actually sorry, that's the source package. You should probably install
igtf-policy-classic.

On Mon, Jun 25, 2018 at 3:28 AM, Jimmy Yuen Ho Wong <wyuenho@gmail.com>
wrote:

> It's in misc, so yes, you have to edit sources.list.
>
> https://packages.debian.org/source/stretch/igtf-policy-bundle
>
> On Mon, Jun 25, 2018 at 2:25 AM, Van L <van@scratch.space> wrote:
>
>>
>> > Jimmy Yuen Ho Wong wrote:
>> >
>> > On Debian, you can get a bunch of CRL PEM files by the following:
>> >
>> >     $ sudo apt-get install igtf-policy-bundle
>> >     $ sudo apt-get install fetch-crl
>> >     $ sudo fetch-crl -p 8 --format pem
>>
>> On Debian (stretch), do you change sources.list?
>>
>>   All packages are up to date.
>>   /etc/apt # apt install igtf-policy-bundle
>>   Reading package lists... Done
>>   Building dependency tree
>>   Reading state information... Done
>>   E: Unable to locate package igtf-policy-bundle
>>
>> There are `igtf-policy-` things but not `bundle`:
>>
>>   https://packages.debian.org/stretch/igtf-policy-iota
>>
>
>

[-- Attachment #2: Type: text/html, Size: 2009 bytes --]

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> Date: Sun, 24 Jun 2018 22:30:50 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, Paul Eggert <eggert@cs.ucla.edu>,
> 	Noam Postavsky <npostavs@gmail.com>, emacs-devel@gnu.org
> 
> Here's the patch to get GnuTLS to do CRL checking.

Thanks, a few minor comments:

> +(defcustom gnutls-crlfiles
> +  '(
> +    "/etc/grid-security/certificates/*.crl.pem"
> +    )
> +  "List of CRL file paths or a function returning said list.
> +If a file path contains a glob pattern, it will be expanded.
> +The files may be in PEM or DER format, as per the GnuTLS documentation.
> +The files may not exist, in which case they will be ignored."
> +  :group 'gnutls
> +  :type '(choice (function :tag "Function to produce list of CRL filenames")
> +                 (repeat (file :tag "CRL filename"))))

This should have a :version tag.

Do we really want/need to allow a function here?  Isn't a list of
files enough?  A function is more dangerous than a string, especially
in a security-sensitive place.

Finally, I think this defcustom needs to be called out in NEWS.

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

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

>
> This should have a :version tag.
>

I'll update the patch.


>
> Do we really want/need to allow a function here?  Isn't a list of
> files enough?  A function is more dangerous than a string, especially
> in a security-sensitive place.
>

It's just convenient. fetch-crl will generate close to 100+ CRL PEM files,
so it's a bit impractical to enter by hand.

Thanks for reviewing!

[-- Attachment #2: Type: text/html, Size: 878 bytes --]

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

[-- Attachment #1.1: Type: text/plain, Size: 1715 bytes --]

Here's the updated patch.

Suggested material to include in the manual or NEWS:

Emacs now has preliminary checks for revoked TLS certificates. To utililize
this feature, users are advised to install the IGTF trust anchor
distribution and FetchCRL packages for their system, and update their
.crl.pem files periodically in order to get the most updated Certificate
Revocation Lists. Refer to the docstring of `gnutls-crlfiles' for details
on how to supply their file locations to Emacs.



On Mon, Jun 25, 2018 at 6:16 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> > Date: Sun, 24 Jun 2018 22:30:50 +0100
> > Cc: Eli Zaretskii <eliz@gnu.org>, Paul Eggert <eggert@cs.ucla.edu>,
> >       Noam Postavsky <npostavs@gmail.com>, emacs-devel@gnu.org
> >
> > Here's the patch to get GnuTLS to do CRL checking.
>
> Thanks, a few minor comments:
>
> > +(defcustom gnutls-crlfiles
> > +  '(
> > +    "/etc/grid-security/certificates/*.crl.pem"
> > +    )
> > +  "List of CRL file paths or a function returning said list.
> > +If a file path contains a glob pattern, it will be expanded.
> > +The files may be in PEM or DER format, as per the GnuTLS documentation.
> > +The files may not exist, in which case they will be ignored."
> > +  :group 'gnutls
> > +  :type '(choice (function :tag "Function to produce list of CRL
> filenames")
> > +                 (repeat (file :tag "CRL filename"))))
>
> This should have a :version tag.
>
> Do we really want/need to allow a function here?  Isn't a list of
> files enough?  A function is more dangerous than a string, especially
> in a security-sensitive place.
>
> Finally, I think this defcustom needs to be called out in NEWS.
>

[-- Attachment #1.2: Type: text/html, Size: 2577 bytes --]

[-- Attachment #2: 0001-Check-TLS-certs-against-CRL.patch --]
[-- Type: application/octet-stream, Size: 3164 bytes --]

From 9a9b4232a28fc8a20d0d217e90541f5c7e27c7dd Mon Sep 17 00:00:00 2001
From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
Date: Mon, 25 Jun 2018 18:46:57 +0100
Subject: [PATCH] Check TLS certs against CRL

* lisp/net/gnutls.el (gnutls-boot-parameters): Return
  `gnutls-crlfiles' in `:crlfiles'.
  (gnutls-crlfiles): New defcustom.
  (gnutls--get-files): New defun.
  (gnutls-trustfiles, gnutls-crlfiles): Delegate to
  `gnutls--get-files' to return a list of filenames, accepts glob pattern.
---
 lisp/net/gnutls.el | 30 +++++++++++++++++++++++++-----
 1 file changed, 25 insertions(+), 5 deletions(-)

diff --git a/lisp/net/gnutls.el b/lisp/net/gnutls.el
index 09df019e2e..650dbf8943 100644
--- a/lisp/net/gnutls.el
+++ b/lisp/net/gnutls.el
@@ -96,12 +96,26 @@ gnutls-trustfiles
     "/etc/ssl/cert.pem"                      ; macOS
     )
   "List of CA bundle location filenames or a function returning said list.
+If a file path contains glob wildcards, they will be expanded.
 The files may be in PEM or DER format, as per the GnuTLS documentation.
 The files may not exist, in which case they will be ignored."
   :group 'gnutls
   :type '(choice (function :tag "Function to produce list of bundle filenames")
                  (repeat (file :tag "Bundle filename"))))
 
+(defcustom gnutls-crlfiles
+  '(
+    "/etc/grid-security/certificates/*.crl.pem"
+    )
+  "List of CRL file paths or a function returning said list.
+If a file path contains glob wildcards, they will be expanded.
+The files may be in PEM or DER format, as per the GnuTLS documentation.
+The files may not exist, in which case they will be ignored."
+  :group 'gnutls
+  :type '(choice (function :tag "Function to produce list of CRL filenames")
+                 (repeat (file :tag "CRL filename")))
+  :version "27.1")
+
 ;;;###autoload
 (defcustom gnutls-min-prime-bits 256
   ;; Several mail servers send fewer bits than the GnuTLS default.
@@ -263,6 +277,7 @@ gnutls-log-level
 It must be omitted, a number, or nil; if omitted or nil it
 defaults to GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT."
   (let* ((trustfiles (or trustfiles (gnutls-trustfiles)))
+         (crlfiles (or crlfiles (gnutls-crlfiles)))
          (maybe-dumbfw (if (memq 'ClientHello\ Padding (gnutls-available-p))
                            ":%DUMBFW"
                          ""))
@@ -304,13 +319,18 @@ gnutls-log-level
                 :verify-error ,verify-error
                 :callbacks nil)))
 
+(defun gnutls--get-files (files)
+  (cl-loop for f in files
+           if f do (setq f (if (functionp f) (funcall f) f))
+           append (cl-delete-if-not #'file-exists-p (file-expand-wildcards f t))))
+
 (defun gnutls-trustfiles ()
   "Return a list of usable trustfiles."
-  (delq nil
-        (mapcar (lambda (f) (and f (file-exists-p f) f))
-                (if (functionp gnutls-trustfiles)
-                    (funcall gnutls-trustfiles)
-                  gnutls-trustfiles))))
+  (gnutls--get-files gnutls-trustfiles))
+
+(defun gnutls-crlfiles ()
+  "Return a list of usable CRL files."
+  (gnutls--get-files gnutls-crlfiles))
 
 (declare-function gnutls-error-string "gnutls.c" (error))
 
-- 
2.18.0

Re: A couple of questions and concerns about Emacs network security

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I had meant to implement warnings for this stuff on the default `medium'
> level instead of letting it remain on the `high' level, but I simply
> forgot.  I'll be changing that on master hopefully sometime next week.

Or today!

I've now pushed the changes to master, so let me know if I accidentally
broke all Emacs network traffic.  It seems to be working OK for me,
though...

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

Re: A couple of questions and concerns about Emacs network security

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I've now pushed the changes to master, so let me know if I accidentally
> broke all Emacs network traffic.  It seems to be working OK for me,
> though...

(And we may want to tweak what tests are on the `medium' level.  Let me
know whether the tests trigger a lot in an annoying way.)

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

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

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

The sha1-intermediate test still fails on 'medium. Also, shouldn't
`network-security-protocol-checks' be a defcustom? Lastly, are the
dh-small-subgroup and dh-composite tests possible to check in LISP?

Thanks for your work!

On Sun, Jun 24, 2018 at 10:07 PM, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
> > I've now pushed the changes to master, so let me know if I accidentally
> > broke all Emacs network traffic.  It seems to be working OK for me,
> > though...
>
> (And we may want to tweak what tests are on the `medium' level.  Let me
> know whether the tests trigger a lot in an annoying way.)
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>

[-- Attachment #2: Type: text/html, Size: 1331 bytes --]

Re: A couple of questions and concerns about Emacs network security

[Lars Ingebrigtsen]

Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:

> The sha1-intermediate test still fails on 'medium.

Hm!  I thought the problem was with SHA1 for intermediate certificates,
not root certificates?  But this is the certificate chain from

https://sha1-intermediate.badssl.com/

 ((:version 3 :serial-number "00:be:00:42:69:d7:58:79:57:10:3c:04:e7:aa:4e:d8:b2" :issuer "C=GB,ST=Greater Manchester,L=Salford,O=COMODO CA Limited,CN=COMODO SSL CA" :valid-from "2017-04-13" :valid-to "2020-05-30" :subject "OU=Domain Control Validated,OU=COMODO SSL Wildcard,CN=*.badssl.com" :public-key-algorithm "RSA" :certificate-security-level "Medium" :signature-algorithm "RSA-SHA256")
  (:version 3 :serial-number "6e:ba:f0:8f:79:83:fa:9d:e1:b2:6f:96:fc:6e:98:bf" :issuer "C=SE,O=AddTrust AB,OU=AddTrust External TTP Network,CN=AddTrust External CA Root" :valid-from "2011-08-23" :valid-to "2020-05-30" :subject "C=GB,ST=Greater Manchester,L=Salford,O=COMODO CA Limited,CN=COMODO SSL CA" :public-key-algorithm "RSA" :certificate-security-level "Medium" :signature-algorithm "RSA-SHA1"))

So the SHA1 is in the last certificate there, but it's the
intermediary...

Here's the one from eternal-september:

 ((:version 3 :serial-number "03:6f:ea:f0:ef:6e:57:9c:11:94:8c:1d:0e:9e:5a:a5:a7:8d" :issuer "C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3" :valid-from "2018-05-07" :valid-to "2018-08-05" :subject "CN=news.eternal-september.org" :public-key-algorithm "RSA" :certificate-security-level "Medium" :signature-algorithm "RSA-SHA256")
  (:version 3 :serial-number "0a:01:41:42:00:00:01:53:85:73:6a:0b:85:ec:a7:08" :issuer "O=Digital Signature Trust Co.,CN=DST Root CA X3" :valid-from "2016-03-17" :valid-to "2021-03-17" :subject "C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3" :public-key-algorithm "RSA" :certificate-security-level "Medium" :signature-algorithm "RSA-SHA256")
  (:version 3 :serial-number "44:af:b0:80:d6:a3:27:ba:89:30:39:86:2e:f8:40:6b" :issuer "O=Digital Signature Trust Co.,CN=DST Root CA X3" :valid-from "2000-09-30" :valid-to "2021-09-30" :subject "O=Digital Signature Trust Co.,CN=DST Root CA X3" :public-key-algorithm "RSA" :certificate-security-level "Medium" :signature-algorithm "RSA-SHA1"))

The third certificate here also has SHA1...  but that's the root
certificate?

*google*  Oh, I see.  Some servers include the root certificate
(redundantly), and some don't.  How do I determine whether a certificate
is a root certificate, then?  There must be a way...  I tried googling
but didn't immediately find anything.

> Also, shouldn't `network-security-protocol-checks' be a defcustom?

Possibly, but editing alists in customize isn't very pleasant.

> Lastly, are the dh-small-subgroup and dh-composite tests possible to
> check in LISP?

I wondered about that, too.  I couldn't find anything in the gnutls API,
but it's pretty big and I could well have missed something.

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

Re: A couple of questions and concerns about Emacs network security

[Noam Postavsky]

On 24 June 2018 at 20:04, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> *google*  Oh, I see.  Some servers include the root certificate
> (redundantly), and some don't.  How do I determine whether a certificate
> is a root certificate, then?  There must be a way...  I tried googling
> but didn't immediately find anything.

Check if :issuer equals :subject?

Re: A couple of questions and concerns about Emacs network security

[Lars Ingebrigtsen]

Noam Postavsky <npostavs@gmail.com> writes:

> On 24 June 2018 at 20:04, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
>> *google*  Oh, I see.  Some servers include the root certificate
>> (redundantly), and some don't.  How do I determine whether a certificate
>> is a root certificate, then?  There must be a way...  I tried googling
>> but didn't immediately find anything.
>
> Check if :issuer equals :subject?

Ah, yes, of course.  Thanks.

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

Re: A couple of questions and concerns about Emacs network security

[Noam Postavsky]

On 24 June 2018 at 16:58, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> I've now pushed the changes to master, so let me know if I accidentally
> broke all Emacs network traffic.  It seems to be working OK for me,
> though...

Seems to be working for me too.

I noticed a bit of copy-pasta in the manual updates:

+@item @acronym{3DES} cipther
+The @acronym{RC4} stream cipher is believed by some to be of low
+quality and may allow eavesdropping by third parties.

Perhaps something along the lines of:

@item @acronym{3DES} cipher
The @acronym{3DES} stream cipher provides at most 112 bits of
effective security, which is considered to be towards the low end.

Re: A couple of questions and concerns about Emacs network security

[Lars Ingebrigtsen]

Noam Postavsky <npostavs@gmail.com> writes:

> Perhaps something along the lines of:
>
> @item @acronym{3DES} cipher
> The @acronym{3DES} stream cipher provides at most 112 bits of
> effective security, which is considered to be towards the low end.

Thanks; updated.

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

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: eggert@cs.ucla.edu,  emacs-devel@gnu.org,  Noam Postavsky <npostavs@gmail.com>,  wyuenho@gmail.com
> Date: Sun, 24 Jun 2018 22:58:28 +0200
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > I had meant to implement warnings for this stuff on the default `medium'
> > level instead of letting it remain on the `high' level, but I simply
> > forgot.  I'll be changing that on master hopefully sometime next week.
> 
> Or today!
> 
> I've now pushed the changes to master, so let me know if I accidentally
> broke all Emacs network traffic.  It seems to be working OK for me,
> though...

Thanks for working on this.

Allow me a few comments, with an eye towards getting at least some of
this to the emacs-26 branch:

 . First, the NEWS entry should tell users how to get the previous
   (less secure) behavior if they want.  I think this also calls for a
   better documentation of the elements that can appear in
   network-security-protocol-checks.

 . The change to gnutls-peer-status is not reflected in its doc string
   and is not called out in NEWS.

 . Do I understand correctly that most of the changes, including those
   in gnutls.c, are so that intermediary certificates could be
   verified?  If so, would it make sense to omit that for emacs-26,
   and only beef up the medium level of security in NSM with the rest
   of the checks?

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

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

My CRL patch should work on Emacs 26.x as well. Sorry I don't know how you
typically submit patches, so I just replied in the email chain. Let me know
if that's not sufficient.

On Mon, Jun 25, 2018 at 5:06 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Lars Ingebrigtsen <larsi@gnus.org>
> > Cc: eggert@cs.ucla.edu,  emacs-devel@gnu.org,  Noam Postavsky <
> npostavs@gmail.com>,  wyuenho@gmail.com
> > Date: Sun, 24 Jun 2018 22:58:28 +0200
> >
> > Lars Ingebrigtsen <larsi@gnus.org> writes:
> >
> > > I had meant to implement warnings for this stuff on the default
> `medium'
> > > level instead of letting it remain on the `high' level, but I simply
> > > forgot.  I'll be changing that on master hopefully sometime next week.
> >
> > Or today!
> >
> > I've now pushed the changes to master, so let me know if I accidentally
> > broke all Emacs network traffic.  It seems to be working OK for me,
> > though...
>
> Thanks for working on this.
>
> Allow me a few comments, with an eye towards getting at least some of
> this to the emacs-26 branch:
>
>  . First, the NEWS entry should tell users how to get the previous
>    (less secure) behavior if they want.  I think this also calls for a
>    better documentation of the elements that can appear in
>    network-security-protocol-checks.
>
>  . The change to gnutls-peer-status is not reflected in its doc string
>    and is not called out in NEWS.
>
>  . Do I understand correctly that most of the changes, including those
>    in gnutls.c, are so that intermediary certificates could be
>    verified?  If so, would it make sense to omit that for emacs-26,
>    and only beef up the medium level of security in NSM with the rest
>    of the checks?
>

[-- Attachment #2: Type: text/html, Size: 2489 bytes --]

Re: A couple of questions and concerns about Emacs network security

[Lars Ingebrigtsen]

Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:

> My CRL patch should work on Emacs 26.x as well. Sorry I don't know how you
> typically submit patches, so I just replied in the email chain. Let me know if
> that's not sufficient.

Sorry; I haven't reviewed the patch yet, but I'll try to do so later
this week.

Do you have FSF copyright assignment papers on file?

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

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

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

No I don't. How do I do that? Thanks in advance for reviewing the patch.

On Mon, 25 Jun 2018 at 5:58 pm, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:
>
> > My CRL patch should work on Emacs 26.x as well. Sorry I don't know how
> you
> > typically submit patches, so I just replied in the email chain. Let me
> know if
> > that's not sufficient.
>
> Sorry; I haven't reviewed the patch yet, but I'll try to do so later
> this week.
>
> Do you have FSF copyright assignment papers on file?
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>

[-- Attachment #2: Type: text/html, Size: 1105 bytes --]

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> Date: Mon, 25 Jun 2018 18:08:37 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, Emacs-Devel devel <emacs-devel@gnu.org>, 
> 	Noam Postavsky <npostavs@gmail.com>, Paul Eggert <eggert@cs.ucla.edu>
> 
> No I don't. How do I do that? Thanks in advance for reviewing the patch.

Form sent off-list.

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

I've signed the copyright assignment form. Gnu should have my records
on file now.

Thanks.

On Mon, Jun 25, 2018 at 6:18 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
>> Date: Mon, 25 Jun 2018 18:08:37 +0100
>> Cc: Eli Zaretskii <eliz@gnu.org>, Emacs-Devel devel <emacs-devel@gnu.org>,
>>       Noam Postavsky <npostavs@gmail.com>, Paul Eggert <eggert@cs.ucla.edu>
>>
>> No I don't. How do I do that? Thanks in advance for reviewing the patch.
>
> Form sent off-list.

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> Date: Sat, 30 Jun 2018 18:40:27 +0100
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Emacs-Devel devel <emacs-devel@gnu.org>, 
> 	Noam Postavsky <npostavs@gmail.com>, Paul Eggert <eggert@cs.ucla.edu>
> 
> I've signed the copyright assignment form. Gnu should have my records
> on file now.

Not yet, they don't.  I guess we need to wait for a few more days.

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Paul Eggert <eggert@cs.ucla.edu>,  Emacs-Devel devel <emacs-devel@gnu.org>,  Noam Postavsky <npostavs@gmail.com>
> Date: Mon, 25 Jun 2018 18:58:27 +0200
> 
> Do you have FSF copyright assignment papers on file?

No.  But the patch is small enough to be considered "tiny".

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> Date: Mon, 25 Jun 2018 17:29:32 +0100
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Paul Eggert <eggert@cs.ucla.edu>,
> 	Noam Postavsky <npostavs@gmail.com>,
> 	Emacs-Devel devel <emacs-devel@gnu.org>
> 
> My CRL patch should work on Emacs 26.x as well.

It's a new feature, so I think it should go to master.

Thanks.

Re: A couple of questions and concerns about Emacs network security

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Allow me a few comments, with an eye towards getting at least some of
> this to the emacs-26 branch:
>
>  . First, the NEWS entry should tell users how to get the previous
>    (less secure) behavior if they want.  I think this also calls for a
>    better documentation of the elements that can appear in
>    network-security-protocol-checks.
>
>  . The change to gnutls-peer-status is not reflected in its doc string
>    and is not called out in NEWS.

Yes, true.  I'll do that later this week.

>  . Do I understand correctly that most of the changes, including those
>    in gnutls.c, are so that intermediary certificates could be
>    verified?  If so, would it make sense to omit that for emacs-26,
>    and only beef up the medium level of security in NSM with the rest
>    of the checks?

Yes, that is definitely a possibility.  The nsm.el changes should be
safe to backport (after they've been in master for a couple of weeks so
that people can test them), while the gnutls.c change might be more
dangerous.

However, the thing that's protecting against (a SHA1 intermediate
certificate (oops, I see I've called it "intermediary" in the code and
doc; I'll fix that now)) is, I seem to remember, now being considered a
realistic attack (i.e., you can generate valid-looking fake certificates
based on one).

Or do I misremember?  I tried googling now, and I couldn't find anybody
actually achieving that yet...

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

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: eggert@cs.ucla.edu,  emacs-devel@gnu.org,  npostavs@gmail.com,  wyuenho@gmail.com
> Date: Mon, 25 Jun 2018 18:55:22 +0200
> 
> >  . Do I understand correctly that most of the changes, including those
> >    in gnutls.c, are so that intermediary certificates could be
> >    verified?  If so, would it make sense to omit that for emacs-26,
> >    and only beef up the medium level of security in NSM with the rest
> >    of the checks?
> 
> Yes, that is definitely a possibility.  The nsm.el changes should be
> safe to backport (after they've been in master for a couple of weeks so
> that people can test them), while the gnutls.c change might be more
> dangerous.
> 
> However, the thing that's protecting against (a SHA1 intermediate
> certificate (oops, I see I've called it "intermediary" in the code and
> doc; I'll fix that now)) is, I seem to remember, now being considered a
> realistic attack (i.e., you can generate valid-looking fake certificates
> based on one).

If this is deemed a very serious vulnerability (I'm not an expert on
these matters), then I guess we will have to wait longer before we
backport the changes to emacs-26.

Thanks.

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

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

>
> However, the thing that's protecting against (a SHA1 intermediate
> certificate (oops, I see I've called it "intermediary" in the code and
> doc; I'll fix that now)) is, I seem to remember, now being considered a
> realistic attack (i.e., you can generate valid-looking fake certificates
> based on one).
>
> Or do I misremember?  I tried googling now, and I couldn't find anybody
> actually achieving that yet...
>
>
It's all about collisions[1], it's mostly a precaution, as no one has found
an actual collistion for a cert yet, but Google has found collision for PDF
last year [2].

[1]: https://blog.chromium.org/2014/09/gradually-sunsetting-sha-1.html
[2]: https://shattered.io/

[-- Attachment #2: Type: text/html, Size: 1158 bytes --]

Re: A couple of questions and concerns about Emacs network security

[Lars Ingebrigtsen]

Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:

> It's all about collisions[1], it's mostly a precaution, as no one has found an
> actual collistion for a cert yet, but Google has found collision for PDF last year
> [2].

Ah, OK, then the SHA1 intermediate check isn't that vital.

(I think the PDF collision was a cheat, anyway, since they just generated
a lot of binary junk in a non-parsed section of the PDF.  :-) )

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

Re: A couple of questions and concerns about Emacs network security

[Perry E. Metzger]

On Mon, 25 Jun 2018 19:33:49 +0200 Lars Ingebrigtsen <larsi@gnus.org>
wrote:
> Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:
> 
> > It's all about collisions[1], it's mostly a precaution, as no one
> > has found an actual collistion for a cert yet, but Google has
> > found collision for PDF last year [2].  
> 
> Ah, OK, then the SHA1 intermediate check isn't that vital.

It is, actually. It's believed to be straightforward for national
actors to forge intermediate certificates at this point.

> (I think the PDF collision was a cheat, anyway, since they just
> generated a lot of binary junk in a non-parsed section of the
> PDF.  :-) )

One of the rules in this game is attacks get better with time. Not
that long after the first certificational attacks on MD5, it was
discovered that parties unknown, generally thought to be nation-state
actors, had been forging signatures on Microsoft software updates
using MD5 collisions to enable what they were doing.

I would make sure that SHA-1 defenses are in place.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

Ok I think I should let people know what my current plans are to avoid
miscommunications:

1. Certificate pinning - HTTP Public Key Pinning is currently used by
some browsers, but it's problematic. Chrome will remove it in Chrome
69[1] and go full-on Certificate Transparency (CT).

2. NSM has its own kind of certificate pinning, which is basically
reinventing `$gnutls-cli --tofu`. It has a couple of problems, such as
not being able to store multiple fingerprints (Google load balance
between 2 certs signed by 2 different public keys), I have fixed them
in my branch. I'll publish it soon.

3. There are a few security theatrics in NSM ATM, 'paranoid level is
BS. If that level is justified, you can justify turning off your
network card. I have removed it in my branch.

4. Certificate pinning is only a very very very small part of the
entire suite of measures needed to securely deploy TLS on the client.
There are a whole host of cipher suite and TLS extension checks
missing in NSM currently. The current set of best practices RFC is RFC
7525. I have implemented most of the recommendations minus those not
applicable to GnuTLS and some big ones like OCSP and CT.

5. The way `gnutls-min-prime-bits` was handled in whatever that bug
number was was never appropriate. 256-bit default was never a good
idea. I have defaulted it to `nil` in my branch, which tells GnuTLS to
use an appropriate bit length according to the priority string
(generally > 1024). If this breaks anyone's config, they have one of 2
options - 1) manually set `gnutls-min-prime-bits` back to whatever you
were using and keep putting yourself at risk, and/or 2) complaint to
your server's admin.

6. GnuTLS is behind in some features such as CT, and enables a shit
ton of ciphers by default that OpenSSL has disabled. It's so seldomly
used and looked at by researchers that I bet it's full of holes.
Paradoxically, this is also its advantage. It's so seldomly used,
mostly OpenSSL specific attacks don't apply to it. I'm not too
concerned about GnuTLS at the moment.

7. Here's a preview of the latest set of checks in my fix-nsm-branch


(defcustom nsm-tls-checks
  '((nsm-tls-check-verify-cert            . low)
    (nsm-tls-check-same-cert              . medium)
    (nsm-tls-check-version                . medium)
    (nsm-tls-check-compression            . medium)
    (nsm-tls-check-renegotiation-info-ext . medium)
    (nsm-tls-check-null-suite             . medium)
    (nsm-tls-check-cbc-cipher             . high)
    (nsm-tls-check-ecdsa-cbc-cipher       . medium)
    (nsm-tls-check-3des-cipher            . medium)
    (nsm-tls-check-rc4-cipher             . medium)
    (nsm-tls-check-sha1-sig               . medium)
    (nsm-tls-check-md5-sig                . medium)
    (nsm-tls-check-rsa-kx                 . high)
    (nsm-tls-check-dhe-prime-kx           . medium)
    (nsm-tls-check-dhe-kx                 . high)
    (nsm-tls-check-export-kx              . medium)
    (nsm-tls-check-anon-kx                . medium))
  "This variable specifies what TLS connection checks to perform.
It's an alist where the key is the name of the check, and the
value is the minimum security level the check should begin.

Each check function is called with the parameters HOST PORT
STATUS SETTINGS.  HOST is the host domain, PORT is a TCP port
number, STATUS is the peer status returned by
`gnutls-peer-status', and SETTINGS is the persistent and session
settings for the host HOST.  Please refer to the contents of
`nsm-setting-file' for details.  If a problem is found, the check
function is required to return an error message, and nil
otherwise.

See also: `nsm-check-tls-connection', `nsm-save-host-names',
`nsm-settings-file'"
  :version "27.1"
  :group 'nsm
  :type '(repeat (cons (function :tag "Check function")
                       (choice :tag "Level"
                               :value medium
                               (const :tag "Low" low)
                           (const :tag "Medium" medium)
                           (const :tag "High" high)))))

[1]: https://www.chromestatus.com/features/5903385005916160
[2]: https://tools.ietf.org/html/rfc7525

On Thu, Jul 5, 2018 at 4:52 PM, Perry E. Metzger <perry@piermont.com> wrote:
> On Mon, 25 Jun 2018 19:33:49 +0200 Lars Ingebrigtsen <larsi@gnus.org>
> wrote:
>> Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:
>>
>> > It's all about collisions[1], it's mostly a precaution, as no one
>> > has found an actual collistion for a cert yet, but Google has
>> > found collision for PDF last year [2].
>>
>> Ah, OK, then the SHA1 intermediate check isn't that vital.
>
> It is, actually. It's believed to be straightforward for national
> actors to forge intermediate certificates at this point.
>
>> (I think the PDF collision was a cheat, anyway, since they just
>> generated a lot of binary junk in a non-parsed section of the
>> PDF.  :-) )
>
> One of the rules in this game is attacks get better with time. Not
> that long after the first certificational attacks on MD5, it was
> discovered that parties unknown, generally thought to be nation-state
> actors, had been forging signatures on Microsoft software updates
> using MD5 collisions to enable what they were doing.
>
> I would make sure that SHA-1 defenses are in place.
>
> Perry
> --
> Perry E. Metzger                perry@piermont.com

Re: A couple of questions and concerns about Emacs network security

[Perry E. Metzger]

On Thu, 5 Jul 2018 16:58:26 +0100 Jimmy Yuen Ho Wong
<wyuenho@gmail.com> wrote:
> Ok I think I should let people know what my current plans are to
> avoid miscommunications:
> 
> 1. Certificate pinning - HTTP Public Key Pinning is currently used
> by some browsers, but it's problematic. Chrome will remove it in
> Chrome 69[1] and go full-on Certificate Transparency (CT).

CT is definitely the long term solution. If CT is in place there's no
need for pinning, which was a more interim measure.

> 2. NSM has its own kind of certificate pinning, which is basically
> reinventing `$gnutls-cli --tofu`. It has a couple of problems, such
> as not being able to store multiple fingerprints (Google load
> balance between 2 certs signed by 2 different public keys), I have
> fixed them in my branch. I'll publish it soon.
> 
> 3. There are a few security theatrics in NSM ATM, 'paranoid level is
> BS. If that level is justified, you can justify turning off your
> network card. I have removed it in my branch.

We are best off doing what the browser vendors are doing (Chrome,
Firefox, and Safari generally being good exemplars.)

> 4. Certificate pinning is only a very very very small part of the
> entire suite of measures needed to securely deploy TLS on the
> client. There are a whole host of cipher suite and TLS extension
> checks missing in NSM currently. The current set of best practices
> RFC is RFC 7525. I have implemented most of the recommendations
> minus those not applicable to GnuTLS and some big ones like OCSP
> and CT.

Good to hear. CT will be needed eventually. OpenSSL does implement
it, if GnuTLS does not, that's another strike against GnuTLS.

> 5. The way `gnutls-min-prime-bits` was handled in whatever that bug
> number was was never appropriate. 256-bit default was never a good
> idea. I have defaulted it to `nil` in my branch, which tells GnuTLS
> to use an appropriate bit length according to the priority string
> (generally > 1024). If this breaks anyone's config, they have one
> of 2 options - 1) manually set `gnutls-min-prime-bits` back to
> whatever you were using and keep putting yourself at risk, and/or
> 2) complaint to your server's admin.

256 was breakable in 1990. There are no circumstances where that's
acceptable. :(

> 6. GnuTLS is behind in some features such as CT, and enables a shit
> ton of ciphers by default that OpenSSL has disabled. It's so
> seldomly used and looked at by researchers that I bet it's full of
> holes. Paradoxically, this is also its advantage. It's so seldomly
> used, mostly OpenSSL specific attacks don't apply to it. I'm not too
> concerned about GnuTLS at the moment.

Not having CT is a problem. Certificate forgery in the field is
becoming a serious issue. Just a couple of days ago I was informed
that the WiFi on Turkish airliners now intercepts your TLS
traffic with the use of faked up certs. It's becoming so common in
various countries that we simply need it. If GnuTLS won't do it, then
we use something else that provides it.

> 7. Here's a preview of the latest set of checks in my fix-nsm-branch
> 
> 
> (defcustom nsm-tls-checks
>   '((nsm-tls-check-verify-cert            . low)
>     (nsm-tls-check-same-cert              . medium)
>     (nsm-tls-check-version                . medium)
>     (nsm-tls-check-compression            . medium)
>     (nsm-tls-check-renegotiation-info-ext . medium)
>     (nsm-tls-check-null-suite             . medium)
>     (nsm-tls-check-cbc-cipher             . high)
>     (nsm-tls-check-ecdsa-cbc-cipher       . medium)
>     (nsm-tls-check-3des-cipher            . medium)
>     (nsm-tls-check-rc4-cipher             . medium)
>     (nsm-tls-check-sha1-sig               . medium)
>     (nsm-tls-check-md5-sig                . medium)
>     (nsm-tls-check-rsa-kx                 . high)
>     (nsm-tls-check-dhe-prime-kx           . medium)
>     (nsm-tls-check-dhe-kx                 . high)
>     (nsm-tls-check-export-kx              . medium)
>     (nsm-tls-check-anon-kx                . medium))
>   "This variable specifies what TLS connection checks to perform.
> It's an alist where the key is the name of the check, and the
> value is the minimum security level the check should begin.
> 
> Each check function is called with the parameters HOST PORT
> STATUS SETTINGS.  HOST is the host domain, PORT is a TCP port
> number, STATUS is the peer status returned by
> `gnutls-peer-status', and SETTINGS is the persistent and session
> settings for the host HOST.  Please refer to the contents of
> `nsm-setting-file' for details.  If a problem is found, the check
> function is required to return an error message, and nil
> otherwise.
> 
> See also: `nsm-check-tls-connection', `nsm-save-host-names',
> `nsm-settings-file'"
>   :version "27.1"
>   :group 'nsm
>   :type '(repeat (cons (function :tag "Check function")
>                        (choice :tag "Level"
>                                :value medium
>                                (const :tag "Low" low)
>                            (const :tag "Medium" medium)
>                            (const :tag "High" high)))))
> 
> [1]: https://www.chromestatus.com/features/5903385005916160
> [2]: https://tools.ietf.org/html/rfc7525

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

>
> We are best off doing what the browser vendors are doing (Chrome,
> Firefox, and Safari generally being good exemplars.)
>

AFAIK, NSM is trying to do exactly that. Lars has set up a good structure here.

>
> Not having CT is a problem. Certificate forgery in the field is
> becoming a serious issue. Just a couple of days ago I was informed
> that the WiFi on Turkish airliners now intercepts your TLS
> traffic with the use of faked up certs. It's becoming so common in
> various countries that we simply need it. If GnuTLS won't do it, then
> we use something else that provides it.
>

There's a CT ticket[1] for GnuTLS. It's not coming any time soon tho,
so OCSP will have to do for now. Although, I'm pretty sure you can
extract the raw DER bytes and parse the SCT extension in
LISP using some bit manipulation magic (I don't even want to think
about it now.... feel free to pick it up).

[1]: https://gitlab.com/gnutls/gnutls/issues/232
[2]: https://www.gnutls.org/manual/gnutls.html#X_002e509-extensions

Re: A couple of questions and concerns about Emacs network security

[Perry E. Metzger]

On Thu, 5 Jul 2018 17:51:27 +0100 Jimmy Yuen Ho Wong
<wyuenho@gmail.com> wrote:
> > Not having CT is a problem. Certificate forgery in the field is
> > becoming a serious issue. Just a couple of days ago I was informed
> > that the WiFi on Turkish airliners now intercepts your TLS
> > traffic with the use of faked up certs. It's becoming so common in
> > various countries that we simply need it. If GnuTLS won't do it,
> > then we use something else that provides it.
> >  
> 
> There's a CT ticket[1] for GnuTLS. It's not coming any time soon
> tho, so OCSP will have to do for now.

So again, yet more reason to use something else.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> Date: Thu, 5 Jul 2018 16:58:26 +0100
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Eli Zaretskii <eliz@gnu.org>, Paul Eggert <eggert@cs.ucla.edu>, 
> 	Noam Postavsky <npostavs@gmail.com>, Emacs-Devel devel <emacs-devel@gnu.org>
> 
> Ok I think I should let people know what my current plans are to avoid
> miscommunications:

Please respond to my comments and questions in

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31946#89

I think we need to be in agreement about some principles before we
discuss further plans.

Thanks.

> 3. There are a few security theatrics in NSM ATM, 'paranoid level is
> BS. If that level is justified, you can justify turning off your
> network card. I have removed it in my branch.

That goes against one of my main comments in the above.  I don't think
I agree with having just one level of security in Emacs.  One more
reason to discuss my comments before going further ahead.

Re: A couple of questions and concerns about Emacs network security

[Noam Postavsky]

On 5 July 2018 at 11:52, Perry E. Metzger <perry@piermont.com> wrote:

> I would make sure that SHA-1 defenses are in place.

The SHA-1 defenses are in master, but there is some problem with them:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31946#95

So did you mean "I would make sure [but I won't for lack of
time/experience/etc]" or "I will make sure"?

Re: A couple of questions and concerns about Emacs network security

[Perry E. Metzger]

On Thu, 5 Jul 2018 14:43:50 -0400 Noam Postavsky <npostavs@gmail.com>
wrote:
> On 5 July 2018 at 11:52, Perry E. Metzger <perry@piermont.com>
> wrote:
> 
> > I would make sure that SHA-1 defenses are in place.  
> 
> The SHA-1 defenses are in master, but there is some problem with
> them: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31946#95
> 
> So did you mean "I would make sure [but I won't for lack of
> time/experience/etc]" or "I will make sure"?

I don't have time right now or I'd be helping. So the former.

-- 
Perry E. Metzger		perry@piermont.com

Re: A couple of questions and concerns about Emacs network security

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Allow me a few comments, with an eye towards getting at least some of
>> this to the emacs-26 branch:
>>
>>  . First, the NEWS entry should tell users how to get the previous
>>    (less secure) behavior if they want.  I think this also calls for a
>>    better documentation of the elements that can appear in
>>    network-security-protocol-checks.
>>
>>  . The change to gnutls-peer-status is not reflected in its doc string
>>    and is not called out in NEWS.
>
> Yes, true.  I'll do that later this week.

That was a ...  12 day week or something.  :-)

I've now pushed these doc fixes, and tried to explain better what these
checks do.  Hopefully it's not total gobbledegook -- trying to explain
TLS stuff without resorting to writing acronym soup (that only explains
things to people who already understands this stuff) isn't trivial.  :-)

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

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: wyuenho@gmail.com,  eggert@cs.ucla.edu,  npostavs@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 08 Jul 2018 13:43:10 +0200
> 
> >>  . First, the NEWS entry should tell users how to get the previous
> >>    (less secure) behavior if they want.  I think this also calls for a
> >>    better documentation of the elements that can appear in
> >>    network-security-protocol-checks.
> >>
> >>  . The change to gnutls-peer-status is not reflected in its doc string
> >>    and is not called out in NEWS.
> >
> > Yes, true.  I'll do that later this week.
> 
> That was a ...  12 day week or something.  :-)

Yeah, gimme 12-day weeks! with 50-hour days on top of that!

> I've now pushed these doc fixes, and tried to explain better what these
> checks do.  Hopefully it's not total gobbledegook -- trying to explain
> TLS stuff without resorting to writing acronym soup (that only explains
> things to people who already understands this stuff) isn't trivial.  :-)

It isn't gobbledegook for me, so I guess we are fine.

Thanks!

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

Ping!

> Date: Mon, 25 Jun 2018 19:06:51 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: wyuenho@gmail.com, eggert@cs.ucla.edu, npostavs@gmail.com,
> 	emacs-devel@gnu.org
> 
> Allow me a few comments, with an eye towards getting at least some of
> this to the emacs-26 branch:
> 
>  . First, the NEWS entry should tell users how to get the previous
>    (less secure) behavior if they want.  I think this also calls for a
>    better documentation of the elements that can appear in
>    network-security-protocol-checks.
> 
>  . The change to gnutls-peer-status is not reflected in its doc string
>    and is not called out in NEWS.
> 
>  . Do I understand correctly that most of the changes, including those
>    in gnutls.c, are so that intermediary certificates could be
>    verified?  If so, would it make sense to omit that for emacs-26,
>    and only beef up the medium level of security in NSM with the rest
>    of the checks?
> 
> 

Re: A couple of questions and concerns about Emacs network security

[Perry E. Metzger]

On Sat, 23 Jun 2018 09:40:56 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Noam Postavsky <npostavs@gmail.com>
> > Date: Fri, 22 Jun 2018 22:17:56 -0400
> > Cc: Lars Magne Ingebrigtsen <larsi@gnus.org>,
> > 	Jimmy Yuen Ho Wong <wyuenho@gmail.com>,
> > 	Emacs developers <emacs-devel@gnu.org>
> > 
> > On 22 June 2018 at 18:43, Paul Eggert <eggert@cs.ucla.edu>
> > wrote:  
> > > On 06/22/2018 03:00 PM, Jimmy Yuen Ho Wong wrote:  
> > >>
> > >> 1. Can we update the default network security settings?  
> > >
> > >
> > > Yes, I would think so, in the master branch. As you say, the
> > > current defaults are inappropriate for today's users.  
> > 
> > Can we bump gnutls-min-prime-bits to 1024 on the release branch?  
> 
> No, I don't think so.  Changing these settings needs a prolonged
> testing period to uncover any subtle problems with non-conforming
> servers that users must be able to access, and such testing is
> unlikely to happen on emacs-26 before the next bug-fix release.

All modern browsers set 1024 as a minimum. There is no need for Emacs
to worry about this as it has been years since you could connect to a
web site with less than 1024 bits security. It should be changed as
soon as possible. Even 1024 bits is too small, but this is at least
better than the current situation.

Generally speaking, if a security setting is the default in Chrome,
Firefox, Safari, and Edge, you can feel reasonably certain that it is
safe to have Emacs turn on such a setting as well without fear that
it will cause inconvenience to the user community.

> If we change this now on emacs-26, we should probably not release
> Emacs 26.2 before a year goes by.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> Date: Thu, 5 Jul 2018 11:33:20 -0400
> From: "Perry E. Metzger" <perry@piermont.com>
> Cc: Noam Postavsky <npostavs@gmail.com>, larsi@gnus.org, eggert@cs.ucla.edu,
>  wyuenho@gmail.com, emacs-devel@gnu.org
> 
> > > Can we bump gnutls-min-prime-bits to 1024 on the release branch?  
> > 
> > No, I don't think so.  Changing these settings needs a prolonged
> > testing period to uncover any subtle problems with non-conforming
> > servers that users must be able to access, and such testing is
> > unlikely to happen on emacs-26 before the next bug-fix release.
> 
> All modern browsers set 1024 as a minimum. There is no need for Emacs
> to worry about this as it has been years since you could connect to a
> web site with less than 1024 bits security. It should be changed as
> soon as possible. Even 1024 bits is too small, but this is at least
> better than the current situation.

Emacs is not a Web browser, it uses the network for purposes other
than browsing Web pages, so what browsers do is less relevant than
what you seem to imply.

Anyway, it seems you completely miss my point: I didn't say that we
shouldn't increase the number of bits, just that we shouldn't do that
on the release branch, unless we are willing to delay Emacs 26.2
significantly.

Re: A couple of questions and concerns about Emacs network security

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Thu, 5 Jul 2018 11:33:20 -0400
>> From: "Perry E. Metzger" <perry@piermont.com>
>> Cc: Noam Postavsky <npostavs@gmail.com>, larsi@gnus.org, eggert@cs.ucla.edu,
>>  wyuenho@gmail.com, emacs-devel@gnu.org
>> 
>> > > Can we bump gnutls-min-prime-bits to 1024 on the release branch?  
>> > 
>> > No, I don't think so.  Changing these settings needs a prolonged
>> > testing period to uncover any subtle problems with non-conforming
>> > servers that users must be able to access, and such testing is
>> > unlikely to happen on emacs-26 before the next bug-fix release.
>> 
>> All modern browsers set 1024 as a minimum. There is no need for Emacs
>> to worry about this as it has been years since you could connect to a
>> web site with less than 1024 bits security. It should be changed as
>> soon as possible. Even 1024 bits is too small, but this is at least
>> better than the current situation.
>
> Emacs is not a Web browser, it uses the network for purposes other
> than browsing Web pages, so what browsers do is less relevant than
> what you seem to imply.
>
> Anyway, it seems you completely miss my point: I didn't say that we
> shouldn't increase the number of bits, just that we shouldn't do that
> on the release branch, unless we are willing to delay Emacs 26.2
> significantly.

FWIW, Iʼve had gnutls-min-prime-bits set to 1024 since 2014-11-25, and
have seen no adverse effects from it, so I donʼt think the risk is
that great.

Regarsd

Robert

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: "Perry E. Metzger" <perry@piermont.com>,  larsi@gnus.org,  eggert@cs.ucla.edu,  emacs-devel@gnu.org,  npostavs@gmail.com,  wyuenho@gmail.com
> Date: Fri, 06 Jul 2018 10:36:54 +0200
> 
> > Anyway, it seems you completely miss my point: I didn't say that we
> > shouldn't increase the number of bits, just that we shouldn't do that
> > on the release branch, unless we are willing to delay Emacs 26.2
> > significantly.
> 
> FWIW, Iʼve had gnutls-min-prime-bits set to 1024 since 2014-11-25, and
> have seen no adverse effects from it, so I donʼt think the risk is
> that great.

Thanks for the data point.

Unfortunately, our experience is that use patterns vary widely between
different Emacs users, and so problem-free experience of a single
individual, or even several people, is not enough to be sure there are
no significant issues.  And TLS secured connections are central to
many Emacs features.

Emacs 26.2 is supposed to have fewer significant bugs than Emacs 26.1,
so we must be careful if we make changes that could bring new
problems.

Re: A couple of questions and concerns about Emacs network security

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: "Perry E. Metzger" <perry@piermont.com>,  larsi@gnus.org,  eggert@cs.ucla.edu,  emacs-devel@gnu.org,  npostavs@gmail.com,  wyuenho@gmail.com
>> Date: Fri, 06 Jul 2018 10:36:54 +0200
>> 
>> > Anyway, it seems you completely miss my point: I didn't say that we
>> > shouldn't increase the number of bits, just that we shouldn't do that
>> > on the release branch, unless we are willing to delay Emacs 26.2
>> > significantly.
>> 
>> FWIW, Iʼve had gnutls-min-prime-bits set to 1024 since 2014-11-25, and
>> have seen no adverse effects from it, so I donʼt think the risk is
>> that great.
>
> Thanks for the data point.
>
> Unfortunately, our experience is that use patterns vary widely between
> different Emacs users, and so problem-free experience of a single
> individual, or even several people, is not enough to be sure there are
> no significant issues.  And TLS secured connections are central to
> many Emacs features.

TLS is central to many of life's interactions now, unfortunately.

> Emacs 26.2 is supposed to have fewer significant bugs than Emacs 26.1,
> so we must be careful if we make changes that could bring new
> problems.

Yes. Would you be willing to try changing it on master?

Robert

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 06 Jul 2018 11:35:54 +0200
> 
> > Emacs 26.2 is supposed to have fewer significant bugs than Emacs 26.1,
> > so we must be careful if we make changes that could bring new
> > problems.
> 
> Yes. Would you be willing to try changing it on master?

No objections to that, of course.  But I think we already did that on
master, didn't we?  (I might be confused due to the sheer number of
submitted patches, some of which were not yet pushed.)

Re: A couple of questions and concerns about Emacs network security

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: emacs-devel@gnu.org
>> Date: Fri, 06 Jul 2018 11:35:54 +0200
>> 
>> > Emacs 26.2 is supposed to have fewer significant bugs than Emacs 26.1,
>> > so we must be careful if we make changes that could bring new
>> > problems.
>> 
>> Yes. Would you be willing to try changing it on master?
>
> No objections to that, of course.  But I think we already did that on
> master, didn't we?  (I might be confused due to the sheer number of
> submitted patches, some of which were not yet pushed.)

I donʼt think any of them have been pushed yet. Certainly the major
changes to nsm.el by Jimmy haven't.

Robert

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Fri, 06 Jul 2018 14:52:13 +0200
> Cc: emacs-devel@gnu.org
> 
> >> Yes. Would you be willing to try changing it on master?
> >
> > No objections to that, of course.  But I think we already did that on
> > master, didn't we?  (I might be confused due to the sheer number of
> > submitted patches, some of which were not yet pushed.)
> 
> I donʼt think any of them have been pushed yet. Certainly the major
> changes to nsm.el by Jimmy haven't.

I thought Lars did it, but I could have been easily confused.

Re: A couple of questions and concerns about Emacs network security

[Stephen Berman]

On Fri, 06 Jul 2018 11:49:45 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: "Perry E. Metzger" <perry@piermont.com>, larsi@gnus.org,
>> eggert@cs.ucla.edu, emacs-devel@gnu.org, npostavs@gmail.com,
>> wyuenho@gmail.com
>> Date: Fri, 06 Jul 2018 10:36:54 +0200
>> 
>> > Anyway, it seems you completely miss my point: I didn't say that we
>> > shouldn't increase the number of bits, just that we shouldn't do that
>> > on the release branch, unless we are willing to delay Emacs 26.2
>> > significantly.
>> 
>> FWIW, Iʼve had gnutls-min-prime-bits set to 1024 since 2014-11-25, and
>> have seen no adverse effects from it, so I donʼt think the risk is
>> that great.
>
> Thanks for the data point.
>
> Unfortunately, our experience is that use patterns vary widely between
> different Emacs users, and so problem-free experience of a single
> individual, or even several people, is not enough to be sure there are
> no significant issues.  And TLS secured connections are central to
> many Emacs features.
>
> Emacs 26.2 is supposed to have fewer significant bugs than Emacs 26.1,
> so we must be careful if we make changes that could bring new
> problems.

I think in this case it is likely that the higher setting has in effect
already undergone prolongued testing, since there is reason to think it
has been used by many, perhaps most, Emacs users for a long time, in my
case since reading this posting:

  From: "Herbert J. Skuhra" <hskuhra@eumx.net>
  Subject: Re: gnutls.c warning
  Newsgroups: gmane.emacs.gnus.general
  To: david@adboyd.com (J. David Boyd)
  Cc: ding@gnus.org
  Date: Tue, 25 Jun 2013 23:38:14 +0200 (5 years, 1 week, 3 days ago)
  
  On Tue, 25 Jun 2013 15:07:08 -0400
  david@adboyd.com (J. David Boyd) wrote:
  
  > 
  > I keep getting this warning, and can't find any way to turn it off.
  > 
  > gnutls.c: [1] Note that the security level of the Diffie-Hellman key
  > exchange has been lowered to 256 bits and this may allow decryption
  > of the session data
  >  
  > Is there some setting to say ok, I understand, quit nagging me?
  
  After setting gnutls-min-prime-bits to 1024 I no longer get this
  warning.

Given this, it seems reasonable to conclude that most Emacs users who
continue to use the current default setting are aware of the risk, and
those who have changed it haven't experienced a problem worth reporting.
Therefore, changing the default at this time is not likely to cause a
problem for most long-time users, and will be safer for all new users,
and most likely unproblematic for them (and if it is a problem, then
they will know the trade-off).

Steve Berman

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: Robert Pluim <rpluim@gmail.com>,  emacs-devel@gnu.org
> Date: Fri, 06 Jul 2018 11:45:17 +0200
> 
>   After setting gnutls-min-prime-bits to 1024 I no longer get this
>   warning.
> 
> Given this, it seems reasonable to conclude that most Emacs users who
> continue to use the current default setting are aware of the risk, and
> those who have changed it haven't experienced a problem worth reporting.
> Therefore, changing the default at this time is not likely to cause a
> problem for most long-time users, and will be safer for all new users,
> and most likely unproblematic for them (and if it is a problem, then
> they will know the trade-off).

Thanks, but I don't see how can we deduce "most" from any such
reports.  And the users who have made such a setting don't need the
defaults to change anyway.

Not that "most" counts here, anyway: the whole point of prolonged
testing of modified defaults is to uncover those rare use cases where
the new values do some harm, and see whether we need to augment the
new settings with something.  I see no way around that, sorry, not
when a feature as basic as network connections is concerned.

Re: A couple of questions and concerns about Emacs network security

[Stephen Berman]

On Fri, 06 Jul 2018 15:41:30 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: Robert Pluim <rpluim@gmail.com>,  emacs-devel@gnu.org
>> Date: Fri, 06 Jul 2018 11:45:17 +0200
>> 
>>   After setting gnutls-min-prime-bits to 1024 I no longer get this
>>   warning.
>> 
>> Given this, it seems reasonable to conclude that most Emacs users who
>> continue to use the current default setting are aware of the risk, and
>> those who have changed it haven't experienced a problem worth reporting.
>> Therefore, changing the default at this time is not likely to cause a
>> problem for most long-time users, and will be safer for all new users,
>> and most likely unproblematic for them (and if it is a problem, then
>> they will know the trade-off).
>
> Thanks, but I don't see how can we deduce "most" from any such
> reports.  

Strictly speaking, of course not.  But since Emacs has emitted the
Gnutls warning for at least five years, it doesn't seem too far-fetched
that "most" Emacs users (i.e., enough to cover all but the rarest of
corner cases) have been exposed to it and acted on it or at least know
the risk.

>           And the users who have made such a setting don't need the
> defaults to change anyway.

No, but it's the new users who would benefit.

> Not that "most" counts here, anyway: the whole point of prolonged
> testing of modified defaults is to uncover those rare use cases where
> the new values do some harm, and see whether we need to augment the
> new settings with something.  I see no way around that, sorry, not
> when a feature as basic as network connections is concerned.

My point was that the higher setting has in effect been tested for at
least five years by many (if not "most") users, in response to the
warning, and there have been no bug reports about it AFAIK.  Are you
expecting and planning more systematic testing beyond changing the
default and waiting for bug reports?

Steve Berman

Re: A couple of questions and concerns about Emacs network security

[martin rudalics]

 >>            And the users who have made such a setting don't need the
 >> defaults to change anyway.
 >
 > No, but it's the new users who would benefit.

Shouldn't new users face such changes with major releases only?

martin

Re: A couple of questions and concerns about Emacs network security

[Stephen Berman]

On Sat, 07 Jul 2018 09:15:32 +0200 martin rudalics <rudalics@gmx.at> wrote:

>>>            And the users who have made such a setting don't need the
>>> defaults to change anyway.
>>
>> No, but it's the new users who would benefit.
>
> Shouldn't new users face such changes with major releases only?

Since this is a security-related change, it depends on the maintainers'
judgment of the risks (both of making the change and of not making it).

Steve Berman

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  rpluim@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 07 Jul 2018 14:22:54 +0200
> 
> On Sat, 07 Jul 2018 09:15:32 +0200 martin rudalics <rudalics@gmx.at> wrote:
> 
> >>>            And the users who have made such a setting don't need the
> >>> defaults to change anyway.
> >>
> >> No, but it's the new users who would benefit.
> >
> > Shouldn't new users face such changes with major releases only?
> 
> Since this is a security-related change, it depends on the maintainers'
> judgment of the risks (both of making the change and of not making it).

When making these judgment calls, are we allowed to apply the same
principle as you did, namely that the current situation "has been
tested for at least five years", and therefore we can conclude that no
urgent change is needed?

Re: A couple of questions and concerns about Emacs network security

[Stephen Berman]

On Sat, 07 Jul 2018 16:22:15 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  rpluim@gmail.com,  emacs-devel@gnu.org
>> Date: Sat, 07 Jul 2018 14:22:54 +0200
>> 
>> On Sat, 07 Jul 2018 09:15:32 +0200 martin rudalics <rudalics@gmx.at> wrote:
>> 
>> >>>            And the users who have made such a setting don't need the
>> >>> defaults to change anyway.
>> >>
>> >> No, but it's the new users who would benefit.
>> >
>> > Shouldn't new users face such changes with major releases only?
>> 
>> Since this is a security-related change, it depends on the maintainers'
>> judgment of the risks (both of making the change and of not making it).
>
> When making these judgment calls, are we allowed to apply the same
> principle as you did, namely that the current situation "has been
> tested for at least five years", and therefore we can conclude that no
> urgent change is needed?

If I were in a position to allow or forbid you anything, I would
certainly allow you that.

Steve Berman

Re: A couple of questions and concerns about Emacs network security

[martin rudalics]

 >> Shouldn't new users face such changes with major releases only?
 >
 > Since this is a security-related change, it depends on the maintainers'
 > judgment of the risks (both of making the change and of not making it).

If a security-related change is about fixing an imminent risk, we
should apply it in the next release or even make a special release for
it.  If a security-related change is about setting and presenting a
security measure to users, it should be given as much prior testing as
possible.  Otherwise, we risk that too many new users get annoyed by
improper security settings and switch them off.  Which is probably not
what we wanted in the first place.

martin

Re: A couple of questions and concerns about Emacs network security

[Perry E. Metzger]

On Fri, 22 Jun 2018 22:17:56 -0400 Noam Postavsky
<npostavs@gmail.com> wrote:
> Can we bump gnutls-min-prime-bits to 1024 on the release branch? I
> know it has a reference to Bug#11267 which describes some mail
> server that works only with 256 bits primes, but surely people
> using such software can set the option themselves. I mean, a 256
> bit DH prime is just a toy example, not real crypto. It's
> inappropriate for yesterday's users. Even 1024 is probably a bit
> low, but at least it's something.

That's too low, but it is the minimum in all modern browsers.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Fri, 22 Jun 2018 15:43:35 -0700
> Cc: Lars Magne Ingebrigtsen <larsi@gnus.org>
> 
> > 2. Now that `starttls.el` and `tls.el` are obsolete, and GnuTLS doesn't
> >     seem to be doing a very good job, can we link to something better
> >     maintained, such as OpenSSL/LibreSSL/BoringSSL/NSS?
> 
> I would think the answer to that could be "yes" too. Despite its name, 
> GnuTLS is no longer GNU code, and we're under no obligation to promote 
> it. However, this would take some work. We'd surely want the option to 
> link to either GnuTLS or OpenSSL/etc.

GnuTLS may not be a GNU project in the formal sense, but nothing has
changed in its development methods or in its spirit since it was.
OpenSSL is even less of a GNU project, and AFAIR includes components
that are not even Free Software.  Moreover, having 2 different
libraries for the same task in Emacs will be a maintenance burden we
are better without, especially given the lack of active experts on
board.  I'd like to remind us all that we've just switched to GnuTLS
as the primary means in Emacs 26.1.

So my vote would be NO for switching away from GnuTLS.

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

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

On Sat, Jun 23, 2018 at 7:45 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Paul Eggert <eggert@cs.ucla.edu>
> > Date: Fri, 22 Jun 2018 15:43:35 -0700
> > Cc: Lars Magne Ingebrigtsen <larsi@gnus.org>
> >
> > > 2. Now that `starttls.el` and `tls.el` are obsolete, and GnuTLS doesn't
> > >     seem to be doing a very good job, can we link to something better
> > >     maintained, such as OpenSSL/LibreSSL/BoringSSL/NSS?
> >
> > I would think the answer to that could be "yes" too. Despite its name,
> > GnuTLS is no longer GNU code, and we're under no obligation to promote
> > it. However, this would take some work. We'd surely want the option to
> > link to either GnuTLS or OpenSSL/etc.
>
> GnuTLS may not be a GNU project in the formal sense, but nothing has
> changed in its development methods or in its spirit since it was.
> OpenSSL is even less of a GNU project, and AFAIR includes components
> that are not even Free Software.  Moreover, having 2 different
> libraries for the same task in Emacs will be a maintenance burden we
> are better without, especially given the lack of active experts on
> board.  I'd like to remind us all that we've just switched to GnuTLS
> as the primary means in Emacs 26.1.
>
> So my vote would be NO for switching away from GnuTLS.
>

While I understand this from a human resource perspective, I wonder if it's
possible for the FSF to ask for some friendly help (such as the folks at
EFF) on this one. I can probably ask around in London as well. In my
opinion having OTTB better security is worthwhile for the switch.

As to OpenSSL, they seem to have found all the past contributors already (
https://license.openssl.org/trying-to-find). It seems they are really close
to switching to the Apache license.

[-- Attachment #2: Type: text/html, Size: 2743 bytes --]

Re: A couple of questions and concerns about Emacs network security

[Perry E. Metzger]

On Sat, 23 Jun 2018 09:45:57 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Paul Eggert <eggert@cs.ucla.edu>
> > Date: Fri, 22 Jun 2018 15:43:35 -0700
> > Cc: Lars Magne Ingebrigtsen <larsi@gnus.org>
> >   
> > > 2. Now that `starttls.el` and `tls.el` are obsolete, and GnuTLS
> > > doesn't seem to be doing a very good job, can we link to
> > > something better maintained, such as
> > > OpenSSL/LibreSSL/BoringSSL/NSS?  
> > 
> > I would think the answer to that could be "yes" too. Despite its
> > name, GnuTLS is no longer GNU code, and we're under no obligation
> > to promote it. However, this would take some work. We'd surely
> > want the option to link to either GnuTLS or OpenSSL/etc.  
> 
> GnuTLS may not be a GNU project in the formal sense, but nothing has
> changed in its development methods or in its spirit since it was.
> OpenSSL is even less of a GNU project, and AFAIR includes components
> that are not even Free Software.

So far as I can tell and am aware, OpenSSL is fully free software.
There are no unfree components.

> Moreover, having 2 different
> libraries for the same task in Emacs will be a maintenance burden we
> are better without,

The security of OpenSSL is, so far as I can tell, more reliably
managed. There's a large team that worries about it, and the security
of cryptographic libraries is a difficult problem. Everything from
timing attacks to very subtle mistakes in nonce generation has to go
perfectly.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: A couple of questions and concerns about Emacs network security

[Paul Eggert]

Perry E. Metzger wrote:
> The security of OpenSSL is, so far as I can tell, more reliably
> managed.

Yes, OpenSSL is surely the best choice for current applications, despite its 
obvious drawbacks. That being said, Emacs shouldn't be tied down to OpenSSL, 
just as it should not be tied down to GnuTLS. There is currently quite a bit of 
interest in replacing OpenSSL with something better, and with luck we'll see 
improvements in the not-too-distant future. We insulate Emacs users from this 
turmoil as best we can.

Here's a useful paper for those of us not plugged into recent work in the area:

Halpin H. A roadmap for high assurance cryptography. FPS 2017. 
https://hal.inria.fr/hal-01673294

Re: A couple of questions and concerns about Emacs network security

[Perry E. Metzger]

On Thu, 5 Jul 2018 12:20:54 -0700 Paul Eggert <eggert@cs.ucla.edu>
wrote:
> Perry E. Metzger wrote:
> > The security of OpenSSL is, so far as I can tell, more reliably
> > managed.  
> 
> Yes, OpenSSL is surely the best choice for current applications,
> despite its obvious drawbacks. That being said, Emacs shouldn't be
> tied down to OpenSSL, just as it should not be tied down to GnuTLS.
> There is currently quite a bit of interest in replacing OpenSSL
> with something better, and with luck we'll see improvements in the
> not-too-distant future. We insulate Emacs users from this turmoil
> as best we can.

This seems completely reasonable. That said, for now, I think the best
possible default should be what we recommend until some better
possible default exists.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: A couple of questions and concerns about Emacs network security

[Richard Stallman]

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

  > So far as I can tell and am aware, OpenSSL is fully free software.
  > There are no unfree components.

OpenSSL had, in the past, a license incompatible with the GNU GPL.
If its license is unchanged, using it with Emacs would require some
inconvenient work to install a license exception.

That is assuming there is no non-FSF-copyrighted GPL-covered code
linked into Emacs.  If there is some, that is not inconvenient but
impossible.


-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

Whoa that's a lot of emails in one day! I understand that some of you
are concerned, I am too, that's why I raised this issue. Now, given
the volume, I don't want to respond individually, so please allow me
to summarize and address all of your concerns here.

First of all, having read all of your comments, I don't think anybody
is deliberately undermining Emacs' networks security. Emacs's network
security is the way it is mostly because of a lack of knowledge and
personnel. I don't think any of us is trying to hide that, and I think
we all want it to be better. Therefore, instead of arguing the issue
on moral ground, I propose we look at our common grounds and see what
we've already agreed on.

Before I dive deeper, here's a diff of my branch against master:

https://github.com/emacs-mirror/emacs/compare/master...wyuenho:additional-nsm-checks

I'll refer to this in the rest of this long email.


You can have both freedom and security
-----------------------------------------------------
A lot of us take Emacs' infinitely malleability as granted, so we
don't even mention it, but that doesn't mean we don't care about
freedom or are trying to be paternalistic. In my branch, I have kept
the current NSM's structure - coarse grain security settings by
setting `network-security-level`, and find grain security by setting
`nsm-tls-checks`. This not only satisfies Eli's concern of providing
reasonable settings while preserving the freedom of users to decide
what's best for them, but also solves a more pertinent problem - the
necessity to adjust individual network security checks quickly in case
of a new kind of TLS attack outside of Emacs' release cycle. We can
either change Emacs's release process or keep NSM malleable, the
latter seems a quicker way out of this mess, and one which we can all
agree on.


Most of the checks are on `medium` level because of **secure by default**
---------------------------------------------------------------------------------------------------
**Secure by default** is a mantra used by InfoSec professionals, in
Emacs' lingo it means reasonable default settings. The reason 13 out
of 17 checks in my branch are on `medium` level is *not* because I'm
trying to mold NSM to such a way that its **security levels** are
indistinguishable with **secury level**, but because most of those
checks are RFC 7525's recommendation's for securely using TLS on the
client. RFC 7525 is listed as BEST CURRENT PRACTICE by IETF in 2015. I
have added a couple more checks to `medium` because things have
evolved since 2015. The details for their inclusion are in the
docstrings.

As to `high`, those 3 checks ideally should be included in `medium`
but can't for fear of being too naggy due to compatibility reasons.
RSA key exchange is still widely deployed, so is DHE due to it being
the only fallback for TLS 1.3. CBC mode is also widely a deployed
fallback cipher. All of the above are known to be insecure a lot of
times, but for me, **secure by default** means as secure *AND*
practical as possible by default, so until RSA KX, DHE KX and CBC
ciphers go away completely from the servers, I believe putting them on
the `high` level is appropriate.


More checks does not mean more inconvenience
-----------------------------------------------------------------
NSM will only prompt you when a check fails *AND* these failed checks
for a host have not been saved as exceptions. If you answer "session
only" after the prompt, NSM will not prompt you again until you
restart Emacs. If you answer "always", NSM will not prompt you again
for those failed checks for that host as long as the exceptions are
still saved on file. The ability of having a "chance to choose between
the alternatives (convenience and safety) early enough that they won't
beunsafe.  The choice should come with an explanation of each option,
first stating what situations it is recommended for, then what it
does." is already implemented in master.

Having said that, NSM currenly may prompt you many times if there is
more than one security check failures, i.e. if your level is set to
`high` and the server such as Google's is load balancing TLS
connections with 2 or more certs with different fingerprints, and it's
using SHA1 signatures, you will get 3 prompts. I have streamlined all
of those in my branch so you only get prompted once for all the
problems found. That's **more** convenience and "more" safety. You can
have your cake and eat it too.


Less knobs can also mean more convenience and security
------------------------------------------------------------------------------
The `paranoid` level is security theatre. All it does is ask if you'd
like to connect to a server via TLS if you have never reached it
before. Why is attempting to securely connect to a server by using a
protocol that will authenticate it a cause for concern? Connecting to
a server via TLS does not mean the user start transmitting
confidential data immediately. That act  comes when you sign up or log
in. That's not TLS's job.

For STARTTLS, if the server does not support TLS, you will have gotten
a prompt for using a plain connection already, so why the extra
prompt? Does it not give the user a false sense of more security? Will
it mislead some innocent user to belive every host can be trusted
under `high` level? If the answer to the last 2 questions were yes, I
believe removing `paranoid` and its check is the right thing to do,
even if only for the sake of giving the right expectation.


Emacs is not (only) a browser, but that's a moot point
-----------------------------------------------------------------------
Emacs' use base is diverse. People not only browse the Web with it,
but read and reply to emails, browse newgroups, chat on
IRC/Jabber/Slack, push code to Github etc., all of which require the
network to be secured with TLS. While TLS is mostly used on the Web
because of HTTPS, SSL/TLS has been mandatory for Gmail for many years
now, Github also requires TLS for code push, and so do many chat
servers. The way Emacs has deployed TLS either has a fault or it
doesn't, it doesn't matter which protocol TLS is wrapping over.

While I agree that blindly copying the security settings of the most
widely deployed TLS clients that we call browsers may not necessarily
be a good idea, it's also not a bad idea given Google and Mozilla's
army of InfoSec people looking after them. In addition, I haven't
copied them blindly. I have researched every single one of them by
reading about a dozen RFCs and papers in the past few weeks, and only
include them when applicable to Emacs' use of GnuTLS. See the
docstrings for details.


`gnutls-min-prime-bits` should be `nil` on Emacs 26.2
-----------------------------------------------------------------------
Setting `gnutls-min-prime-bits` to `nil` lets GnuTLS negotiate the
highest possible bit length based on its priority string, which means
at least 1008-bit since 3.3.0.

If my and other's positions on this issue have not been clear, let me
reiterate this - it was *never* appripriate to default
`gnutls-min-prime-bits` to 256. The list of reasons are the following:

1. If a user's email server demands 256 bits, it's not a sufficient
reason to sacriface the **secury by default** goal for the vast
majority of users by defaulting it to 256 just so everyone is on the
lowest common denominator possible.

2. US export regulation controls export of crypto components using DH
> 512 bit prime length to rogue states[2], that means NSA can break DH
with prime bits < 512, that also means possibly other state actors as
well. 256-bit default means **enabling mass-surveillance** for our
users world-wide.

3. If you are afraid of upping to > 1024 will interrupt many people's
workflow, don't. SSLLabs's Key Exchange Strength scan[3] shows there's
only 2.9% servers found using < 512 bit key exchange. 1024+2048+3076
bit servers cover ~ 95% of TLS server deployments out there. It makes
no sense to sacriface 95% for 2.9%. See 1).

4. Even if it regressed for some poor guy's connection to an email
server configured in the 80s, that's a **good** thing. If he ever
comes back to complaint about it, we can direct him to complaint to
the server admin instead, so we can all be safer. See 1) again.

5. Even if he turns out to have legitimate reasons to set prime bits
to 256 bits, it's not Emacs' problem. He just has to M-x
customize-set-value RET gnutls-min-prime-bits RET 256 RET.

There is absolutely no reason whatsoever to default
`gnutls-min-prime-bits` to 256, not even in the 90s.

[1]: https://ee.stanford.edu/~hellman/publications/28.pdf
[2]: https://www.bis.doc.gov/index.php/forms-documents/encryption/335-supplement-no-1-to-part-774-category-5-part-ii-information-security/file
[3]: https://www.ssllabs.com/ssl-pulse/


OpenSSL is nice, but getting much improved network security out the
door ASAP is nicer
----------------------------------------------------------------------------------------------------------------------
While OpenSSL certainly has its advantages, it is also a much bigger
target. When dealing with security issues, one has to consider the
economics. When economics are factored, an attacker will often ask if
it make sense to spend a month working on an attack to target a small
user base such as GnuTLS'. The answer to that is likely to be false.
But if we are on OpenSSL, any new attack targeted towards it will make
Emacs a target as well.

In addition, these days I try to live by a motto - Don't let the
perfect be the enemy of the good. Replacing GnuTLS with OpenSSL is
significantly harder than writing a couple C functions to get the most
out of GnuTLS. Replacing it without major regressions even harder.
Besides, most of Emacs' network security problems do not come from it
use of GnuTLS, but deficiencies in NSM. I believe Emacs' network
security can get much better faster if we focus our efforts on the
current design.


Documenting security changes
-----------------------------------------
Currently, Emacs' network security settings are poorly documented and
widely misunderstood. There's only one page on the entire Emacs manual
that briefly describes the checks NSM has, but it doesn't mention what
its relation is with GnuTLS. There is also no mention of NSM or GnuTLS
in the Emacs Lisp Reference whatsoever. I aim to improve it, but given
the amount of work involved to bring Emacs' network security up to
date, I'd rather submit another patch when the dust has settled.
(*cough* feature creep *cough*)


Jimmy


On Thu, Jul 5, 2018 at 11:44 PM, Richard Stallman <rms@gnu.org> wrote:
> [[[ 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. ]]]
>
> I don't know what this issue concretely involves, so I don't have
> an opinion about what concretely we should do.  But I'd like to suggest
> a possible avenue for choosing a good response.
>
> The idea is that we make sure users see a chance to choose between the
> alternatives (convenience and safety) early enough that they won't be
> unsafe.  The choice should come with an explanation of each option,
> first stating what situations it is recommended for, then what it does.
>
>
>
> --
> Dr Richard Stallman
> President, Free Software Foundation (https://gnu.org, https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)
>
>

On Thu, Jul 5, 2018 at 11:44 PM, Richard Stallman <rms@gnu.org> wrote:
> [[[ 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. ]]]
>
>   > So far as I can tell and am aware, OpenSSL is fully free software.
>   > There are no unfree components.
>
> OpenSSL had, in the past, a license incompatible with the GNU GPL.
> If its license is unchanged, using it with Emacs would require some
> inconvenient work to install a license exception.
>
> That is assuming there is no non-FSF-copyrighted GPL-covered code
> linked into Emacs.  If there is some, that is not inconvenient but
> impossible.
>
>
> --
> Dr Richard Stallman
> President, Free Software Foundation (https://gnu.org, https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)
>
>

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> Date: Fri, 6 Jul 2018 07:42:22 +0100
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Paul Eggert <eggert@cs.ucla.edu>,
> 	Emacs-Devel devel <emacs-devel@gnu.org>,
> 	"Perry E. Metzger" <perry@piermont.com>
> 
> Whoa that's a lot of emails in one day! I understand that some of you
> are concerned, I am too, that's why I raised this issue. Now, given
> the volume, I don't want to respond individually, so please allow me
> to summarize and address all of your concerns here.

Thanks.

> instead of arguing the issue on moral ground, I propose we look at
> our common grounds and see what we've already agreed on.

Agreed.  I only responded "on moral grounds" because my views were
challenged on those grounds.

> Most of the checks are on `medium` level because of **secure by default**
> ---------------------------------------------------------------------------------------------------
> **Secure by default** is a mantra used by InfoSec professionals, in
> Emacs' lingo it means reasonable default settings. The reason 13 out
> of 17 checks in my branch are on `medium` level is *not* because I'm
> trying to mold NSM to such a way that its **security levels** are
> indistinguishable with **secury level**, but because most of those
> checks are RFC 7525's recommendation's for securely using TLS on the
> client. RFC 7525 is listed as BEST CURRENT PRACTICE by IETF in 2015. I
> have added a couple more checks to `medium` because things have
> evolved since 2015. The details for their inclusion are in the
> docstrings.
> 
> As to `high`, those 3 checks ideally should be included in `medium`

I'm still questioning how can this be TRT.  Please remember that
'medium' in Emacs really means 'minimum', because 'low' has no
security checks at all.  How can it make sense to have _all_ the
checks on the _minimum_ level?  (I say "all" because you clearly think
'high' and 'paranoid' should be removed, and their checks, those which
make sense, moved into 'medium'.)

Suppose I work in Emacs on an internal secure network that is
physically disconnected from the Internet (many enterprises, including
my daytime job, have such stand-alone networks as a matter of
routine).  Why would I need all the checks you propose on such a
network?  OTOH, I don't want to go to 'low' (i.e. 'none') on such
networks, because who knows what viri and other calamities can be once
in a blue moon present on some of the machines on that network.

Same questions regarding a home network, separated from the outside
world by a firewall.

Why shouldn't Emacs cater to such use cases?

On the other end, there are legitimate use cases where users might
need to access sites and servers known in advance to be dangerous.
Why shouldn't Emacs provide a 'paranoid' set of settings for such use
cases?

The RFCs you cite and the vulnerabilities they describe should IMO be
carefully analyzed, in the context of typical Emacs jobs that require
network connections, and then we should grade them by their
importance, divide them into 3 or 4 meaningful classes (a.k.a.
"levels"), and let users change their settings in meaningful ways by
changing the level.  Fine-grained settings should IMO also be
provided, but they cannot be the only solution that we offer our
users, precisely because not everyone has time to study each
individual feature, but they normally will have time to read a
description of 3 to 4 levels and decide which one is for them,
especially if we describe them in terms that are related to the
general environment rather than to specific vulnerabilities, similar
to how many laptops ask you to select whether the new connection is
for "home network", "enterprise", or "public network" -- that's
something that every user can normally answer.

> More checks does not mean more inconvenience
> -----------------------------------------------------------------
> NSM will only prompt you when a check fails *AND* these failed checks
> for a host have not been saved as exceptions. If you answer "session
> only" after the prompt, NSM will not prompt you again until you
> restart Emacs. If you answer "always", NSM will not prompt you again
> for those failed checks for that host as long as the exceptions are
> still saved on file. The ability of having a "chance to choose between
> the alternatives (convenience and safety) early enough that they won't
> beunsafe.  The choice should come with an explanation of each option,
> first stating what situations it is recommended for, then what it
> does." is already implemented in master.
> 
> Having said that, NSM currenly may prompt you many times if there is
> more than one security check failures, i.e. if your level is set to
> `high` and the server such as Google's is load balancing TLS
> connections with 2 or more certs with different fingerprints, and it's
> using SHA1 signatures, you will get 3 prompts. I have streamlined all
> of those in my branch so you only get prompted once for all the
> problems found. That's **more** convenience and "more" safety. You can
> have your cake and eat it too.

These improvements are good (provided that they indeed work in
practice -- I will have to try them), but IMO they are not enough.
You assume each one of us has only one Emacs installation, with only
one HOME directory where settings are saved.  But that is profoundly
not true: people have Emacs installed on several machines, with HOME
directories not necessarily shared.  Emacs developers might very well
have several HOME directories on the same machine, for testing
purposes (I certainly have such setups and use them all the time).
Last, but not least, "emacs -Q" will not save any settings nor use
previously set ones.

That is why IMO we must make the default level strike a reasonable
balance between "more checks" and "convenience".  It is IMO
unreasonable to base such a balance on the assumption that a dedicated
team of thugs with torture chambers are out there to get every one of
us.  I think these cases are a minority, which should be catered to by
non-default security levels -- that's where 'high' and 'paranoid'
should come into the play.

> The `paranoid` level is security theatre.

If the 'paranoid' level doesn't do a useful job, it should be modified
to do a useful job.  The decision whether we even need such a level
should IMO be one we take _after_ classifying the vulnerabilities and
their prevention measures, not before.  It is quite possible we will
decide that we don't need such a level, but the fact it is not useful
today doesn't mean it cannot be useful.

I would very much like the security experts we have in our ranks help
us make these decisions by using their expertise to produce such an
analysis of the issues.  Then this whole discussion would be much more
constructive, and I believe agreements could be reached much faster.

> For STARTTLS, if the server does not support TLS, you will have gotten
> a prompt for using a plain connection already, so why the extra
> prompt?

Does what you say cover Emacs built without TLS support, for example?

> Emacs is not (only) a browser, but that's a moot point
> -----------------------------------------------------------------------
> Emacs' use base is diverse. People not only browse the Web with it,
> but read and reply to emails, browse newgroups, chat on
> IRC/Jabber/Slack, push code to Github etc., all of which require the
> network to be secured with TLS. While TLS is mostly used on the Web
> because of HTTPS, SSL/TLS has been mandatory for Gmail for many years
> now, Github also requires TLS for code push, and so do many chat
> servers. The way Emacs has deployed TLS either has a fault or it
> doesn't, it doesn't matter which protocol TLS is wrapping over.

I don't see how your conclusion necessarily follows from the fact that
most or all protocols we use are secured with TLS.  Isn't it true that
some of the vulnerabilities are only or mainly specific to some
protocols or even some classes of servers?  Is it really true that,
say, fetching and sending email on the one side, browsing s Web page
on the other, and chatting on the third, all bump into the same set of
risks?  This is the kind of analysis I'd like to see before we make up
our minds what should be in 'medium'.

(Btw, is Github relevant to the issue at hand?  We access Git
repositories by invoking Git, we don't access them from Emacs
directly, AFAIK.)

> `gnutls-min-prime-bits` should be `nil` on Emacs 26.2

As I already said, this will delay the release of Emacs 26.2 by many
moons.  From my POV, doing so is not a good idea, as we already have
quite a few non-trivial bugfixes on the emacs-26 branch, but if no one
else is bothered, I'm fine with doing that.

IOW, this is a project-management decision, not a security-related
decision.

> OpenSSL is nice, but getting much improved network security out the
> door ASAP is nicer
> ----------------------------------------------------------------------------------------------------------------------
> While OpenSSL certainly has its advantages, it is also a much bigger
> target. When dealing with security issues, one has to consider the
> economics. When economics are factored, an attacker will often ask if
> it make sense to spend a month working on an attack to target a small
> user base such as GnuTLS'. The answer to that is likely to be false.
> But if we are on OpenSSL, any new attack targeted towards it will make
> Emacs a target as well.
> 
> In addition, these days I try to live by a motto - Don't let the
> perfect be the enemy of the good. Replacing GnuTLS with OpenSSL is
> significantly harder than writing a couple C functions to get the most
> out of GnuTLS. Replacing it without major regressions even harder.
> Besides, most of Emacs' network security problems do not come from it
> use of GnuTLS, but deficiencies in NSM. I believe Emacs' network
> security can get much better faster if we focus our efforts on the
> current design.

Agreed.

> Documenting security changes
> -----------------------------------------
> Currently, Emacs' network security settings are poorly documented and
> widely misunderstood. There's only one page on the entire Emacs manual
> that briefly describes the checks NSM has, but it doesn't mention what
> its relation is with GnuTLS. There is also no mention of NSM or GnuTLS
> in the Emacs Lisp Reference whatsoever.

NSM documentation that exists was adequate when the number of features
it provided was small, which is what we had until now.  With a vastly
larger number of checks and customization opportunities, the
documentation we have is entirely inadequate, and we must extend it.

> I aim to improve it, but given the amount of work involved to bring
> Emacs' network security up to date, I'd rather submit another patch
> when the dust has settled.  (*cough* feature creep *cough*)

IMO this is a mistake, and I urge you to reconsider.  While there's no
need to follow up each code change on a scratch branch with a suitable
documentation change, I think we already have a lot of added turf to
document, and having at least that well documented will go a long way
towards the goal.  It could even make this discussion more efficient
and more rational, since we would all be on the same page wrt the
issues being discussed, even though not all of us are experts on these
matters.

Thanks again for working on this.

Re: A couple of questions and concerns about Emacs network security

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> As to `high`, those 3 checks ideally should be included in `medium`
>
> I'm still questioning how can this be TRT.  Please remember that
> 'medium' in Emacs really means 'minimum', because 'low' has no
> security checks at all.  How can it make sense to have _all_ the
> checks on the _minimum_ level?  (I say "all" because you clearly think
> 'high' and 'paranoid' should be removed, and their checks, those which
> make sense, moved into 'medium'.)
>

Thatʼs not quite my reading. Jimmy says:

  until RSA KX, DHE KX and CBC
  ciphers go away completely from the servers, I believe putting them on
  the `high` level is appropriate.

so, it not a proposal to move them now. By the time that can be done,
I suspect there will be other checks that can be added into
'high'. And most checks *should* be on 'medium', since many people will
never change the defaults.

> Suppose I work in Emacs on an internal secure network that is
> physically disconnected from the Internet (many enterprises, including
> my daytime job, have such stand-alone networks as a matter of
> routine).  Why would I need all the checks you propose on such a
> network?  OTOH, I don't want to go to 'low' (i.e. 'none') on such
> networks, because who knows what viri and other calamities can be once
> in a blue moon present on some of the machines on that network.

Current security thinking no longer makes a distinction between
'internal' and 'external' networks, they're all assumed to be
potentially dangerous, so 'low' would never be appropriate (except for
honeypot type activities).

> Same questions regarding a home network, separated from the outside
> world by a firewall.

I have such a network at home. I also have family members who are not
necessarily as aware of security issues as I am, and who also possess
network connections that are not secured by my firewall.

> Why shouldn't Emacs cater to such use cases?
>
> On the other end, there are legitimate use cases where users might
> need to access sites and servers known in advance to be dangerous.
> Why shouldn't Emacs provide a 'paranoid' set of settings for such use
> cases?

That I agree with, and thatʼs why I use 'paranoid', limited as it
currently is.

> The RFCs you cite and the vulnerabilities they describe should IMO be
> carefully analyzed, in the context of typical Emacs jobs that require
> network connections, and then we should grade them by their
> importance, divide them into 3 or 4 meaningful classes (a.k.a.
> "levels"), and let users change their settings in meaningful ways by
> changing the level.  Fine-grained settings should IMO also be
> provided, but they cannot be the only solution that we offer our
> users, precisely because not everyone has time to study each
> individual feature, but they normally will have time to read a
> description of 3 to 4 levels and decide which one is for them,
> especially if we describe them in terms that are related to the
> general environment rather than to specific vulnerabilities, similar
> to how many laptops ask you to select whether the new connection is
> for "home network", "enterprise", or "public network" -- that's
> something that every user can normally answer.

I donʼt think this is the right approach: the defaults should be as
secure as we can make it whilst remaining reasonably convenient. I see
no real use case for 4 separate classes that could meaningfully be
used by a typical user (as distinct from 'low', 'paranoid', and the
fine-grained settings, all intended for experts).

>> More checks does not mean more inconvenience
>> -----------------------------------------------------------------
>> NSM will only prompt you when a check fails *AND* these failed checks
>> for a host have not been saved as exceptions. If you answer "session
>> only" after the prompt, NSM will not prompt you again until you
>> restart Emacs. If you answer "always", NSM will not prompt you again
>> for those failed checks for that host as long as the exceptions are
>> still saved on file. The ability of having a "chance to choose between
>> the alternatives (convenience and safety) early enough that they won't
>> beunsafe.  The choice should come with an explanation of each option,
>> first stating what situations it is recommended for, then what it
>> does." is already implemented in master.
>> 
>> Having said that, NSM currenly may prompt you many times if there is
>> more than one security check failures, i.e. if your level is set to
>> `high` and the server such as Google's is load balancing TLS
>> connections with 2 or more certs with different fingerprints, and it's
>> using SHA1 signatures, you will get 3 prompts. I have streamlined all
>> of those in my branch so you only get prompted once for all the
>> problems found. That's **more** convenience and "more" safety. You can
>> have your cake and eat it too.
>
> These improvements are good (provided that they indeed work in
> practice -- I will have to try them), but IMO they are not enough.
> You assume each one of us has only one Emacs installation, with only
> one HOME directory where settings are saved.  But that is profoundly
> not true: people have Emacs installed on several machines, with HOME
> directories not necessarily shared.  Emacs developers might very well
> have several HOME directories on the same machine, for testing
> purposes (I certainly have such setups and use them all the time).
> Last, but not least, "emacs -Q" will not save any settings nor use
> previously set ones.

Iʼm not sure what youʼre proposing here.  These settings are per-HOME,
as all emacs settings are. Did you want some method for sharing the
NSM settings?

> That is why IMO we must make the default level strike a reasonable
> balance between "more checks" and "convenience".  It is IMO
> unreasonable to base such a balance on the assumption that a dedicated
> team of thugs with torture chambers are out there to get every one of
> us.  I think these cases are a minority, which should be catered to by
> non-default security levels -- that's where 'high' and 'paranoid'
> should come into the play.

Even people not in physical danger deserve to have their
communications protected from interception and snooping, as part of
the basic human right to privacy and freedom from unjustified
governmental tracking of their online behaviour.

>> The `paranoid` level is security theatre.
>
> If the 'paranoid' level doesn't do a useful job, it should be modified
> to do a useful job.  The decision whether we even need such a level
> should IMO be one we take _after_ classifying the vulnerabilities and
> their prevention measures, not before.  It is quite possible we will
> decide that we don't need such a level, but the fact it is not useful
> today doesn't mean it cannot be useful.
>
> I would very much like the security experts we have in our ranks help
> us make these decisions by using their expertise to produce such an
> analysis of the issues.  Then this whole discussion would be much more
> constructive, and I believe agreements could be reached much faster.
>
>> For STARTTLS, if the server does not support TLS, you will have gotten
>> a prompt for using a plain connection already, so why the extra
>> prompt?
>
> Does what you say cover Emacs built without TLS support, for example?
>

Thatʼs an excellent question to which I donʼt have an answer, although the
'open-network-stream' doc-string has:

  `starttls' -- Begin with an ordinary connection, and try
                upgrading via STARTTLS.  If that fails for any
                reason, drop the connection; in that case the
                returned object is a killed process.

and

  :use-starttls-if-possible is a boolean that says to do opportunistic
  STARTTLS upgrades even if Emacs doesn't have built-in TLS functionality.

So perhaps we should ensure that all uses of it in emacs use that one
or both of those where reasonable (the docstring for that function is
long and complex, and all the possible interactions of various tls
options are not obvious to me).

As an aside, we should really try to steer people away from both
cleartext *and* STARTTLS connections towards using direct TLS
connections, but Iʼm not sure what the right method is there.

>> Emacs is not (only) a browser, but that's a moot point
>> -----------------------------------------------------------------------
>> Emacs' use base is diverse. People not only browse the Web with it,
>> but read and reply to emails, browse newgroups, chat on
>> IRC/Jabber/Slack, push code to Github etc., all of which require the
>> network to be secured with TLS. While TLS is mostly used on the Web
>> because of HTTPS, SSL/TLS has been mandatory for Gmail for many years
>> now, Github also requires TLS for code push, and so do many chat
>> servers. The way Emacs has deployed TLS either has a fault or it
>> doesn't, it doesn't matter which protocol TLS is wrapping over.
>
> I don't see how your conclusion necessarily follows from the fact that
> most or all protocols we use are secured with TLS.  Isn't it true that
> some of the vulnerabilities are only or mainly specific to some
> protocols or even some classes of servers?  Is it really true that,
> say, fetching and sending email on the one side, browsing s Web page
> on the other, and chatting on the third, all bump into the same set of
> risks?  This is the kind of analysis I'd like to see before we make up
> our minds what should be in 'medium'.
>
> (Btw, is Github relevant to the issue at hand?  We access Git
> repositories by invoking Git, we don't access them from Emacs
> directly, AFAIK.)
>
>> `gnutls-min-prime-bits` should be `nil` on Emacs 26.2

That might be going a bit far, but I can certainly do that locally and
see what happens.

> As I already said, this will delay the release of Emacs 26.2 by many
> moons.  From my POV, doing so is not a good idea, as we already have
> quite a few non-trivial bugfixes on the emacs-26 branch, but if no one
> else is bothered, I'm fine with doing that.
>
> IOW, this is a project-management decision, not a security-related
> decision.
>

26.1 is out there. 26.2 has some fixes, but I see nothing that
requires a quick 26.2 release (but my perspective is skewed by the
fact that I build from git anyway).

>> I aim to improve it, but given the amount of work involved to bring
>> Emacs' network security up to date, I'd rather submit another patch
>> when the dust has settled.  (*cough* feature creep *cough*)
>
> IMO this is a mistake, and I urge you to reconsider.  While there's no
> need to follow up each code change on a scratch branch with a suitable
> documentation change, I think we already have a lot of added turf to
> document, and having at least that well documented will go a long way
> towards the goal.  It could even make this discussion more efficient
> and more rational, since we would all be on the same page wrt the
> issues being discussed, even though not all of us are experts on these
> matters.
>

Documentation is good. Iʼll see if I can find some time to work on
that.

> Thanks again for working on this.

Likewise.

Regards

Robert

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Jimmy Yuen Ho Wong <wyuenho@gmail.com>,  perry@piermont.com,  larsi@gnus.org,  eggert@cs.ucla.edu,  rms@gnu.org,  emacs-devel@gnu.org
> Date: Fri, 06 Jul 2018 11:28:24 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> As to `high`, those 3 checks ideally should be included in `medium`
> >
> > I'm still questioning how can this be TRT.  Please remember that
> > 'medium' in Emacs really means 'minimum', because 'low' has no
> > security checks at all.  How can it make sense to have _all_ the
> > checks on the _minimum_ level?  (I say "all" because you clearly think
> > 'high' and 'paranoid' should be removed, and their checks, those which
> > make sense, moved into 'medium'.)
> >
> 
> Thatʼs not quite my reading. Jimmy says:
> 
>   until RSA KX, DHE KX and CBC
>   ciphers go away completely from the servers, I believe putting them on
>   the `high` level is appropriate.
> 
> so, it not a proposal to move them now.

Not now, indeed, but only for temporary practical reasons:

> As to `high`, those 3 checks ideally should be included in `medium`

I was referring to the general tendency, which is quite clear.

> By the time that can be done, I suspect there will be other checks
> that can be added into 'high'. And most checks *should* be on
> 'medium', since many people will never change the defaults.

I agree that the defaults should be reasonable for that reason.  My
problem is with the "most" part: I'm not yet convinced it is TRT.

> Current security thinking no longer makes a distinction between
> 'internal' and 'external' networks, they're all assumed to be
> potentially dangerous

I question the wisdom of such security thinking.  The security officer
on my daytime job clearly disagrees with that.  (Cannot tell the
details here, because there will be too many people I'll have to take
out and shoot afterwards ;-)

> so 'low' would never be appropriate (except for honeypot type
> activities).

In Emacs, 'low' is actually 'none'.  Which is an other thing that
makes little sense to me.  I know of no other application whose
default security level is one notch above no security at all, they all
provide a "less secure" level.

So yes, I agree that 'low' in Emacs is almost never appropriate, but I
agree for entirely different reasons.

> > Same questions regarding a home network, separated from the outside
> > world by a firewall.
> 
> I have such a network at home. I also have family members who are not
> necessarily as aware of security issues as I am, and who also possess
> network connections that are not secured by my firewall.

So your network may be less secure than my home network, where only
machines and devices to which I explicitly allow access can connect.
It's legitimate to have home networks of different security standards.
What I think is not optimal is that Emacs would not provide a security
level that allows me to specify a trusted environment.  As someone who
may not understand all the intricacies of the individual security
features we provide, and might have no time to read up on all of them,
I might still be competent enough to set up my home network securely
(or hire someone to do that), and be sure it is not as vulnerable as a
public network or an Internet connection or the home network of the
guy next door.

> I donʼt think this is the right approach: the defaults should be as
> secure as we can make it whilst remaining reasonably convenient.

Once again, we agree with the principles, it's the details which
matter.  Isn't it true that any failed check will pop up some prompt
or message?  Isn't it true that each such prompt makes using Emacs
less convenient?  If the answer is YES to both questions, then we need
to find the optimal set of features we turn on so that Emacs is "as
secure as we can make it whilst remaining reasonably convenient".
Right?

> I see no real use case for 4 separate classes that could
> meaningfully be used by a typical user

How can you say that before we classify the risks into however many
classes they present?  Maybe I will agree with you once we have such a
classification, but not in advance.

> >> Having said that, NSM currenly may prompt you many times if there is
> >> more than one security check failures, i.e. if your level is set to
> >> `high` and the server such as Google's is load balancing TLS
> >> connections with 2 or more certs with different fingerprints, and it's
> >> using SHA1 signatures, you will get 3 prompts. I have streamlined all
> >> of those in my branch so you only get prompted once for all the
> >> problems found. That's **more** convenience and "more" safety. You can
> >> have your cake and eat it too.
> >
> > These improvements are good (provided that they indeed work in
> > practice -- I will have to try them), but IMO they are not enough.
> > You assume each one of us has only one Emacs installation, with only
> > one HOME directory where settings are saved.  But that is profoundly
> > not true: people have Emacs installed on several machines, with HOME
> > directories not necessarily shared.  Emacs developers might very well
> > have several HOME directories on the same machine, for testing
> > purposes (I certainly have such setups and use them all the time).
> > Last, but not least, "emacs -Q" will not save any settings nor use
> > previously set ones.
> 
> Iʼm not sure what youʼre proposing here.

I'm saying we cannot rely on the fact that NSM asks certain questions
only once.  We cannot see that feature as a solution for annoyance.

> > That is why IMO we must make the default level strike a reasonable
> > balance between "more checks" and "convenience".  It is IMO
> > unreasonable to base such a balance on the assumption that a dedicated
> > team of thugs with torture chambers are out there to get every one of
> > us.  I think these cases are a minority, which should be catered to by
> > non-default security levels -- that's where 'high' and 'paranoid'
> > should come into the play.
> 
> Even people not in physical danger deserve to have their
> communications protected from interception and snooping, as part of
> the basic human right to privacy and freedom from unjustified
> governmental tracking of their online behaviour.

But people in physical danger need more protection, don't you agree?
And for those people in danger, additional inconvenience is justified,
right?  But that additional inconvenience is net necessarily justified
for people who are NOT in physical danger, for them it's just an
annoyance.  Same thing for when the probability of someone snooping on
you is lower than for someone else.

For these reasons, I find the "one level fits all" idea sub-optimal.

> As an aside, we should really try to steer people away from both
> cleartext *and* STARTTLS connections towards using direct TLS
> connections

I agree, but my point was that perhaps 'paranoid' should fail any
non-TLS connections, whereas other levels should not automatically
fail them.  Or something like that.

> > As I already said, this will delay the release of Emacs 26.2 by many
> > moons.  From my POV, doing so is not a good idea, as we already have
> > quite a few non-trivial bugfixes on the emacs-26 branch, but if no one
> > else is bothered, I'm fine with doing that.
> >
> > IOW, this is a project-management decision, not a security-related
> > decision.
> >
> 
> 26.1 is out there. 26.2 has some fixes, but I see nothing that
> requires a quick 26.2 release (but my perspective is skewed by the
> fact that I build from git anyway).

Yes, I think your perspective is different from mine.  I see quite a
few bugfixes that are important to get out ASAP.  Just look at "git
log" past the release, and I believe you will agree.

> Documentation is good. Iʼll see if I can find some time to work on
> that.

Thank you very much.

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

>
>> Same questions regarding a home network, separated from the outside
>> world by a firewall.
>
> I have such a network at home. I also have family members who are not
> necessarily as aware of security issues as I am, and who also possess
> network connections that are not secured by my firewall.
>
>> Why shouldn't Emacs cater to such use cases?
>>
>> On the other end, there are legitimate use cases where users might
>> need to access sites and servers known in advance to be dangerous.
>> Why shouldn't Emacs provide a 'paranoid' set of settings for such use
>> cases?
>
> That I agree with, and thatʼs why I use 'paranoid', limited as it
> currently is.
>

I disagree that prompting for pretty much every TLS connection is a
good idea. In security circles these days, there's such a thing known
as "security fatigue". Overly troublesome security measure that don't
take human psychology into account will lead to numbness. A side
effect of that is users will simply start ignoring security warnings
like they skip reading iTunes's EULA. This is an adverse unintended
consequence that achieves the opposite of what we want to do here.

>>> `gnutls-min-prime-bits` should be `nil` on Emacs 26.2
>
> That might be going a bit far, but I can certainly do that locally and
> see what happens.
>

As I've said, setting `gnutls-min-prime-bits` to nil simply means
GnuTLS will negotiate the right number of DH bits on the user's
behalf, starting from 1008 bits since 3.3.0.

>
> Documentation is good. Iʼll see if I can find some time to work on
> that.
>

Thanks for helping out :)

Re: A couple of questions and concerns about Emacs network security

[Perry E. Metzger]

On Fri, 6 Jul 2018 19:06:29 +0100 Jimmy Yuen Ho Wong
<wyuenho@gmail.com> wrote:
> I disagree that prompting for pretty much every TLS connection is a
> good idea. In security circles these days, there's such a thing
> known as "security fatigue". Overly troublesome security measure
> that don't take human psychology into account will lead to
> numbness. A side effect of that is users will simply start ignoring
> security warnings like they skip reading iTunes's EULA. This is an
> adverse unintended consequence that achieves the opposite of what
> we want to do here.

This is an incredibly important point.

Users cannot meaningfully make decision after decision after decision
without burning out and ceasing to have any real sense of what
they're doing. The published studies say people start clicking
through regardless of the warnings after a while. This is one of the
reasons that browsers like Firefox now no longer provide so many
decision points for users.

There's nothing wrong with letting users customize policies in
their .emacs file, but constantly prompting people to make decisions
based on little information is not really workable.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> Date: Fri, 6 Jul 2018 19:06:29 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, "Perry E. Metzger" <perry@piermont.com>, Lars Ingebrigtsen <larsi@gnus.org>, 
> 	Paul Eggert <eggert@cs.ucla.edu>, rms@gnu.org
> 
> In security circles these days, there's such a thing known as
> "security fatigue". Overly troublesome security measure that don't
> take human psychology into account will lead to numbness. A side
> effect of that is users will simply start ignoring security warnings
> like they skip reading iTunes's EULA.

Exactly my concerns wrt putting too many checks into 'medium'.

Is there any way to know in advance the percentage of connections (by
protocol, if possible) that will trigger any of those checks?  If so,
we could have some quantitative measure of when the "fatigue" might
strike, and decide accordingly.  Failing that, I guess the only way
would be to let users complain...

Re: A couple of questions and concerns about Emacs network security

[Robert Pluim]

Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:

> I disagree that prompting for pretty much every TLS connection is a
> good idea. In security circles these days, there's such a thing known
> as "security fatigue". Overly troublesome security measure that don't
> take human psychology into account will lead to numbness. A side
> effect of that is users will simply start ignoring security warnings
> like they skip reading iTunes's EULA. This is an adverse unintended
> consequence that achieves the opposite of what we want to do here.

For normal usage, we should absolutely not prompt too much [1]. Iʼm not
recommending 'paranoid' to anyone, but in my specific circumstances
itʼs the right thing to do.

>>>> `gnutls-min-prime-bits` should be `nil` on Emacs 26.2
>>
>> That might be going a bit far, but I can certainly do that locally and
>> see what happens.
>>
>
> As I've said, setting `gnutls-min-prime-bits` to nil simply means
> GnuTLS will negotiate the right number of DH bits on the user's
> behalf, starting from 1008 bits since 3.3.0.
>
>>
>> Documentation is good. Iʼll see if I can find some time to work on
>> that.
>>
>
> Thanks for helping out :)

Is your work on a git branch somewhere?

Regards

Robert

Footnotes:
[1]  If you fix the double-prompting caused by google's certificate
     load-balancing, that would reduce it a lot for me :-)

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

On Sat, Jul 7, 2018 at 10:36 AM, Robert Pluim <rpluim@gmail.com> wrote:
> Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:
>
>> I disagree that prompting for pretty much every TLS connection is a
>> good idea. In security circles these days, there's such a thing known
>> as "security fatigue". Overly troublesome security measure that don't
>> take human psychology into account will lead to numbness. A side
>> effect of that is users will simply start ignoring security warnings
>> like they skip reading iTunes's EULA. This is an adverse unintended
>> consequence that achieves the opposite of what we want to do here.
>
> For normal usage, we should absolutely not prompt too much [1]. Iʼm not
> recommending 'paranoid' to anyone, but in my specific circumstances
> itʼs the right thing to do.
>

I still fail to see what those circumstances are that warrant
prompting the user whenever he visits a URL with TLS that he hasn't
visited before.

>>>>> `gnutls-min-prime-bits` should be `nil` on Emacs 26.2
>>>
>>> That might be going a bit far, but I can certainly do that locally and
>>> see what happens.
>>>
>>
>> As I've said, setting `gnutls-min-prime-bits` to nil simply means
>> GnuTLS will negotiate the right number of DH bits on the user's
>> behalf, starting from 1008 bits since 3.3.0.
>>
>>>
>>> Documentation is good. Iʼll see if I can find some time to work on
>>> that.
>>>
>>
>> Thanks for helping out :)
>
> Is your work on a git branch somewhere?

It's on Github: https://github.com/wyuenho/emacs/tree/additional-nsm-checks

Diff to master:
https://github.com/emacs-mirror/emacs/compare/master...wyuenho:additional-nsm-checks

You can just fork my fork and send over a PR.

There's still a couple of things I need to do:

1. Implement `nsm-trust-local-network`
2. Remove that change in src/gnutls.h not needed for bug#31946 (this
is from my OCSP stash still sitting on my machine)
3. Write some ert tests, but this should affect the doc effort
4. I might throw in a few more checks to detech DHE-DSS key exchange
and DSA signature. IETF TLSWG has removed it from TLS 1.3, so do
browsers, but I haven't been able to find much information about them
other than they are not used. There's a claim made that DSS key
exchange is just as bad as static RSA, but DHE-DSS is not that same as
DSS...

Thanks again!

>
> Regards
>
> Robert
>
> Footnotes:
> [1]  If you fix the double-prompting caused by google's certificate
>      load-balancing, that would reduce it a lot for me :-)
>

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

> Write some ert tests, but this should affect the doc effort

I mean it shouldn't... I can't type

On Sat, Jul 7, 2018 at 10:59 AM, Jimmy Yuen Ho Wong <wyuenho@gmail.com> wrote:
> On Sat, Jul 7, 2018 at 10:36 AM, Robert Pluim <rpluim@gmail.com> wrote:
>> Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:
>>
>>> I disagree that prompting for pretty much every TLS connection is a
>>> good idea. In security circles these days, there's such a thing known
>>> as "security fatigue". Overly troublesome security measure that don't
>>> take human psychology into account will lead to numbness. A side
>>> effect of that is users will simply start ignoring security warnings
>>> like they skip reading iTunes's EULA. This is an adverse unintended
>>> consequence that achieves the opposite of what we want to do here.
>>
>> For normal usage, we should absolutely not prompt too much [1]. Iʼm not
>> recommending 'paranoid' to anyone, but in my specific circumstances
>> itʼs the right thing to do.
>>
>
> I still fail to see what those circumstances are that warrant
> prompting the user whenever he visits a URL with TLS that he hasn't
> visited before.
>
>>>>>> `gnutls-min-prime-bits` should be `nil` on Emacs 26.2
>>>>
>>>> That might be going a bit far, but I can certainly do that locally and
>>>> see what happens.
>>>>
>>>
>>> As I've said, setting `gnutls-min-prime-bits` to nil simply means
>>> GnuTLS will negotiate the right number of DH bits on the user's
>>> behalf, starting from 1008 bits since 3.3.0.
>>>
>>>>
>>>> Documentation is good. Iʼll see if I can find some time to work on
>>>> that.
>>>>
>>>
>>> Thanks for helping out :)
>>
>> Is your work on a git branch somewhere?
>
> It's on Github: https://github.com/wyuenho/emacs/tree/additional-nsm-checks
>
> Diff to master:
> https://github.com/emacs-mirror/emacs/compare/master...wyuenho:additional-nsm-checks
>
> You can just fork my fork and send over a PR.
>
> There's still a couple of things I need to do:
>
> 1. Implement `nsm-trust-local-network`
> 2. Remove that change in src/gnutls.h not needed for bug#31946 (this
> is from my OCSP stash still sitting on my machine)
> 3. Write some ert tests, but this should affect the doc effort
> 4. I might throw in a few more checks to detech DHE-DSS key exchange
> and DSA signature. IETF TLSWG has removed it from TLS 1.3, so do
> browsers, but I haven't been able to find much information about them
> other than they are not used. There's a claim made that DSS key
> exchange is just as bad as static RSA, but DHE-DSS is not that same as
> DSS...
>
> Thanks again!
>
>>
>> Regards
>>
>> Robert
>>
>> Footnotes:
>> [1]  If you fix the double-prompting caused by google's certificate
>>      load-balancing, that would reduce it a lot for me :-)
>>

Re: A couple of questions and concerns about Emacs network security

[Ted Zlatanov]

On Sat, 7 Jul 2018 10:59:42 +0100 Jimmy Yuen Ho Wong <wyuenho@gmail.com> wrote: 

JYHW> On Sat, Jul 7, 2018 at 10:36 AM, Robert Pluim <rpluim@gmail.com> wrote:
>> Is your work on a git branch somewhere?

JYHW> It's on Github: https://github.com/wyuenho/emacs/tree/additional-nsm-checks

JYHW> Diff to master:
JYHW> https://github.com/emacs-mirror/emacs/compare/master...wyuenho:additional-nsm-checks

JYHW> You can just fork my fork and send over a PR.

Hi Jimmy,

I think your work is terrific. Sorry if this has been discussed before
but I couldn't find the answer to a key question: have you signed the
contributor papers?

If yes, I'd like to put your code in an emacs.git branch e.g.
feature/wyuenho/additional-nsm-checks so people can start testing it
without requiring Github access.

JYHW> There's still a couple of things I need to do:
[omitted]

Are any of those blockers for pushing the code into that branch?

Thanks
Ted

Re: A couple of questions and concerns about Emacs network security

[Paul Eggert]

Ted Zlatanov wrote:
> I couldn't find the answer to a key question: have you signed the
> contributor papers?

He's not listed by the FSF copyright clerk as having done so. Jimmy, have you 
started the ball rolling on the paperwork for that? If not, I can email you the 
appropriate forms.

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

>
> Ted Zlatanov wrote:
> > I couldn't find the answer to a key question: have you signed the
> > contributor papers?
>
> He's not listed by the FSF copyright clerk as having done so. Jimmy, have you
> started the ball rolling on the paperwork for that? If not, I can email you the
> appropriate forms.

I have signed and emailed it back 2 weeks ago. I'll ping the clerk again.

Re: A couple of questions and concerns about Emacs network security

[Ted Zlatanov]

On Sat, 7 Jul 2018 23:11:50 +0100 Jimmy Yuen Ho Wong <wyuenho@gmail.com> wrote: 

>> Ted Zlatanov wrote:
>> > I couldn't find the answer to a key question: have you signed the
>> > contributor papers?
>> 
>> He's not listed by the FSF copyright clerk as having done so. Jimmy, have you
>> started the ball rolling on the paperwork for that? If not, I can email you the
>> appropriate forms.

JYHW> I have signed and emailed it back 2 weeks ago. I'll ping the clerk again.

OK. You should probably be able to commit to emacs.git as well.

Ted

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

> OK. You should probably be able to commit to emacs.git as well.
>
> Ted

Wooot! Thanks! How do I push my branch to Savannah tho? I just created
an account after seeing this email.

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> Date: Tue, 10 Jul 2018 19:20:28 +0100
> Cc: Paul Eggert <eggert@cs.ucla.edu>, rms@gnu.org, 
> 	"Perry E. Metzger" <perry@piermont.com>, Lars Ingebrigtsen <larsi@gnus.org>, 
> 	Emacs-Devel devel <emacs-devel@gnu.org>, Eli Zaretskii <eliz@gnu.org>
> 
> > OK. You should probably be able to commit to emacs.git as well.
> >
> > Ted
> 
> Wooot! Thanks! How do I push my branch to Savannah tho?

You need to get write access, and for that we need to wait till your
legal paperwork is completed (it isn't as of now, AFAICT).

Thanks.

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

On Tue, Jul 10, 2018 at 7:37 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> > Date: Tue, 10 Jul 2018 19:20:28 +0100
> > Cc: Paul Eggert <eggert@cs.ucla.edu>, rms@gnu.org,
> >       "Perry E. Metzger" <perry@piermont.com>, Lars Ingebrigtsen <larsi@gnus.org>,
> >       Emacs-Devel devel <emacs-devel@gnu.org>, Eli Zaretskii <eliz@gnu.org>
> >
> > > OK. You should probably be able to commit to emacs.git as well.
> > >
> > > Ted
> >
> > Wooot! Thanks! How do I push my branch to Savannah tho?
>
> You need to get write access, and for that we need to wait till your
> legal paperwork is completed (it isn't as of now, AFAICT).
>
> Thanks.

Do you know what's holding the clerk up? It's been more than a few
weeks already and I've pinged the clerk a few days ago. She still
hasn't replied.

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> Date: Tue, 10 Jul 2018 19:40:22 +0100
> Cc: Ted Zlatanov <tzz@lifelogs.com>, Paul Eggert <eggert@cs.ucla.edu>, rms@gnu.org, 
> 	"Perry E. Metzger" <perry@piermont.com>, Lars Ingebrigtsen <larsi@gnus.org>, 
> 	Emacs-Devel devel <emacs-devel@gnu.org>
> 
> Do you know what's holding the clerk up? It's been more than a few
> weeks already and I've pinged the clerk a few days ago. She still
> hasn't replied.

Summer vacations, I guess.  Just keep pinging until you get a reply.

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

On Tue, Jul 10, 2018 at 7:59 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> > Date: Tue, 10 Jul 2018 19:40:22 +0100
> > Cc: Ted Zlatanov <tzz@lifelogs.com>, Paul Eggert <eggert@cs.ucla.edu>, rms@gnu.org,
> >       "Perry E. Metzger" <perry@piermont.com>, Lars Ingebrigtsen <larsi@gnus.org>,
> >       Emacs-Devel devel <emacs-devel@gnu.org>
> >
> > Do you know what's holding the clerk up? It's been more than a few
> > weeks already and I've pinged the clerk a few days ago. She still
> > hasn't replied.
>
> Summer vacations, I guess.  Just keep pinging until you get a reply.

Just got confirmation that my paperwork had been signed by all
parties. Set me up?

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> Date: Fri, 13 Jul 2018 21:50:41 +0100
> Cc: Ted Zlatanov <tzz@lifelogs.com>, Paul Eggert <eggert@cs.ucla.edu>, rms@gnu.org, 
> 	"Perry E. Metzger" <perry@piermont.com>, Lars Ingebrigtsen <larsi@gnus.org>, 
> 	Emacs-Devel devel <emacs-devel@gnu.org>
> 
> Just got confirmation that my paperwork had been signed by all
> parties. Set me up?

Yes, your name i now on file.  But I see you didn't request membership
in the emacs project, or maybe I don't recognize your user name among
those who did.  You need to request membership, and then I can approve
you, which gives you write access to the repository.

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

Hi All,

I've just pushed a "netsec" branch to Savannah. Here's a summary of the changes:

* Ability to specify a bunch of CRL PEM files on your system for
GnuTLS to verify against
* Set the standard value of `gnutls-min-prime-bits` to nil so GnuTLS
can do its thing using its own default
* Completely revamped NSM checks - many new checks and bug fixes,
please see the commit diff for details
* New `nsm-trust-local-network` option to bypass implicitly trusted
NSM checks on local networks
* Revamped NSM prompt - full certificate chain details now available,
summary is also more useful now

Planned TODOs:

* OCSP
* Update NEWS and the manual

Please help me test the **** of out this branch with all kinds of
networks, OSes and servers.

Thank you so much!
On Sat, Jul 14, 2018 at 7:37 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> > Date: Fri, 13 Jul 2018 21:50:41 +0100
> > Cc: Ted Zlatanov <tzz@lifelogs.com>, Paul Eggert <eggert@cs.ucla.edu>, rms@gnu.org,
> >       "Perry E. Metzger" <perry@piermont.com>, Lars Ingebrigtsen <larsi@gnus.org>,
> >       Emacs-Devel devel <emacs-devel@gnu.org>
> >
> > Just got confirmation that my paperwork had been signed by all
> > parties. Set me up?
>
> Yes, your name i now on file.  But I see you didn't request membership
> in the emacs project, or maybe I don't recognize your user name among
> those who did.  You need to request membership, and then I can approve
> you, which gives you write access to the repository.
>

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> Date: Sat, 14 Jul 2018 18:18:52 +0100
> Cc: Paul Eggert <eggert@cs.ucla.edu>, rms@gnu.org, Ted Zlatanov <tzz@lifelogs.com>, 
> 	Emacs-Devel devel <emacs-devel@gnu.org>, Lars Ingebrigtsen <larsi@gnus.org>, 
> 	"Perry E. Metzger" <perry@piermont.com>
> 
> I've just pushed a "netsec" branch to Savannah.

Thanks!

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

>
> I think your work is terrific. Sorry if this has been discussed before
> but I couldn't find the answer to a key question: have you signed the
> contributor papers?
>
> If yes, I'd like to put your code in an emacs.git branch e.g.
> feature/wyuenho/additional-nsm-checks so people can start testing it
> without requiring Github access.
>

That'll be nice thanks!

>
> Are any of those blockers for pushing the code into that branch?
>

Nope. It works at least on my machine. Would be nice if people can
test it on theirs :)

Re: A couple of questions and concerns about Emacs network security

[Robert Pluim]

Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:

>> Is your work on a git branch somewhere?
>
> It's on Github: https://github.com/wyuenho/emacs/tree/additional-nsm-checks
>
> Diff to master:
> https://github.com/emacs-mirror/emacs/compare/master...wyuenho:additional-nsm-checks
>
> You can just fork my fork and send over a PR.
>
> There's still a couple of things I need to do:
>
> 1. Implement `nsm-trust-local-network`
> 2. Remove that change in src/gnutls.h not needed for bug#31946 (this
> is from my OCSP stash still sitting on my machine)

It needs either removing or making it work with earlier versions of GnuTLS:

gnutls.c: In function ‘Fgnutls_peer_status’:
gnutls.c:1353:22: error: ‘GNUTLS_CERT_MISSING_OCSP_STATUS’ undeclared (first use in this function)

I have:

pkg-config --modversion gnutls 
3.4.10

I think the OCSP stuff is 3.6.something.

> 3. Write some ert tests, but this should affect the doc effort
> 4. I might throw in a few more checks to detech DHE-DSS key exchange
> and DSA signature. IETF TLSWG has removed it from TLS 1.3, so do
> browsers, but I haven't been able to find much information about them
> other than they are not used. There's a claim made that DSS key
> exchange is just as bad as static RSA, but DHE-DSS is not that same as
> DSS...

I see youʼre checking for TLS < 1.1. TLS 1.1 has its fair share of
reported issues as well, perhaps we should check for < 1.2 (or we
could put that on 'high).

Regards

Robert

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

On Mon, Jul 9, 2018 at 2:09 PM Robert Pluim <rpluim@gmail.com> wrote:
>
> Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:
>
> >> Is your work on a git branch somewhere?
> >
> > It's on Github: https://github.com/wyuenho/emacs/tree/additional-nsm-checks
> >
> > Diff to master:
> > https://github.com/emacs-mirror/emacs/compare/master...wyuenho:additional-nsm-checks
> >
> > You can just fork my fork and send over a PR.
> >
> > There's still a couple of things I need to do:
> >
> > 1. Implement `nsm-trust-local-network`
> > 2. Remove that change in src/gnutls.h not needed for bug#31946 (this
> > is from my OCSP stash still sitting on my machine)
>
> It needs either removing or making it work with earlier versions of GnuTLS:
>
> gnutls.c: In function ‘Fgnutls_peer_status’:
> gnutls.c:1353:22: error: ‘GNUTLS_CERT_MISSING_OCSP_STATUS’ undeclared (first use in this function)
>
> I have:
>
> pkg-config --modversion gnutls
> 3.4.10
>
> I think the OCSP stuff is 3.6.something.
>

Ah! Thank you! It's >= 3.5.1. I just pushed a change to fix this.

> > 3. Write some ert tests, but this should affect the doc effort
> > 4. I might throw in a few more checks to detech DHE-DSS key exchange
> > and DSA signature. IETF TLSWG has removed it from TLS 1.3, so do
> > browsers, but I haven't been able to find much information about them
> > other than they are not used. There's a claim made that DSS key
> > exchange is just as bad as static RSA, but DHE-DSS is not that same as
> > DSS...
>
> I see youʼre checking for TLS < 1.1. TLS 1.1 has its fair share of
> reported issues as well, perhaps we should check for < 1.2 (or we
> could put that on 'high).
>

I thought about this, but there's no standard that bans TLS 1.1, nor
TLS client implementations that disabled it by default. Besides, all
the problems TLS 1.1 has is already checked by the other checks. This
reason I'm checking for TLS 1.0 is somewhat arbitrary, as all the
problems it has is already checked by other checks too. So maybe even
checking for 1.0 is already too strict, but PCI DSS does ban it, so...

Re: A couple of questions and concerns about Emacs network security

[Lars Ingebrigtsen]

Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:

> I thought about this, but there's no standard that bans TLS 1.1, nor
> TLS client implementations that disabled it by default. Besides, all
> the problems TLS 1.1 has is already checked by the other checks. This
> reason I'm checking for TLS 1.0 is somewhat arbitrary, as all the
> problems it has is already checked by other checks too. So maybe even
> checking for 1.0 is already too strict, but PCI DSS does ban it, so...

For those who don't understand security acronym soup, the latter means
"Payment Card Industry Data Security Standard".

And I don't think that's the level we should be considering for Emacs,
even at the "high" level, because it's pretty...  excessive.  Last time
I checked.

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

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

On Mon, Jul 9, 2018 at 2:44 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
> Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:
>
> > I thought about this, but there's no standard that bans TLS 1.1, nor
> > TLS client implementations that disabled it by default. Besides, all
> > the problems TLS 1.1 has is already checked by the other checks. This
> > reason I'm checking for TLS 1.0 is somewhat arbitrary, as all the
> > problems it has is already checked by other checks too. So maybe even
> > checking for 1.0 is already too strict, but PCI DSS does ban it, so...
>
> For those who don't understand security acronym soup, the latter means
> "Payment Card Industry Data Security Standard".
>
> And I don't think that's the level we should be considering for Emacs,
> even at the "high" level, because it's pretty...  excessive.  Last time
> I checked.
>

The only TLS requirement in PCI DSS is to use TLS 1.1 and above.
There's no other requirement that I'm aware of.

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Emacs-Devel devel <emacs-devel@gnu.org>,  "Perry E. Metzger" <perry@piermont.com>,  Eli Zaretskii <eliz@gnu.org>,  Paul Eggert <eggert@cs.ucla.edu>,  rms@gnu.org
> Date: Mon, 09 Jul 2018 15:43:43 +0200
> 
> Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:
> 
> > I thought about this, but there's no standard that bans TLS 1.1, nor
> > TLS client implementations that disabled it by default. Besides, all
> > the problems TLS 1.1 has is already checked by the other checks. This
> > reason I'm checking for TLS 1.0 is somewhat arbitrary, as all the
> > problems it has is already checked by other checks too. So maybe even
> > checking for 1.0 is already too strict, but PCI DSS does ban it, so...
> 
> For those who don't understand security acronym soup, the latter means
> "Payment Card Industry Data Security Standard".
> 
> And I don't think that's the level we should be considering for Emacs,
> even at the "high" level, because it's pretty...  excessive.  Last time
> I checked.

So maybe for 'paranoid'?

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

On Mon, Jul 9, 2018 at 6:15 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Lars Ingebrigtsen <larsi@gnus.org>
> > Cc: Emacs-Devel devel <emacs-devel@gnu.org>,  "Perry E. Metzger" <perry@piermont.com>,  Eli Zaretskii <eliz@gnu.org>,  Paul Eggert <eggert@cs.ucla.edu>,  rms@gnu.org
> > Date: Mon, 09 Jul 2018 15:43:43 +0200
> >
> > Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:
> >
> > > I thought about this, but there's no standard that bans TLS 1.1, nor
> > > TLS client implementations that disabled it by default. Besides, all
> > > the problems TLS 1.1 has is already checked by the other checks. This
> > > reason I'm checking for TLS 1.0 is somewhat arbitrary, as all the
> > > problems it has is already checked by other checks too. So maybe even
> > > checking for 1.0 is already too strict, but PCI DSS does ban it, so...
> >
> > For those who don't understand security acronym soup, the latter means
> > "Payment Card Industry Data Security Standard".
> >
> > And I don't think that's the level we should be considering for Emacs,
> > even at the "high" level, because it's pretty...  excessive.  Last time
> > I checked.
>
> So maybe for 'paranoid'?

Nooooooo...... enough with this 'paranoid business already :(

As I've replied to Robert and a few others already, the checks I have
done is already multi-layered. Under normal circumtances, warning for
TLS 1.0 should already takes care of checking of CBC mode
ciphers/encrypt-then-MAC (if the server was configured correctly when
TLS 1.0 was in vogue), but I check both regardless. The checks are
already plenty paranoid without being crying-wolf under a vast
majority normal usage.

Re: A couple of questions and concerns about Emacs network security

[Perry E. Metzger]

On Mon, 9 Jul 2018 18:24:03 +0100 Jimmy Yuen Ho Wong
<wyuenho@gmail.com> wrote:
> On Mon, Jul 9, 2018 at 6:15 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >  
> > > From: Lars Ingebrigtsen <larsi@gnus.org>
> > > Cc: Emacs-Devel devel <emacs-devel@gnu.org>,  "Perry E.
> > > Metzger" <perry@piermont.com>,  Eli Zaretskii <eliz@gnu.org>,
> > > Paul Eggert <eggert@cs.ucla.edu>,  rms@gnu.org Date: Mon, 09
> > > Jul 2018 15:43:43 +0200
> > >
> > > Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:
> > >  
> > > > I thought about this, but there's no standard that bans TLS
> > > > 1.1, nor TLS client implementations that disabled it by
> > > > default. Besides, all the problems TLS 1.1 has is already
> > > > checked by the other checks. This reason I'm checking for TLS
> > > > 1.0 is somewhat arbitrary, as all the problems it has is
> > > > already checked by other checks too. So maybe even checking
> > > > for 1.0 is already too strict, but PCI DSS does ban it,
> > > > so...  
> > >
> > > For those who don't understand security acronym soup, the
> > > latter means "Payment Card Industry Data Security Standard".
> > >
> > > And I don't think that's the level we should be considering for
> > > Emacs, even at the "high" level, because it's pretty...
> > > excessive.  Last time I checked.  
> >
> > So maybe for 'paranoid'?  
> 
> Nooooooo...... enough with this 'paranoid business already :(
> 
> As I've replied to Robert and a few others already, the checks I
> have done is already multi-layered. Under normal circumtances,
> warning for TLS 1.0 should already takes care of checking of CBC
> mode ciphers/encrypt-then-MAC (if the server was configured
> correctly when TLS 1.0 was in vogue), but I check both regardless.
> The checks are already plenty paranoid without being crying-wolf
> under a vast majority normal usage.

I strongly agree. PCI compliance is an industry base/minimum. It's
not paranoid. It's not even what I'd prefer -- it isn't nearly good
enough on TLS standards, but it's fine.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: A couple of questions and concerns about Emacs network security

[Perry E. Metzger]

On Mon, 09 Jul 2018 15:43:43 +0200 Lars Ingebrigtsen <larsi@gnus.org>
wrote:
> Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:
> 
> > I thought about this, but there's no standard that bans TLS 1.1,
> > nor TLS client implementations that disabled it by default.
> > Besides, all the problems TLS 1.1 has is already checked by the
> > other checks. This reason I'm checking for TLS 1.0 is somewhat
> > arbitrary, as all the problems it has is already checked by other
> > checks too. So maybe even checking for 1.0 is already too strict,
> > but PCI DSS does ban it, so...  
> 
> For those who don't understand security acronym soup, the latter
> means "Payment Card Industry Data Security Standard".
> 
> And I don't think that's the level we should be considering for
> Emacs, even at the "high" level, because it's pretty...
> excessive.  Last time I checked.

I deal with PCI compliance a lot. It's not excessive. It's in fact
insufficient, but it's a nice minimum. More to the point, though,
it's less than what many of the browser vendors are doing.

-- 
Perry E. Metzger		perry@piermont.com

Re: A couple of questions and concerns about Emacs network security

[Perry E. Metzger]

On Mon, 9 Jul 2018 14:33:17 +0100 Jimmy Yuen Ho Wong
<wyuenho@gmail.com> wrote:
> > I see youʼre checking for TLS < 1.1. TLS 1.1 has its fair share of
> > reported issues as well, perhaps we should check for < 1.2 (or we
> > could put that on 'high).
> >  
> 
> I thought about this, but there's no standard that bans TLS 1.1, nor
> TLS client implementations that disabled it by default. Besides, all
> the problems TLS 1.1 has is already checked by the other checks.
> This reason I'm checking for TLS 1.0 is somewhat arbitrary, as all
> the problems it has is already checked by other checks too. So
> maybe even checking for 1.0 is already too strict, but PCI DSS does
> ban it, so...

Yes, this is the correct choice. 1.1 is too widely deployed. Not
allowing 1.0 is quite reasonable, and it would be _nice_ to stop 1.1,
but it would be too disruptive. We should do that only after the
major browsers do the same.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

>
>> Most of the checks are on `medium` level because of **secure by default**
>> ---------------------------------------------------------------------------------------------------
>> **Secure by default** is a mantra used by InfoSec professionals, in
>> Emacs' lingo it means reasonable default settings. The reason 13 out
>> of 17 checks in my branch are on `medium` level is *not* because I'm
>> trying to mold NSM to such a way that its **security levels** are
>> indistinguishable with **secury level**, but because most of those
>> checks are RFC 7525's recommendation's for securely using TLS on the
>> client. RFC 7525 is listed as BEST CURRENT PRACTICE by IETF in 2015. I
>> have added a couple more checks to `medium` because things have
>> evolved since 2015. The details for their inclusion are in the
>> docstrings.
>>
>> As to `high`, those 3 checks ideally should be included in `medium`
>
> I'm still questioning how can this be TRT.  Please remember that
> 'medium' in Emacs really means 'minimum', because 'low' has no
> security checks at all.  How can it make sense to have _all_ the
> checks on the _minimum_ level?  (I say "all" because you clearly think
> 'high' and 'paranoid' should be removed, and their checks, those which
> make sense, moved into 'medium'.)
>

No, `low` verifies the certificate. That's always been the case, its
just on master, they are separate from the protocol checks. In my
branch, I have broken up the giant and separate
`nsm-check-certificate` function and reimplemented it as 2 check
functions in `nsm-tls-checks`. There's no distinction between
certificate checks and protocol checks anymore, whatever that means
originally. A check for a TLS connection is just that, a TLS check. As
such, `medium` is not minimum, `medium` means default, i.e. verifies
the cert + checking for unsafe TLS extensions and cipher suites.
`high` is `low` + `medium` + checking for more unsafe cipher suites
that are still widely deployed but warning you under most
circumstances may produce excessive nagging (It's getting very rare
these days tho, due to Google and Mozilla flexing their muscles, so to
speak).

> Suppose I work in Emacs on an internal secure network that is
> physically disconnected from the Internet (many enterprises, including
> my daytime job, have such stand-alone networks as a matter of
> routine).  Why would I need all the checks you propose on such a
> network?  OTOH, I don't want to go to 'low' (i.e. 'none') on such
> networks, because who knows what viri and other calamities can be once
> in a blue moon present on some of the machines on that network.
>

The answer to this question very much depends on how this intranet is
setup to mirror the most current best practices for the wider
internet. If they are close, as they should be, all you have to do is
give your org's CA PEM file to `gnutls-trustfiles` and you are all
set. If your org only relies on a physical separation, and does not
deploy TLS internally, your connections either go through
`nsm-check-plain-connection` in the case of SMTP/POP/IMAP, which does
nothing unless a previous connection to your internal email server was
done in a TLS connection, or not go through NSM at all. For anything
between these 2 extremes, you can easily adjust the checks in the new
defcustom that is `nsm-tls-checks`, which allows you to insert and
delete individual cons' in the alist in Customize. Expanding the
network security section in the manual to cover what these checks are
and how to adjust them should help users in these orgs figure out what
to do.

> Same questions regarding a home network, separated from the outside
> world by a firewall.
>
> Why shouldn't Emacs cater to such use cases?
>

Do you run your own CA and TLS servers at home? Do you use Google at
home? If you answer no and yes, then the list of checks in my branch
is designed specifically for you.

> On the other end, there are legitimate use cases where users might
> need to access sites and servers known in advance to be dangerous.
> Why shouldn't Emacs provide a 'paranoid' set of settings for such use
> cases?
>

If they know a site might be dangerous a priori and still decide to
visit it, may be The Emacs Way is to treat them like adults?

> The RFCs you cite and the vulnerabilities they describe should IMO be
> carefully analyzed, in the context of typical Emacs jobs that require
> network connections, and then we should grade them by their
> importance, divide them into 3 or 4 meaningful classes (a.k.a.
> "levels"), and let users change their settings in meaningful ways by
> changing the level.  Fine-grained settings should IMO also be
> provided, but they cannot be the only solution that we offer our
> users, precisely because not everyone has time to study each
> individual feature, but they normally will have time to read a
> description of 3 to 4 levels and decide which one is for them,
> especially if we describe them in terms that are related to the
> general environment rather than to specific vulnerabilities, similar
> to how many laptops ask you to select whether the new connection is
> for "home network", "enterprise", or "public network" -- that's
> something that every user can normally answer.
>

I think it's good that you are trying to be thorough, but I think you
are over-complicating the situation here. The answer to these
situations can be found by doing what I call "The Google Test" -

Do you use Google on this network? If yes, you need the checks in my
branch. If no, adjust the checks in `nsm-tls-check` as you see fit.
Read the manual to find out how.

For weird enterprise networks, if you get a prompt, you can whitelist
the intranet site by typing a for always, and you don't get a prompt
the next time. I think this is a good balance between convenience and
safety. Lars' good ideas hold up very well here.

If a user wants more convenience, he can write a check function that
distinguishes these network types you speak of. Let the thousand
flowers bloom in the package ecosystem for these things. Emacs only
needs to provide some hooks and a nice interface for them, which is
NSM.

>> Having said that, NSM currenly may prompt you many times if there is
>> more than one security check failures, i.e. if your level is set to
>> `high` and the server such as Google's is load balancing TLS
>> connections with 2 or more certs with different fingerprints, and it's
>> using SHA1 signatures, you will get 3 prompts. I have streamlined all
>> of those in my branch so you only get prompted once for all the
>> problems found. That's **more** convenience and "more" safety. You can
>> have your cake and eat it too.
>
> These improvements are good (provided that they indeed work in
> practice -- I will have to try them), but IMO they are not enough.
> You assume each one of us has only one Emacs installation, with only
> one HOME directory where settings are saved.  But that is profoundly
> not true: people have Emacs installed on several machines, with HOME
> directories not necessarily shared.  Emacs developers might very well
> have several HOME directories on the same machine, for testing
> purposes (I certainly have such setups and use them all the time).

Tons of people already put their init files or the entire
`user-directory` in a git repo and share them across installations.
`nsm-settings-file` by default goes into your `user-directory`, they
can very well put it into a git repo.

> Last, but not least, "emacs -Q" will not save any settings nor use
> previously set ones.
>

Not true. The settings NSM saves do not go into your init file or
custom-file. They are by default saved in
user-directory/network-settings.data, and NSM will use the settings
saved there even during emacs -Q.

>
> If the 'paranoid' level doesn't do a useful job, it should be modified
> to do a useful job.  The decision whether we even need such a level
> should IMO be one we take _after_ classifying the vulnerabilities and
> their prevention measures, not before.  It is quite possible we will
> decide that we don't need such a level, but the fact it is not useful
> today doesn't mean it cannot be useful.
>

TBH, while `low` may be useful once in a blue moon for testing
purposes, I can't think of anything that can justify a `paranoid`
level that is not better served by unplugging your network card. But
do let me know if you can think of some.

>> For STARTTLS, if the server does not support TLS, you will have gotten
>> a prompt for using a plain connection already, so why the extra
>> prompt?
>
> Does what you say cover Emacs built without TLS support, for example?
>

If I understand the code in `network-stream-open-starttls` correctly,
you won't even be able to establish a connection if neither GnuTLS is
linked into Emacs nor a `starttls-command` is available.

>> Emacs is not (only) a browser, but that's a moot point
>> -----------------------------------------------------------------------
>> Emacs' use base is diverse. People not only browse the Web with it,
>> but read and reply to emails, browse newgroups, chat on
>> IRC/Jabber/Slack, push code to Github etc., all of which require the
>> network to be secured with TLS. While TLS is mostly used on the Web
>> because of HTTPS, SSL/TLS has been mandatory for Gmail for many years
>> now, Github also requires TLS for code push, and so do many chat
>> servers. The way Emacs has deployed TLS either has a fault or it
>> doesn't, it doesn't matter which protocol TLS is wrapping over.
>
> I don't see how your conclusion necessarily follows from the fact that
> most or all protocols we use are secured with TLS.

TLS is protocol agnostic protocol. If the way Emacs implements TLS has
a vuln, the vuln will show up for all connections for all protocols
when a user opens a network stream that requires TLS or STARTTLS.

> Isn't it true that
> some of the vulnerabilities are only or mainly specific to some
> protocols or even some classes of servers?

For the protocols TLS is wrapping, no. For servers, maybe. I'm quite
certain that a lot of schools have woefully outdated TLS settings for
SMTP/POP3/IMAP. For those types of servers, you may get a prompt from
NSM per the default settings. But then again, you can easily whitelist
the cert after visually verifying it. It's fire-and-forget, done once
over the lifetime of the network-settings.data file type of deal.
After that, NSM will protect you if you are served a different cert
identified by its public key ID when connecting to a host previously
visited. In such circumstances, you might be under an active MITM
attack, hence the warning prompt again. All of the checks in
`nsm-tls-checks` is there to prevent MITM, so if you are connecting to
a server that NSM considers unsafe due to outdated TLS settings,
giving you a warning is exactly the right thing to do as opposed to
silently ignoring the problem by relaxing the constraints.

> Is it really true that,
> say, fetching and sending email on the one side, browsing s Web page
> on the other, and chatting on the third, all bump into the same set of
> risks?  This is the kind of analysis I'd like to see before we make up
> our minds what should be in 'medium'.

Different application protocols contain different kinds of attack
vectors, that's true. But those application-specific security measures
are not the job of TLS. TLS stands for Transport Layer Security, it's
primary jobs are verifying the identity of the server you are
connecting to, ensuring the traffic to that server has not been
tempered and keeping the traffic confidential, that is to say, only
the client and the server can read the messages. TLS' primary function
is to prevent MITM attacks, which contains passive attacks such as
eave-dropping, or active attacks such as phising. Deploying TLS it's
only one of the many security measures for an application. In addition
to TLS, browser have Single-Origin-Policy, Content-Security-Policy,
HTTP-Strict-Transport-Security and a whole host of other techniques to
achieve defence-in-depth. Email clients typically employ spam-filters,
heuristics to detect phising emails, blocking Javascripts and loading
of tracking images. With that said, if we cannot secure the
communication channel, all hopes are lost as a lot of things the
attackers want by launching these application specific attacks are
easily obtainable by intercepting your connection.

>
> (Btw, is Github relevant to the issue at hand?  We access Git
> repositories by invoking Git, we don't access them from Emacs
> directly, AFAIK.)

There are all kinds of github integration packages on Melpa. I think
they tend to clone repos using HTTPS because it's permeable to
firewalls.

>
>> `gnutls-min-prime-bits` should be `nil` on Emacs 26.2
>
> As I already said, this will delay the release of Emacs 26.2 by many
> moons.  From my POV, doing so is not a good idea, as we already have
> quite a few non-trivial bugfixes on the emacs-26 branch, but if no one
> else is bothered, I'm fine with doing that.
>
> IOW, this is a project-management decision, not a security-related
> decision.
>

This only requires deleting 2 lines of comments and s/256/nil, and
perhaps say a few words in the docstring to let users know under what
circumstances should they be adjusting `gnutls-min-prime-bits`. All of
which takes 5 mins maximum. I guarantee you this will cause no problem
whatsoever. If a user has customized `gnutls-min-prime-bits`, changing
the default will have no visible effect to them. For those who
haven't, it's a small step towards having Emacs's network security
catching up to 2015. This is a super-low-hanging fruit. Users will
applaud you if you do this for Emacs 26.2.

>
> IMO this is a mistake, and I urge you to reconsider.  While there's no
> need to follow up each code change on a scratch branch with a suitable
> documentation change, I think we already have a lot of added turf to
> document, and having at least that well documented will go a long way
> towards the goal.  It could even make this discussion more efficient
> and more rational, since we would all be on the same page wrt the
> issues being discussed, even though not all of us are experts on these
> matters.
>

I'm beginning to think this is probably a good idea.

> Thanks again for working on this.

Thank you for your thoughtful responses!

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> Date: Fri, 6 Jul 2018 14:03:51 +0100
> Cc: rms@gnu.org, Lars Ingebrigtsen <larsi@gnus.org>, Paul Eggert <eggert@cs.ucla.edu>, 
> 	Emacs-Devel devel <emacs-devel@gnu.org>, "Perry E. Metzger" <perry@piermont.com>, 
> 	Robert Pluim <rpluim@gmail.com>
> 
> No, `low` verifies the certificate.

Thanks.  I was looking at nsm.el, so I guess I missed that.

Still, I'm asking whether it is appropriate to check only the
certificate.  Aren't there any other checks that would fit 'low'?

> > Suppose I work in Emacs on an internal secure network that is
> > physically disconnected from the Internet (many enterprises, including
> > my daytime job, have such stand-alone networks as a matter of
> > routine).  Why would I need all the checks you propose on such a
> > network?  OTOH, I don't want to go to 'low' (i.e. 'none') on such
> > networks, because who knows what viri and other calamities can be once
> > in a blue moon present on some of the machines on that network.
> >
> 
> The answer to this question very much depends on how this intranet is
> setup to mirror the most current best practices for the wider
> internet. If they are close, as they should be, all you have to do is
> give your org's CA PEM file to `gnutls-trustfiles` and you are all
> set.

I'm saying that it would be good to have a single setting in Emacs,
ideally one of the security levels, that I could use in such
environments, without being bothered about the details.

> > Same questions regarding a home network, separated from the outside
> > world by a firewall.
> >
> > Why shouldn't Emacs cater to such use cases?
> 
> Do you run your own CA and TLS servers at home? Do you use Google at
> home? If you answer no and yes, then the list of checks in my branch
> is designed specifically for you.

Sorry, I don't understand what that means in practice.  Are you saying
that on your branch Emacs doesn't by default distinguish between such
home networks and public connections to Internet?  If so, I don't
think it's TRT.

> > On the other end, there are legitimate use cases where users might
> > need to access sites and servers known in advance to be dangerous.
> > Why shouldn't Emacs provide a 'paranoid' set of settings for such use
> > cases?
> 
> If they know a site might be dangerous a priori and still decide to
> visit it, may be The Emacs Way is to treat them like adults?

There could be legitimate use cases for that.  For example, testing
nsm.el ;-)

> I think it's good that you are trying to be thorough, but I think you
> are over-complicating the situation here.

I might agree with you, but not before we see the details of some of
these "complications".

> The answer to these
> situations can be found by doing what I call "The Google Test" -
> 
> Do you use Google on this network? If yes, you need the checks in my
> branch.

Can you explain how a single site can be used to decide on what checks
are appropriate?

> For weird enterprise networks, if you get a prompt, you can whitelist
> the intranet site by typing a for always, and you don't get a prompt
> the next time.

See, I'm getting these prompts from Firefox too frequently, and I'd
hate Emacs to do the same.  Even if these prompts are shown only once
for every such site.

> If a user wants more convenience, he can write a check function that
> distinguishes these network types you speak of. Let the thousand
> flowers bloom in the package ecosystem for these things. Emacs only
> needs to provide some hooks and a nice interface for them, which is
> NSM.

We are talking about the defaults, so let's not start about fancy
customizations.  Selecting a non-default security level should be the
only customization pertinent to this discussion.

> > Last, but not least, "emacs -Q" will not save any settings nor use
> > previously set ones.
> 
> Not true. The settings NSM saves do not go into your init file or
> custom-file. They are by default saved in
> user-directory/network-settings.data, and NSM will use the settings
> saved there even during emacs -Q.

Hmm... I would consider this a bug, as it means "emacs -Q" behaves
differently on different systems and with different users.

> TBH, while `low` may be useful once in a blue moon for testing
> purposes, I can't think of anything that can justify a `paranoid`
> level that is not better served by unplugging your network card. But
> do let me know if you can think of some.

Robert just did, see his post.

> >> For STARTTLS, if the server does not support TLS, you will have gotten
> >> a prompt for using a plain connection already, so why the extra
> >> prompt?
> >
> > Does what you say cover Emacs built without TLS support, for example?
> >
> 
> If I understand the code in `network-stream-open-starttls` correctly,
> you won't even be able to establish a connection if neither GnuTLS is
> linked into Emacs nor a `starttls-command` is available.

So we prompt for a plain connection when TLS is available, but
unconditionally fail it when TLS isn't available?  Does that make
sense?

> > I don't see how your conclusion necessarily follows from the fact that
> > most or all protocols we use are secured with TLS.
> 
> TLS is protocol agnostic protocol. If the way Emacs implements TLS has
> a vuln, the vuln will show up for all connections for all protocols
> when a user opens a network stream that requires TLS or STARTTLS.

TLS is protocol agnostic, but vulnerabilities aren't, right?  I mean,
some of the vulnerabilities are more likely (or even only) met when
using TLS with some protocols and not with others, right?

> > Isn't it true that
> > some of the vulnerabilities are only or mainly specific to some
> > protocols or even some classes of servers?
> 
> For the protocols TLS is wrapping, no. For servers, maybe. I'm quite
> certain that a lot of schools have woefully outdated TLS settings for
> SMTP/POP3/IMAP. For those types of servers, you may get a prompt from
> NSM per the default settings. But then again, you can easily whitelist
> the cert after visually verifying it. It's fire-and-forget, done once
> over the lifetime of the network-settings.data file type of deal.
> After that, NSM will protect you if you are served a different cert
> identified by its public key ID when connecting to a host previously
> visited.

That might be "good enough", but I'm still not convinced that we
cannot do better by default.

> In such circumstances, you might be under an active MITM attack,
> hence the warning prompt again.

Yes, I might, but is it reasonable to have the defaults assume
_everyone_ is _always_ under such an attack?  I don't think so.

> > Is it really true that,
> > say, fetching and sending email on the one side, browsing s Web page
> > on the other, and chatting on the third, all bump into the same set of
> > risks?  This is the kind of analysis I'd like to see before we make up
> > our minds what should be in 'medium'.
> 
> Different application protocols contain different kinds of attack
> vectors, that's true. But those application-specific security measures
> are not the job of TLS.

The NSM is not only about TLS, it's about any network connection Emacs
establishes.  The security levels should not be only about TLS.

> > (Btw, is Github relevant to the issue at hand?  We access Git
> > repositories by invoking Git, we don't access them from Emacs
> > directly, AFAIK.)
> 
> There are all kinds of github integration packages on Melpa. I think
> they tend to clone repos using HTTPS because it's permeable to
> firewalls.

I'd be surprised if any of those packages used HTTPS to access Git
repositories.  They'd have to reinvent Git.

> > As I already said, this will delay the release of Emacs 26.2 by many
> > moons.  From my POV, doing so is not a good idea, as we already have
> > quite a few non-trivial bugfixes on the emacs-26 branch, but if no one
> > else is bothered, I'm fine with doing that.
> >
> > IOW, this is a project-management decision, not a security-related
> > decision.
> 
> This only requires deleting 2 lines of comments and s/256/nil, and
> perhaps say a few words in the docstring to let users know under what
> circumstances should they be adjusting `gnutls-min-prime-bits`.

I didn't say the change is complex.  What bothers me is entirely
different effects this change could have.

> I guarantee you this will cause no problem whatsoever.

Sorry, I cannot accept such guarantees.  I have too much gray hair.

> Users will applaud you if you do this for Emacs 26.2.

Been there, done that, can show the scars.

> > IMO this is a mistake, and I urge you to reconsider.  While there's no
> > need to follow up each code change on a scratch branch with a suitable
> > documentation change, I think we already have a lot of added turf to
> > document, and having at least that well documented will go a long way
> > towards the goal.  It could even make this discussion more efficient
> > and more rational, since we would all be on the same page wrt the
> > issues being discussed, even though not all of us are experts on these
> > matters.
> >
> 
> I'm beginning to think this is probably a good idea.

Thanks in advance.

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

>
> Still, I'm asking whether it is appropriate to check only the
> certificate.  Aren't there any other checks that would fit 'low'?
>

Been waiting for you to say that :)

In https://github.com/wyuenho/emacs/commit/35d720eceef5c9b1dc0553b7d2235bbb079b0036
, I've used Snowden as an epoch, and separated the checks known to be
necessary before Snowden, the response post-Snowden, and preparations
standard bodies and browser vendors do to prepare for TLS 1.3. The
count is now 10 lows, 13 mediums (10 low + 3), and 17 highs (13
mediums + 4).

>> > Suppose I work in Emacs on an internal secure network that is
>> > physically disconnected from the Internet (many enterprises, including
>> > my daytime job, have such stand-alone networks as a matter of
>> > routine).  Why would I need all the checks you propose on such a
>> > network?  OTOH, I don't want to go to 'low' (i.e. 'none') on such
>> > networks, because who knows what viri and other calamities can be once
>> > in a blue moon present on some of the machines on that network.
>> >
>>
>> The answer to this question very much depends on how this intranet is
>> setup to mirror the most current best practices for the wider
>> internet. If they are close, as they should be, all you have to do is
>> give your org's CA PEM file to `gnutls-trustfiles` and you are all
>> set.
>
> I'm saying that it would be good to have a single setting in Emacs,
> ideally one of the security levels, that I could use in such
> environments, without being bothered about the details.
>
>> > Same questions regarding a home network, separated from the outside
>> > world by a firewall.
>> >
>> > Why shouldn't Emacs cater to such use cases?
>>
>> Do you run your own CA and TLS servers at home? Do you use Google at
>> home? If you answer no and yes, then the list of checks in my branch
>> is designed specifically for you.
>
> Sorry, I don't understand what that means in practice.  Are you saying
> that on your branch Emacs doesn't by default distinguish between such
> home networks and public connections to Internet?  If so, I don't
> think it's TRT.
>

Alright... I cave. I see what you want now, you want an escape hatch
for implicitly trusted network hosts. I'll make you a deal, if you can
give me cross-platform C DEFUNs of getifaddr(3), getaddrinfo(3) and
getnameinfo(3), I'll give you a `nsm-trust-local-network` boolean. If
`nsm-trust-local-network` is non-nil, or a function that returns
non-nil when `nsm-trust-local-network` is read, connecting to such
hosts via TLS will be whitelisted automatically in memory. The
docstring should say use this at your own risk. This should smooth out
your home network situations, and like-wise for corporate intranets.

>> If I understand the code in `network-stream-open-starttls` correctly,
>> you won't even be able to establish a connection if neither GnuTLS is
>> linked into Emacs nor a `starttls-command` is available.
>
> So we prompt for a plain connection when TLS is available, but
> unconditionally fail it when TLS isn't available?  Does that make
> sense?
>

You only land on the `network-stream-open-starttls` code path when you
request :type 'starttls, I think this makes sense. This also is the
approach recommended by RFC 2595, 3207 and 7425. The only protocols in
Emacs that request STARTTLS, AFAIK, is IMAP, SMTP, POP3 and NNIP. I'm
not sure if there are defcustoms in these packages that decides
whether to terminate the connection if STARTTLS is not possible.
Regardless, RFC 8314, fresh out of the oven in Jan this year demands
Email related protocols to require TLS implicitly. STARTTLS will soon
be obsolete anyway.

> TLS is protocol agnostic, but vulnerabilities aren't, right?  I mean,
> some of the vulnerabilities are more likely (or even only) met when
> using TLS with some protocols and not with others, right?
>

Most of the CAPITAL LETTER cute name vulns you can Google are targeted
towards TLS, but demostrated with HTTP, but that doesn't mean their
effects only are only limited to HTTPS. They are simply demostrated
with HTTP so people can get a better sense of their severity as it's
the most well-known protocol out there. The only instance of a cross
protocol attack that only targets a specific application protocol that
I'm aware of is an instance of CRIME called BREACH, of which there's
no known effective countermeasure.

There are however, plenty of implementation-specific vulns that do not
apply to Emacs and GnuTLS. You may have heard of them. (*cough*
Heartbleed *cough* gotofail *cough*)

None of the checks I've thrown in are mitigations for OpenSSL
implementation faults of targeted towards specific application
protocols. They apply to ALL TLS connections.

>
>> In such circumstances, you might be under an active MITM attack,
>> hence the warning prompt again.
>
> Yes, I might, but is it reasonable to have the defaults assume
> _everyone_ is _always_ under such an attack?  I don't think so.
>

I said you *might be*, and that's what the warning is about. Emacs
can't decide for the user under such circumstances. No one ever said
anything about assuming everyone is always under attack, we are saying
user are exposed to these attacks, if you don't have these checks.
These attacks may or may not be happening when you connect to a
server, but you can certainly detect them or prevent them by using a
combination of automated checks and human intervention.

>
> The NSM is not only about TLS, it's about any network connection Emacs
> establishes.  The security levels should not be only about TLS.
>

But it is only about TLS. Do you really want Emacs to prompt you when
you are browsing http://www.some-random-guy.com/blog ? Browsers can do
with a green padlock, the best Emacs can do is bleep out a message in
the echo area or put a Unicode padlock in the mode line. But this is
too application specific, it's best done in EWW or whatever.

>
> I'd be surprised if any of those packages used HTTPS to access Git
> repositories.  They'd have to reinvent Git.
>

They use Github's RESTful API to login, and clone the repo with
`shell-command`. You can file issues and submit PRs on Github using
Emacs too.

>
> I didn't say the change is complex.  What bothers me is entirely
> different effects this change could have.
>
>> I guarantee you this will cause no problem whatsoever.
>
> Sorry, I cannot accept such guarantees.  I have too much gray hair.
>
>> Users will applaud you if you do this for Emacs 26.2.
>
> Been there, done that, can show the scars.
>

Oh ye faithful disciple of the religion of Murphy's Law, may your hair
show youthful color again by changing Emacs' release process to a
Continuous Integration and Delivery process.

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> Date: Fri, 6 Jul 2018 22:24:51 +0100
> Cc: rms@gnu.org, Lars Ingebrigtsen <larsi@gnus.org>, Paul Eggert <eggert@cs.ucla.edu>, 
> 	Emacs-Devel devel <emacs-devel@gnu.org>, "Perry E. Metzger" <perry@piermont.com>, 
> 	Robert Pluim <rpluim@gmail.com>
> 
> > Still, I'm asking whether it is appropriate to check only the
> > certificate.  Aren't there any other checks that would fit 'low'?
> >
> 
> Been waiting for you to say that :)
> 
> In https://github.com/wyuenho/emacs/commit/35d720eceef5c9b1dc0553b7d2235bbb079b0036
> , I've used Snowden as an epoch, and separated the checks known to be
> necessary before Snowden, the response post-Snowden, and preparations
> standard bodies and browser vendors do to prepare for TLS 1.3. The
> count is now 10 lows, 13 mediums (10 low + 3), and 17 highs (13
> mediums + 4).

Thanks, I think this is a good change.

> Alright... I cave. I see what you want now, you want an escape hatch
> for implicitly trusted network hosts. I'll make you a deal, if you can
> give me cross-platform C DEFUNs of getifaddr(3), getaddrinfo(3) and
> getnameinfo(3), I'll give you a `nsm-trust-local-network` boolean. If
> `nsm-trust-local-network` is non-nil, or a function that returns
> non-nil when `nsm-trust-local-network` is read, connecting to such
> hosts via TLS will be whitelisted automatically in memory. The
> docstring should say use this at your own risk. This should smooth out
> your home network situations, and like-wise for corporate intranets.

Do network-interface-list and/or network-interface-info fit the bill?
If not, what's missing?

Thanks for the other points, I will have to dwell on them before I
make up my mind.

> Oh ye faithful disciple of the religion of Murphy's Law, may your hair
> show youthful color again by changing Emacs' release process to a
> Continuous Integration and Delivery process.

Hear, hear!

Re: A couple of questions and concerns about Emacs network security

[Lars Ingebrigtsen]

Geez!  So many emails in this thread all of a sudden...

I think it sounds like Jimmy is very much on the right track, so that's
great.  (I haven't actually looked at the code yet.)  Batching up the
warnings so you don't get double-prompting sounds very nice, for
instance, and handling the certificate things and the encryption
primitives warnings in "one batch" sounds good.

But here's some comments after reading all the 5000 messages in this
thread:

1) I don't think the `paranoid' setting is security theatre.  It's not a
useful setting for general browsing, but if your use case is that you
only use Emacs for, say, talking with your IMAP server, and that's it,
and you're worried that you may somehow end up talking with the wrong
server, and you're, er, paranoid (perhaps with good reason), then
that's the setting for you.

But, yes, as Eli says, `paranoid' should perhaps do more for non-TLS
connections.  The question is "what", though, because there's no
fingerprint (beyond the host/port number) that we can use to verify
that a non-TLS connection is to a previously seen host.

2) The `gnutls-min-prime-bits' documentation is unclear:

---

 This function sets the number of bits, for use in a Diffie-Hellman
 key exchange. This is used both in DH ephemeral and DH anonymous
 cipher suites. This will set the minimum size of the prime that will
 be used for the handshake.

 In the client side it sets the minimum accepted number of bits.

---

I thought that it set the minimum number of bits (like it says in the
last sentence), but it would use however many bits the server allows.
The first sentence seems to contradict this, and that this sets an
upper as well as lower bound on the number of bits, which is pretty
horrific, if that's the case...  But I don't think it is, because
I get ":diffie-hellman-prime-bits 2047" when connecting to a DH host.

So there's no need to worry about the `gnutls-min-prime-bits'
setting.  The NSM handles the problem.

3) emacs -Q should ignore the NSM settings (and not save anything)

Other than that, I'm just waiting for Jimmy's code to show up in an
Emacs branch, and I'll probably have more comments.

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

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

>
> 1) I don't think the `paranoid' setting is security theatre.  It's not a
> useful setting for general browsing, but if your use case is that you
> only use Emacs for, say, talking with your IMAP server, and that's it,
> and you're worried that you may somehow end up talking with the wrong
> server, and you're, er, paranoid (perhaps with good reason), then
> that's the setting for you.
>

I still haven't heard of a "good reason" yet. If the checks are
complete on the 'high level (i.e. checks for all known problems,
including checking your cert for revocations with OCSP+CT+CRL, use of
interceptable static RSA key exchange...), it would require some sort
of zero-day to forge a cert. Honestly if you are in that kind of
hostile environment, using Emacs to check your email directly without
connecting to a VPN first is an absolutely horrible idea. If you are
in that kind of environment, you would know it.

> But, yes, as Eli says, `paranoid' should perhaps do more for non-TLS
> connections.  The question is "what", though, because there's no
> fingerprint (beyond the host/port number) that we can use to verify
> that a non-TLS connection is to a previously seen host.
>

Exactly. NSM can only warn you if you are establishing a cleartext
connection, nothing else can be done.

>
> I thought that it set the minimum number of bits (like it says in the
> last sentence), but it would use however many bits the server allows.
> The first sentence seems to contradict this, and that this sets an
> upper as well as lower bound on the number of bits, which is pretty
> horrific, if that's the case...  But I don't think it is, because
> I get ":diffie-hellman-prime-bits 2047" when connecting to a DH host.
>

That's true, but there's still no reason to default
`gnutls-min-prime-bits` to 256. If that's the default, presumably
checking for DH prime bits > 1024 is a bug as NSM should let 256-bit
DH prime go through.

BTW, this bahavior pretty much we can default `gnutls-min-prime-bits`
to nil with no problem at all as we haven't seen any bug complaining
about NSM checking for DH prime bits > 1024 being too strict.

I would suggest we move the defcustom groups of all GnuTLS options to
NSM again to avoid further confusion.

Re: A couple of questions and concerns about Emacs network security

[Lars Ingebrigtsen]

Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:

> I still haven't heard of a "good reason" yet.

It's been stated in this thread that somebody uses it and finds it
useful, and I think that's sufficient.

>> But, yes, as Eli says, `paranoid' should perhaps do more for non-TLS
>> connections.  The question is "what", though, because there's no
>> fingerprint (beyond the host/port number) that we can use to verify
>> that a non-TLS connection is to a previously seen host.
>
> Exactly. NSM can only warn you if you are establishing a cleartext
> connection, nothing else can be done.

Well...  It could just do the host/port number thing and say "you've
never connected to this host before".  It's not much (considering how
easy it is to spoof DNS), but it's not nothing either.

> That's true, but there's still no reason to default
> `gnutls-min-prime-bits` to 256. If that's the default, presumably
> checking for DH prime bits > 1024 is a bug as NSM should let 256-bit
> DH prime go through.

No?  We let gnutls always establish the connection, no matter how sucky,
and then we ask the user about it.  That's the whole idea behind the
NSM.

And setting gnutls-min-prime-bits to 256 has no adverse effects, since
(contrary to what you've said several times in this thread), the TLS
connection will use as many prime bits that the server offers,
apparently.

> BTW, this bahavior pretty much we can default `gnutls-min-prime-bits`
> to nil with no problem at all as we haven't seen any bug complaining
> about NSM checking for DH prime bits > 1024 being too strict.

I don't think we would get a bug report for that.  People deal with
"broken" web site TLS all the time, and there'll be an abundance of them
over the next years.  That's what the NSM is for, and that's not
something users will complain about.

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

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

On Sun, Jul 8, 2018 at 4:13 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
> Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:
>
> > I still haven't heard of a "good reason" yet.
>
> It's been stated in this thread that somebody uses it and finds it
> useful, and I think that's sufficient.
>

Anybody will find anything useful, that's not a sufficient reason to
throw everything into Emacs, especially when it comes to security.

Finding it "useful" without any reason it's like saying oh this
theatrics makes me feel safer. But are you really? I would remind you
about "security fatigue" again.

Also, for people who are not well-education in security matters,
`paranoid gives them a false sense of security, where in fact it does
nothing more than checking if you've visiting a site before. Why would
having visited a site before make me safer? Allow me to quote myself:

"Why is attempting to securely connect to a server by using a
protocol that will authenticate it a cause for concern? Connecting to
a server via TLS does not mean the user start transmitting
confidential data immediately. That act  comes when you sign up or log
in. That's not TLS's job.

For STARTTLS, if the server does not support TLS, you will have gotten
a prompt for using a plain connection already, so why the extra
prompt? Does it not give the user a false sense of more security? Will
it mislead some innocent user to belive every host can be trusted
under `paranoid` level? If the answer to the last 2 questions were yes, I
believe removing `paranoid` and its check is the right thing to do,
even if only for the sake of giving the right expectation."

Offering an extra paranoid level cause more misunderstanding than
anything else. Bad UI is also a major cause of insecurity. You can
take it from a guy who used to work on the front-end at Cloudflare.

> > That's true, but there's still no reason to default
> > `gnutls-min-prime-bits` to 256. If that's the default, presumably
> > checking for DH prime bits > 1024 is a bug as NSM should let 256-bit
> > DH prime go through.
>
> No?  We let gnutls always establish the connection, no matter how sucky,
> and then we ask the user about it.  That's the whole idea behind the
> NSM.
>

No we don't let GnuTLS always establish the connection. We don't set
the priority string to the lowest level possible, i.e. "LEGACY". Are
you suggesting you want to do that?
The precedence has been set that we don't allow every GnuTLS
connection to go through, therefore, your ideal with letting NSM
handle all kinds of network security issues in Emacs is invalid.

> And setting gnutls-min-prime-bits to 256 has no adverse effects, since
> (contrary to what you've said several times in this thread), the TLS
> connection will use as many prime bits that the server offers,
> apparently.
>

The adverse effect is, there is no way to explain this clearly to a
user WTF is going on without confusing the hack out of people. The
choice option with a "Default" :tag in the defcustom already says nil
is the default, just the standard value isn't. This is already a
contradiction.

Think about this: If I'm connecting to a server that will only offer
256-bit prime, and I've set `gnutls-min-prime-bits` to 256, min means
lower bound, what exactly do I mean?

Setting `gnutls-min-prime-bits` to 256 as the standard value suggests
to me that Emacs' network security level is so relaxed that a TLS
connection with a DH prime 256-bits should go through, but in reality
NSM still warns. This yet again contradicts the intention of the
standard value. If the intention is to warn about prime-bit < 1024
bits, `gnutls-min-prime-bits` should not be 256, otherwise NSM should
not warn.

Just switch it back to `nil` and let GnuTLS do the right thing
according to the priority string for crying out loud. This also has no
adverse effect.

I don't know why I have to keep arguing this issue. The right decision
is clear as day. There is absolutely no reason to set it to 256 by
default in 2018. According to SSLLab's SSLPulse report, there's
exactly 0 server demanding DH < 512 bits. If you absolutely need DH <
512 bits due to some weird corporate network setup, there will be a
new knob called `nsm-trust-local-network`. Otherwise you can set it to
256 manually. Defaulting it to 256 was never a good idea.

If you are thinking about renaming the "Default" tag in
`gnutls-min-prime-bits` 's defcustom, don't. I will start doubting
whether you are doing this under good faith.

Please do not make figuring out how to tune Emacs' network security
setting more confusing than it is already.

>
> I don't think we would get a bug report for that.  People deal with
> "broken" web site TLS all the time, and there'll be an abundance of them
> over the next years.  That's what the NSM is for, and that's not
> something users will complain about.
>

Assuming people understand what the hell NSM is doing. Given the
Reddit thread and this thread, do you think people understand? One of
the goals when designing NSM should be to warning only when it's
appropriate to avoid security fatigue. No more, no less. That doesn't
sound like what you have in mind.

Re: A couple of questions and concerns about Emacs network security

[Paul Eggert]

Jimmy Yuen Ho Wong wrote:
> If you are thinking about renaming the "Default" tag in
> `gnutls-min-prime-bits` 's defcustom, don't. I will start doubting
> whether you are doing this under good faith

There's no need to be using ad hominem language like that. Assume that we are 
miscommunicating, as this is the obvious and most likely explanation for the 
behavior you're observing. Indulging in attacks will make your efforts less 
likely to succeed.

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

On Sun, Jul 8, 2018 at 6:06 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
>
> Jimmy Yuen Ho Wong wrote:
> > If you are thinking about renaming the "Default" tag in
> > `gnutls-min-prime-bits` 's defcustom, don't. I will start doubting
> > whether you are doing this under good faith
>
> There's no need to be using ad hominem language like that. Assume that we are
> miscommunicating, as this is the obvious and most likely explanation for the
> behavior you're observing. Indulging in attacks will make your efforts less
> likely to succeed.

I have been quite lenient to everyone as I'm trying to figure a lot of
things myself. But sometimes, when there's clearly no good reason to
do a something, but still insisting on doing it, especially when it
comes to security matters, you have to resolve to the last resort,
which is start doubting whether you are dealing with a friend or an
adversary.

I would urge a little less stubborness in changing some of the defaults.

If I've given the impression that setting `gnutls-min-prime-bits` to
256 will make the connection to use a 256 bit prime, I apologize. I
don't think I have done that since the very beginning of this thread,
but I haven't clarified myself enough, here's my sincere apology. I
only believe this is a UI issue, which may have some security
consequences.

The last thing I would suggest to Lars is, `gnutls-verify-error` will
effectively bypass NSM, so please don't pretend NSM is the be-all and
end-all layer for all matters related to Emacs' network security. It's
not, not until you consent to removing or changing some of the
standard values of the defcustoms in the 'gnutls group, or better yet.
Merge NSM and GnuTLS together, and rename some of the `gnutls group's
options. i.e. (define-obsolete-variable-alias 'gnutls-verify-error
'nsm-bypass' "27.1"). Better UI/UX/DX design is almost always more
preferrable than documentation.

Re: A couple of questions and concerns about Emacs network security

[Lars Ingebrigtsen]

Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:

> The last thing I would suggest to Lars is, `gnutls-verify-error` will
> effectively bypass NSM, so please don't pretend NSM is the be-all and
> end-all layer for all matters related to Emacs' network security. It's
> not, not until you consent to removing or changing some of the
> standard values of the defcustoms in the 'gnutls group, or better yet.
> Merge NSM and GnuTLS together, and rename some of the `gnutls group's
> options. i.e. (define-obsolete-variable-alias 'gnutls-verify-error
> 'nsm-bypass' "27.1"). Better UI/UX/DX design is almost always more
> preferrable than documentation.

Some people want these checks on the TLS level, and that's why those
checks exist.  It's perfectly reasonable for a user with a specific need
(for instance, to talk to a particularly ornery old private SSL 0.9
server) to use the gnutls functions and variables directly when
implementing their solution.

That's why these things are layered.  gnutls is a low-level library that
allows tweaking certain things about the connections it provides.

The NSM is a high-level user facing library.  Merging the two doesn't
seem to make much sense.

Both here and in other places in this thread you seem to fixate on the
particular use cases you're interested in to the extent that you say
that other use cases are wrong, somehow.  People have different needs
and different approaches, and Emacs should empower them to get their
work done, and not pressure them into doing it the way we think they
should do it.

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

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

>
> Some people want these checks on the TLS level, and that's why those
> checks exist.  It's perfectly reasonable for a user with a specific need
> (for instance, to talk to a particularly ornery old private SSL 0.9
> server) to use the gnutls functions and variables directly when
> implementing their solution.
>

It's not about what they want, but about what to give them so they can
accomplish what they want to do without getting confused by the
contradictary docs, and reading the source code. The pretense of NSM
taking care of all network security matters does not match the
reality. And from the sense I get, there's no intention to turn that
ideal into reality either. Nobody is talking about taking away
functionality here. You can remove/replace/rename/change things and
still provide equivalent functionality.

> That's why these things are layered.  gnutls is a low-level library that
> allows tweaking certain things about the connections it provides.
>
> The NSM is a high-level user facing library.  Merging the two doesn't
> seem to make much sense.
>
> Both here and in other places in this thread you seem to fixate on the
> particular use cases you're interested in to the extent that you say
> that other use cases are wrong, somehow.  People have different needs
> and different approaches, and Emacs should empower them to get their
> work done, and not pressure them into doing it the way we think they
> should do it.
>

We are talking about what should be the defaults here, as I've said in
that giant email a couple of days ago, you can have both reasonable
OTTB settings and freedom. If you haven't read it, I urge you to.

How about this, I'll be satisfied if we append :group 'nsm on the
gnutls defcustoms, so they show up on both the gnutls customize group
**and** nsm, and document in the docstrings the effects to NSM checks
if you mess with these GnuTLS settings? This doesn't sound too drastic
and saves users from having to dig around 2 different places or
resolve to trial and error to figure out there interactions.

Re: A couple of questions and concerns about Emacs network security

[Lars Ingebrigtsen]

Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:

> How about this, I'll be satisfied if we append :group 'nsm on the
> gnutls defcustoms, so they show up on both the gnutls customize group
> **and** nsm, and document in the docstrings the effects to NSM checks
> if you mess with these GnuTLS settings?

All the doc strings of the gnutls variables mention the NSM now.  (After
I remembered to push the changes to the emacs-26 branch that I wrote a
couple of weeks ago.  :-))

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

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

On Sun, Jul 8, 2018 at 8:30 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
> Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:
>
> > How about this, I'll be satisfied if we append :group 'nsm on the
> > gnutls defcustoms, so they show up on both the gnutls customize group
> > **and** nsm, and document in the docstrings the effects to NSM checks
> > if you mess with these GnuTLS settings?
>
> All the doc strings of the gnutls variables mention the NSM now.  (After
> I remembered to push the changes to the emacs-26 branch that I wrote a
> couple of weeks ago.  :-))
>

Nope, you are mistaken. Check again :)

Re: A couple of questions and concerns about Emacs network security

[Richard Stallman]

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

  > There's no need to be using ad hominem language like that. Assume that we are 
  > miscommunicating, as this is the obvious and most likely explanation for the 
  > behavior you're observing. Indulging in attacks will make your efforts less 
  > likely to succeed.

Thank you for reminding us of this.

I am sure everyone in this discussion sincerely wants Emacs to do the
best thing for users.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: A couple of questions and concerns about Emacs network security

[Lars Ingebrigtsen]

Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:

> No we don't let GnuTLS always establish the connection. We don't set
> the priority string to the lowest level possible, i.e. "LEGACY". Are
> you suggesting you want to do that?

That's my preference, but others don't agree.  And it's basically a moot
point, since there are virtually no (legitimate real-world) connections
that fall between the nil and "LEGACY" settings of
`gnutls-algorithm-priority'.

> Setting `gnutls-min-prime-bits` to 256 as the standard value suggests
> to me that Emacs' network security level is so relaxed that a TLS
> connection with a DH prime 256-bits should go through, but in reality
> NSM still warns. This yet again contradicts the intention of the
> standard value. If the intention is to warn about prime-bit < 1024
> bits, `gnutls-min-prime-bits` should not be 256, otherwise NSM should
> not warn.
>
> Just switch it back to `nil` and let GnuTLS do the right thing
> according to the priority string for crying out loud. This also has no
> adverse effect.

I don't understand what you're saying here.  We've chosen 256 since
that's the way to say "don't stop any connections on the gnutls level
because of this stuff".  nil currently means 1008 bits, if I read the
docs right.

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

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 08 Jul 2018 19:47:35 +0200
> Cc: Emacs-Devel devel <emacs-devel@gnu.org>
> 
> nil currently means 1008 bits, if I read the docs right.

Can you tell where in the docs you see this?

Also, isn't this GnuTLS version-dependent?

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

It is version dependent, it's buried deep in the NEW files.

https://gitlab.com/gnutls/gnutls/blob/master/NEWS
On Sun, Jul 8, 2018 at 7:11 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Lars Ingebrigtsen <larsi@gnus.org>
> > Date: Sun, 08 Jul 2018 19:47:35 +0200
> > Cc: Emacs-Devel devel <emacs-devel@gnu.org>
> >
> > nil currently means 1008 bits, if I read the docs right.
>
> Can you tell where in the docs you see this?
>
> Also, isn't this GnuTLS version-dependent?

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> Date: Sun, 8 Jul 2018 19:12:21 +0100
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Emacs-Devel devel <emacs-devel@gnu.org>
> 
> It is version dependent, it's buried deep in the NEW files.
> 
> https://gitlab.com/gnutls/gnutls/blob/master/NEWS

Thanks.  According to that, it's 1008 since GnuTLS 3.3.0.  Perhaps we
should tell that in the doc string of gnutls-min-prime-bits, or at
least in a comment there.

Re: A couple of questions and concerns about Emacs network security

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Thanks.  According to that, it's 1008 since GnuTLS 3.3.0.  Perhaps we
> should tell that in the doc string of gnutls-min-prime-bits, or at
> least in a comment there.

Yeah, but since it varies from GnuTLS release to release, we'd have to
keep updating it.  And not everybody is uses the same release, anyway,
so I think it's better just to not say anything.  Or just "what nil
means depends on the GnuTLS version".

Users aren't supposed to care about that variable, anyway, since the NSM
warns about less than 1024 bits...

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

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Jimmy Yuen Ho Wong <wyuenho@gmail.com>,  emacs-devel@gnu.org
> Date: Sun, 08 Jul 2018 20:39:30 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Thanks.  According to that, it's 1008 since GnuTLS 3.3.0.  Perhaps we
> > should tell that in the doc string of gnutls-min-prime-bits, or at
> > least in a comment there.
> 
> Yeah, but since it varies from GnuTLS release to release, we'd have to
> keep updating it.

Yes, that's unfortunate.  But if the value doesn't change too
frequently (as it seems, since 3.3.0 was what? 4 years ago?), maybe it
isn't a catastrophe.

> so I think it's better just to not say anything.  Or just "what nil
> means depends on the GnuTLS version".

Problem is, I cannot find this number in the GnuTLS documentation,
either.  Maybe I'm blind; but if not, it means our users have no
reasonable way of knowing how many bits they are using, and that is
not good, IMO.

> Users aren't supposed to care about that variable, anyway, since the NSM
> warns about less than 1024 bits...

Yes, but what if GnuTLS bumps the default to more than that?  And even
if not, I think I might like to know how far below 1024 I'm going to
be if I allow the connection.

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

> > so I think it's better just to not say anything.  Or just "what nil
> > means depends on the GnuTLS version".
>
> Problem is, I cannot find this number in the GnuTLS documentation,
> either.  Maybe I'm blind; but if not, it means our users have no
> reasonable way of knowing how many bits they are using, and that is
> not good, IMO.
>

It's not in the documentation, it's in the src/gnutls.c line
1834-1835. It's also in the docstring of `gnutls-min-prime-bits`.

> > Users aren't supposed to care about that variable, anyway, since the NSM
> > warns about less than 1024 bits...
>
> Yes, but what if GnuTLS bumps the default to more than that?  And even
> if not, I think I might like to know how far below 1024 I'm going to
> be if I allow the connection.

See my other email for a way out of this. Once you've caught
GNUTLS_E_DH_PRIME_UNACCEPTABLE, you can still call
gnutls_dh_get_prime_bits to get the prime bits the server sends back
out. I think this is already done, we just need to catch
GNUTLS_E_DH_PRIME_UNACCEPTABLE so gnutls_verify_boot doesn't
immediately return.

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> Date: Sun, 8 Jul 2018 20:22:54 +0100
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Emacs-Devel devel <emacs-devel@gnu.org>
> > Problem is, I cannot find this number in the GnuTLS documentation,
> > either.  Maybe I'm blind; but if not, it means our users have no
> > reasonable way of knowing how many bits they are using, and that is
> > not good, IMO.
> 
> It's not in the documentation, it's in the src/gnutls.c line
> 1834-1835. It's also in the docstring of `gnutls-min-prime-bits`.

Are you talking about the master branch of the Emacs repository?  If
so, I must be blind, because I don't see 1008 anywhere around those
places.

> > > Users aren't supposed to care about that variable, anyway, since the NSM
> > > warns about less than 1024 bits...
> >
> > Yes, but what if GnuTLS bumps the default to more than that?  And even
> > if not, I think I might like to know how far below 1024 I'm going to
> > be if I allow the connection.
> 
> See my other email for a way out of this. Once you've caught
> GNUTLS_E_DH_PRIME_UNACCEPTABLE, you can still call
> gnutls_dh_get_prime_bits to get the prime bits the server sends back
> out. I think this is already done, we just need to catch
> GNUTLS_E_DH_PRIME_UNACCEPTABLE so gnutls_verify_boot doesn't
> immediately return.

That's a separate issue, regarding your argument with Lars whether to
let NSM handle the too low bits or leave it to GnuTLS.  The issue I
raised was how can users know what is the GnuTLS default.  Because the
doc string of gnutls-min-prime-bits says:

  (defcustom gnutls-min-prime-bits 256
    ;; Several mail servers send fewer bits than the GnuTLS default.
    ;; Currently, 256 appears to be a reasonable choice (Bug#11267).
    "Minimum number of prime bits accepted by GnuTLS for key exchange.
  During a Diffie-Hellman handshake, if the server sends a prime
  number with fewer than this number of bits, the handshake is
  rejected.  \(The smaller the prime number, the less secure the
  key exchange is against man-in-the-middle attacks.)

  A value of nil says to use the default GnuTLS value."
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Which of course immediately begs the question "what is my GnuTLS's
default value?"

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

>
>   A value of nil says to use the default GnuTLS value."
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Which of course immediately begs the question "what is my GnuTLS's
> default value?"

That's what I've been saying all along. There are a couple of issues
we are discussing regarding setting the standard value of
`gnutls-min-prime-bits` to 256.

1. The standard value does not match the default value, when you say
it it's a default but not really OOTB, what exactly is the default?
2. Default nil doesn't tell the user what exactly is the GnuTLS
default either, that seems to be what you are wondering.
3. I've been trying to find a way where you don't need to care about
what the default is. My first attempt at surfacing the DH prime from a
failed handshake seems to have failed. The only other way I can think
of is set gnutls-min-prime-bits to 256 on the C side, and leave it to
nil in Lisp. This way its behavior is consistent with how we already
handles gnutls-algorithm-priority - we just hardcode a NORMAL in the C
side when unspecified. This way you don't have to explain anything.

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

On Mon, Jul 9, 2018 at 5:58 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> > Date: Sun, 8 Jul 2018 20:22:54 +0100
> > Cc: Lars Ingebrigtsen <larsi@gnus.org>, Emacs-Devel devel <emacs-devel@gnu.org>
> > > Problem is, I cannot find this number in the GnuTLS documentation,
> > > either.  Maybe I'm blind; but if not, it means our users have no
> > > reasonable way of knowing how many bits they are using, and that is
> > > not good, IMO.
> >
> > It's not in the documentation, it's in the src/gnutls.c line
> > 1834-1835. It's also in the docstring of `gnutls-min-prime-bits`.
>
> Are you talking about the master branch of the Emacs repository?  If
> so, I must be blind, because I don't see 1008 anywhere around those
> places.
>

No I was merely talking about what (setq gnutls-algorithm-priority nil) means.

https://github.com/emacs-mirror/emacs/blob/master/src/gnutls.c#L1835

The default is here:

https://github.com/emacs-mirror/emacs/blob/master/src/gnutls.c#L1606

> > > > Users aren't supposed to care about that variable, anyway, since the NSM
> > > > warns about less than 1024 bits...
> > >
> > > Yes, but what if GnuTLS bumps the default to more than that?  And even
> > > if not, I think I might like to know how far below 1024 I'm going to
> > > be if I allow the connection.
> >
> > See my other email for a way out of this. Once you've caught
> > GNUTLS_E_DH_PRIME_UNACCEPTABLE, you can still call
> > gnutls_dh_get_prime_bits to get the prime bits the server sends back
> > out. I think this is already done, we just need to catch
> > GNUTLS_E_DH_PRIME_UNACCEPTABLE so gnutls_verify_boot doesn't
> > immediately return.
>
> That's a separate issue, regarding your argument with Lars whether to
> let NSM handle the too low bits or leave it to GnuTLS.  The issue I
> raised was how can users know what is the GnuTLS default.  Because the
> doc string of gnutls-min-prime-bits says:
>
>   (defcustom gnutls-min-prime-bits 256
>     ;; Several mail servers send fewer bits than the GnuTLS default.
>     ;; Currently, 256 appears to be a reasonable choice (Bug#11267).
>     "Minimum number of prime bits accepted by GnuTLS for key exchange.
>   During a Diffie-Hellman handshake, if the server sends a prime
>   number with fewer than this number of bits, the handshake is
>   rejected.  \(The smaller the prime number, the less secure the
>   key exchange is against man-in-the-middle attacks.)
>
>   A value of nil says to use the default GnuTLS value."
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Which of course immediately begs the question "what is my GnuTLS's
> default value?"

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

On Mon, Jul 9, 2018 at 6:36 PM Jimmy Yuen Ho Wong <wyuenho@gmail.com> wrote:
>
> On Mon, Jul 9, 2018 at 5:58 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> > > Date: Sun, 8 Jul 2018 20:22:54 +0100
> > > Cc: Lars Ingebrigtsen <larsi@gnus.org>, Emacs-Devel devel <emacs-devel@gnu.org>
> > > > Problem is, I cannot find this number in the GnuTLS documentation,
> > > > either.  Maybe I'm blind; but if not, it means our users have no
> > > > reasonable way of knowing how many bits they are using, and that is
> > > > not good, IMO.
> > >
> > > It's not in the documentation, it's in the src/gnutls.c line
> > > 1834-1835. It's also in the docstring of `gnutls-min-prime-bits`.
> >
> > Are you talking about the master branch of the Emacs repository?  If
> > so, I must be blind, because I don't see 1008 anywhere around those
> > places.
> >
>
> No I was merely talking about what (setq gnutls-algorithm-priority nil) means.
>
> https://github.com/emacs-mirror/emacs/blob/master/src/gnutls.c#L1835
>
> The default is here:
>
> https://github.com/emacs-mirror/emacs/blob/master/src/gnutls.c#L1606
>

Ahhh the lines moved:

This is what (setq gnutls-min-prime-bits nil) means:

https://github.com/emacs-mirror/emacs/blob/master/src/gnutls.c#L1854


> > > > > Users aren't supposed to care about that variable, anyway, since the NSM
> > > > > warns about less than 1024 bits...
> > > >
> > > > Yes, but what if GnuTLS bumps the default to more than that?  And even
> > > > if not, I think I might like to know how far below 1024 I'm going to
> > > > be if I allow the connection.
> > >
> > > See my other email for a way out of this. Once you've caught
> > > GNUTLS_E_DH_PRIME_UNACCEPTABLE, you can still call
> > > gnutls_dh_get_prime_bits to get the prime bits the server sends back
> > > out. I think this is already done, we just need to catch
> > > GNUTLS_E_DH_PRIME_UNACCEPTABLE so gnutls_verify_boot doesn't
> > > immediately return.
> >
> > That's a separate issue, regarding your argument with Lars whether to
> > let NSM handle the too low bits or leave it to GnuTLS.  The issue I
> > raised was how can users know what is the GnuTLS default.  Because the
> > doc string of gnutls-min-prime-bits says:
> >
> >   (defcustom gnutls-min-prime-bits 256
> >     ;; Several mail servers send fewer bits than the GnuTLS default.
> >     ;; Currently, 256 appears to be a reasonable choice (Bug#11267).
> >     "Minimum number of prime bits accepted by GnuTLS for key exchange.
> >   During a Diffie-Hellman handshake, if the server sends a prime
> >   number with fewer than this number of bits, the handshake is
> >   rejected.  \(The smaller the prime number, the less secure the
> >   key exchange is against man-in-the-middle attacks.)
> >
> >   A value of nil says to use the default GnuTLS value."
> >   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > Which of course immediately begs the question "what is my GnuTLS's
> > default value?"

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> Date: Mon, 9 Jul 2018 18:38:14 +0100
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Emacs-Devel devel <emacs-devel@gnu.org>
> This is what (setq gnutls-min-prime-bits nil) means:
> 
> https://github.com/emacs-mirror/emacs/blob/master/src/gnutls.c#L1854

This still doesn't tell me what nil means:

  prime_bits            = Fplist_get (proplist, QCmin_prime_bits);
  [...]
  if (INTEGERP (prime_bits))
    gnutls_dh_set_prime_bits (state, XUINT (prime_bits));

If prime_bits is nil, we do nothing with it.  We only use it if it is
an integer.

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

On Mon, Jul 9, 2018 at 7:05 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> > Date: Mon, 9 Jul 2018 18:38:14 +0100
> > Cc: Lars Ingebrigtsen <larsi@gnus.org>, Emacs-Devel devel <emacs-devel@gnu.org>
> > This is what (setq gnutls-min-prime-bits nil) means:
> >
> > https://github.com/emacs-mirror/emacs/blob/master/src/gnutls.c#L1854
>
> This still doesn't tell me what nil means:
>
>   prime_bits            = Fplist_get (proplist, QCmin_prime_bits);
>   [...]
>   if (INTEGERP (prime_bits))
>     gnutls_dh_set_prime_bits (state, XUINT (prime_bits));
>
> If prime_bits is nil, we do nothing with it.  We only use it if it is
> an integer.

Yep. By not setting it from the Emacs's side, it means the DH prime
bits is controlled by the priority string, and GnuTLS will do the
right thing accordingly. It also means the min prime bit is GnuTLS
version dependent.

"Note that since 3.1.7 this function is deprecated. The minimum number
of bits is set by the priority string level. Also this function must
be called after gnutls_priority_set_direct() or the set value may be
overridden by the selected priority options."

https://www.gnutls.org/reference/gnutls-gnutls.html#gnutls-dh-set-prime-bits

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> Date: Mon, 9 Jul 2018 19:10:09 +0100
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Emacs-Devel devel <emacs-devel@gnu.org>
> 
> "Note that since 3.1.7 this function is deprecated. The minimum number
> of bits is set by the priority string level. Also this function must
> be called after gnutls_priority_set_direct() or the set value may be
> overridden by the selected priority options."

Granted, I saw that.  I have GnuTLS installed with its Info manual.
But the above still doesn't tell what is the default number of bits,
even if I go hunting for the description of the priority string.

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

On Mon, Jul 9, 2018 at 7:33 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> > Date: Mon, 9 Jul 2018 19:10:09 +0100
> > Cc: Lars Ingebrigtsen <larsi@gnus.org>, Emacs-Devel devel <emacs-devel@gnu.org>
> >
> > "Note that since 3.1.7 this function is deprecated. The minimum number
> > of bits is set by the priority string level. Also this function must
> > be called after gnutls_priority_set_direct() or the set value may be
> > overridden by the selected priority options."
>
> Granted, I saw that.  I have GnuTLS installed with its Info manual.
> But the above still doesn't tell what is the default number of bits,
> even if I go hunting for the description of the priority string.

I'm not sure of the significance of what you are trying to do, but if
you are trying to confirm the actual min prime bit, the file is here:

https://gitlab.com/gnutls/gnutls/blob/master/lib/algorithms/secparams.c

The second number is the DH min prime bits. Don't ask me which row is
the actual default... I don't want to know...

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> Date: Mon, 9 Jul 2018 19:47:23 +0100
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Emacs-Devel devel <emacs-devel@gnu.org>
> > > "Note that since 3.1.7 this function is deprecated. The minimum number
> > > of bits is set by the priority string level. Also this function must
> > > be called after gnutls_priority_set_direct() or the set value may be
> > > overridden by the selected priority options."
> >
> > Granted, I saw that.  I have GnuTLS installed with its Info manual.
> > But the above still doesn't tell what is the default number of bits,
> > even if I go hunting for the description of the priority string.
> 
> I'm not sure of the significance of what you are trying to do

I'm trying to find some evidence to the number of bits GnuTLS will use
by default.

> but if you are trying to confirm the actual min prime bit, the file
> is here:
> 
> https://gitlab.com/gnutls/gnutls/blob/master/lib/algorithms/secparams.c
> 
> The second number is the DH min prime bits. Don't ask me which row is
> the actual default... I don't want to know...

What you asked not to ask is, of course, what I'm after.  I guess the
answer is in gnutls_ui.c:

  void gnutls_dh_set_prime_bits(gnutls_session_t session, unsigned int bits)
  {
	  if (bits < gnutls_sec_param_to_pk_bits(GNUTLS_PK_DH, GNUTLS_SEC_PARAM_WEAK)
		  && bits != 0)
		  _gnutls_audit_log(session,
				    "Note that the security level of the Diffie-Hellman key exchange has been lowered to %u bits and this may allow decryption of the session data\n",
				    bits);
	  session->internals.priorities.dh_prime_bits = bits;
  }

This tells us that the default is GNUTLS_SEC_PARAM_WEAK, i.e. this:

        {"Weak", GNUTLS_SEC_PARAM_WEAK, 72, 1008, 1008, 160, 160}

IOW, indeed 1008 bits.

Thanks for pointing me in the right direction.

Re: A couple of questions and concerns about Emacs network security

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Users aren't supposed to care about that variable, anyway, since the NSM
>> warns about less than 1024 bits...
>
> Yes, but what if GnuTLS bumps the default to more than that?  And even
> if not, I think I might like to know how far below 1024 I'm going to
> be if I allow the connection.

The NSM will say explicitly how many bits the DH exchange is using.  Try
this one with `M-x eww'

https://dh480.badssl.com/

and you should get the warning.

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

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

On Sun, Jul 8, 2018 at 8:28 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> Users aren't supposed to care about that variable, anyway, since the NSM
> >> warns about less than 1024 bits...
> >
> > Yes, but what if GnuTLS bumps the default to more than that?  And even
> > if not, I think I might like to know how far below 1024 I'm going to
> > be if I allow the connection.
>
> The NSM will say explicitly how many bits the DH exchange is using.  Try
> this one with `M-x eww'
>
> https://dh480.badssl.com/
>
> and you should get the warning.
>

That's only because 480 > 256.  I think Eli wants to know the bit
length if we leave gnutls-min-prime-bits to nil. In my other emails
I've pointed out a way to do that.

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> Date: Sun, 8 Jul 2018 20:31:09 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, Emacs-Devel devel <emacs-devel@gnu.org>
> 
> I think Eli wants to know the bit length if we leave
> gnutls-min-prime-bits to nil.

Yes.

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: wyuenho@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 08 Jul 2018 21:28:20 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Users aren't supposed to care about that variable, anyway, since the NSM
> >> warns about less than 1024 bits...
> >
> > Yes, but what if GnuTLS bumps the default to more than that?  And even
> > if not, I think I might like to know how far below 1024 I'm going to
> > be if I allow the connection.
> 
> The NSM will say explicitly how many bits the DH exchange is using.  Try
> this one with `M-x eww'
> 
> https://dh480.badssl.com/
> 
> and you should get the warning.

The warning says

  The Diffie-Hellman prime bits (480) used for this connection to
  dh480.badssl.com:443 is less than what is considered safe (1024)

So it doesn't show the 1008 value.  What did I miss?

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

On Mon, Jul 9, 2018 at 6:02 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Lars Ingebrigtsen <larsi@gnus.org>
> > Cc: wyuenho@gmail.com,  emacs-devel@gnu.org
> > Date: Sun, 08 Jul 2018 21:28:20 +0200
> >
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> > >> Users aren't supposed to care about that variable, anyway, since the NSM
> > >> warns about less than 1024 bits...
> > >
> > > Yes, but what if GnuTLS bumps the default to more than that?  And even
> > > if not, I think I might like to know how far below 1024 I'm going to
> > > be if I allow the connection.
> >
> > The NSM will say explicitly how many bits the DH exchange is using.  Try
> > this one with `M-x eww'
> >
> > https://dh480.badssl.com/
> >
> > and you should get the warning.
>
> The warning says
>
>   The Diffie-Hellman prime bits (480) used for this connection to
>   dh480.badssl.com:443 is less than what is considered safe (1024)
>
> So it doesn't show the 1008 value.  What did I miss?

Nothing. The server you are connecting will only give you a 480-bit
prime. Since your Emacs is still using 256 `gnutls-min-prime-bit`,
GnuTLS lowered the lower bound from 1008 to 256, and then negotiate a
bit length as high as the server can go. What you see is expected.

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

>
> > Users aren't supposed to care about that variable, anyway, since the NSM
> > warns about less than 1024 bits...
>
> Yes, but what if GnuTLS bumps the default to more than that?  And even
> if not, I think I might like to know how far below 1024 I'm going to
> be if I allow the connection.

I've surfaced the DH_PRIME_UNACCEPTABLE error from the handshake to
the Lisp side here.
https://github.com/wyuenho/emacs/commit/6c00758175b227338005533b27999435b33528d5

I'm don't like this change to much. It's full of exceptions in the C
code, and you still can't get the prime bits the server sent over,
because gnutls_dh_get_prime_bits() only returns a prime bit if an
actual DH key exchange was done. Since the handshake failed early as
soon as the client found out the prime bits are too low, ciphers, mac
and all the rest were not negotiated, so they are all NULL. You do at
least get a warning that lets you know the prime bit is too low tho,
and you can still proceed with this connection tho, but it wouldn't be
very useful. Since the handshake failed, the result will be a plain
HTTP request to an HTTPS port, of which the server will typically
return with an HTTP 400.

Perhaps it's simply better to let the user know that they can (setq
gnutls-log-level 1) to log out the actual GnuTLS error message (which
is still just prime bits too low without specifying a number)

Re: A couple of questions and concerns about Emacs network security

[Robert Pluim]

Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:

>>
>> > Users aren't supposed to care about that variable, anyway, since the NSM
>> > warns about less than 1024 bits...
>>
>> Yes, but what if GnuTLS bumps the default to more than that?  And even
>> if not, I think I might like to know how far below 1024 I'm going to
>> be if I allow the connection.
>
> I've surfaced the DH_PRIME_UNACCEPTABLE error from the handshake to
> the Lisp side here.
> https://github.com/wyuenho/emacs/commit/6c00758175b227338005533b27999435b33528d5
>
> I'm don't like this change to much. It's full of exceptions in the C
> code, and you still can't get the prime bits the server sent over,
> because gnutls_dh_get_prime_bits() only returns a prime bit if an
> actual DH key exchange was done. Since the handshake failed early as
> soon as the client found out the prime bits are too low, ciphers, mac
> and all the rest were not negotiated, so they are all NULL. You do at
> least get a warning that lets you know the prime bit is too low tho,
> and you can still proceed with this connection tho, but it wouldn't be
> very useful. Since the handshake failed, the result will be a plain
> HTTP request to an HTTPS port, of which the server will typically
> return with an HTTP 400.

Iʼd much rather we hard fail the connection here than proceed without
TLS.

> Perhaps it's simply better to let the user know that they can (setq
> gnutls-log-level 1) to log out the actual GnuTLS error message (which
> is still just prime bits too low without specifying a number)

Yes, that sounds like a good idea.

Robert

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

On Sun, Jul 8, 2018 at 6:47 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
> Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:
>
> > No we don't let GnuTLS always establish the connection. We don't set
> > the priority string to the lowest level possible, i.e. "LEGACY". Are
> > you suggesting you want to do that?
>
> That's my preference, but others don't agree.  And it's basically a moot
> point, since there are virtually no (legitimate real-world) connections
> that fall between the nil and "LEGACY" settings of
> `gnutls-algorithm-priority'.
>

There is also no legitimate real-world connection that fall between
min-prime-bit 0 and 512-bits. In fact, exactly 0 top Alexa 150k site
demands 256 bit.
https://www.ssllabs.com/ssl-pulse/.

I'll reply to the problem with setting gnutls-algorithm-priority to
LEGACY in other email.

> > Setting `gnutls-min-prime-bits` to 256 as the standard value suggests
> > to me that Emacs' network security level is so relaxed that a TLS
> > connection with a DH prime 256-bits should go through, but in reality
> > NSM still warns. This yet again contradicts the intention of the
> > standard value. If the intention is to warn about prime-bit < 1024
> > bits, `gnutls-min-prime-bits` should not be 256, otherwise NSM should
> > not warn.
> >
> > Just switch it back to `nil` and let GnuTLS do the right thing
> > according to the priority string for crying out loud. This also has no
> > adverse effect.
>
> I don't understand what you're saying here.  We've chosen 256 since
> that's the way to say "don't stop any connections on the gnutls level
> because of this stuff".  nil currently means 1008 bits, if I read the
> docs right.
>

That is correct, for consistency's sake. Since we'e decided on a
default NORMAL:%DUMB_FW priority string, which means let the GnuTLS
version you've built Emacs with to decide what cipher suites to allow,
it follows that we should also default `gnutls-min-prime-bits` to nil,
which also lets GnuTLS decide.

Re: A couple of questions and concerns about Emacs network security

[Lars Ingebrigtsen]

Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:

> I'll reply to the problem with setting gnutls-algorithm-priority to
> LEGACY in other email.

Well, I'm not really advocating that.  It's a bit too much hubris.  :-)
Nobody's perfect, and the default NORMAL gnutls-algorithm-priority is
fine by me, even if it means a less-than-perfect UI and user experience.

> That is correct, for consistency's sake. Since we'e decided on a
> default NORMAL:%DUMB_FW priority string, which means let the GnuTLS
> version you've built Emacs with to decide what cipher suites to allow,
> it follows that we should also default `gnutls-min-prime-bits` to nil,
> which also lets GnuTLS decide.

We could, but we know that we handle that bit well on our own in the
NSM, so I don't see the point.  

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

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

On Sun, Jul 8, 2018 at 7:42 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
> Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:
>
> > I'll reply to the problem with setting gnutls-algorithm-priority to
> > LEGACY in other email.
>
> Well, I'm not really advocating that.  It's a bit too much hubris.  :-)
> Nobody's perfect, and the default NORMAL gnutls-algorithm-priority is
> fine by me, even if it means a less-than-perfect UI and user experience.
>

But you could advocate that, I don't object to that :). You can just
copy this bit of code[1] and do a few adjustments in the checks to
avoid too much nagging if the user specifically listed he wants RC4 to
be enabled.

https://www.gnutls.org/manual/gnutls.html#Listing-the-ciphersuites-in-a-priority-string

> > That is correct, for consistency's sake. Since we'e decided on a
> > default NORMAL:%DUMB_FW priority string, which means let the GnuTLS
> > version you've built Emacs with to decide what cipher suites to allow,
> > it follows that we should also default `gnutls-min-prime-bits` to nil,
> > which also lets GnuTLS decide.
>
> We could, but we know that we handle that bit well on our own in the
> NSM, so I don't see the point.
>

As I said, it's a UI issue. You are confusing people when what they
specify do not match expectation. When I specify a lower bound, that's
me saying I don't want NSM to nag me about it.

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> Date: Sun, 8 Jul 2018 17:56:03 +0100
> Cc: Emacs-Devel devel <emacs-devel@gnu.org>
> 
> > > That's true, but there's still no reason to default
> > > `gnutls-min-prime-bits` to 256. If that's the default, presumably
> > > checking for DH prime bits > 1024 is a bug as NSM should let 256-bit
> > > DH prime go through.
> >
> > No?  We let gnutls always establish the connection, no matter how sucky,
> > and then we ask the user about it.  That's the whole idea behind the
> > NSM.
> 
> No we don't let GnuTLS always establish the connection. We don't set
> the priority string to the lowest level possible, i.e. "LEGACY". Are
> you suggesting you want to do that?
> The precedence has been set that we don't allow every GnuTLS
> connection to go through, therefore, your ideal with letting NSM
> handle all kinds of network security issues in Emacs is invalid.
> 
> > And setting gnutls-min-prime-bits to 256 has no adverse effects, since
> > (contrary to what you've said several times in this thread), the TLS
> > connection will use as many prime bits that the server offers,
> > apparently.
> >
> 
> The adverse effect is, there is no way to explain this clearly to a
> user WTF is going on without confusing the hack out of people. The
> choice option with a "Default" :tag in the defcustom already says nil
> is the default, just the standard value isn't. This is already a
> contradiction.

But if we set the prime bits to a higher number, isn't it true that a
TLS connection will fail with little or no explanations?  Whereas the
NSM does provide a sensible description of the problem when it asks me
whether to go ahead with the insecure connection, so I could consider
how much I trust the server and/or the connection.

I don't know if I'm talking about the same situation, but I sometimes
get from Firefox a cryptic "secure connection failed" with some error
code mnemonics I don't understand; when that happens, it annoys me
quite a bit, because I have no easy way of figuring out whether the
problem is with the server, with my box, or with some fascist
firewall in the middle.

If this is what will happen when we bump the number of bits (or with
any other security setting), then I'd rather have NSM catch that and
talk to me in a language I can understand better.  At least as an
option, if not by default (and no, that option shouldn't be
gnutls-min-prime-bits, as that's too technical for most users; I'm
thinking about some non-default security level, perhaps).

Does that make sense?

> Just switch it back to `nil` and let GnuTLS do the right thing
> according to the priority string for crying out loud.

If you mean that people should customize the priority string, then I
think this is again too technical and shouldn't be the primary
solution we provide users for controlling their security level.

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

On Sun, Jul 8, 2018 at 6:53 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> > Date: Sun, 8 Jul 2018 17:56:03 +0100
> > Cc: Emacs-Devel devel <emacs-devel@gnu.org>
> >
> > > > That's true, but there's still no reason to default
> > > > `gnutls-min-prime-bits` to 256. If that's the default, presumably
> > > > checking for DH prime bits > 1024 is a bug as NSM should let 256-bit
> > > > DH prime go through.
> > >
> > > No?  We let gnutls always establish the connection, no matter how sucky,
> > > and then we ask the user about it.  That's the whole idea behind the
> > > NSM.
> >
> > No we don't let GnuTLS always establish the connection. We don't set
> > the priority string to the lowest level possible, i.e. "LEGACY". Are
> > you suggesting you want to do that?
> > The precedence has been set that we don't allow every GnuTLS
> > connection to go through, therefore, your ideal with letting NSM
> > handle all kinds of network security issues in Emacs is invalid.
> >
> > > And setting gnutls-min-prime-bits to 256 has no adverse effects, since
> > > (contrary to what you've said several times in this thread), the TLS
> > > connection will use as many prime bits that the server offers,
> > > apparently.
> > >
> >
> > The adverse effect is, there is no way to explain this clearly to a
> > user WTF is going on without confusing the hack out of people. The
> > choice option with a "Default" :tag in the defcustom already says nil
> > is the default, just the standard value isn't. This is already a
> > contradiction.
>
> But if we set the prime bits to a higher number, isn't it true that a
> TLS connection will fail with little or no explanations?  Whereas the
> NSM does provide a sensible description of the problem when it asks me
> whether to go ahead with the insecure connection, so I could consider
> how much I trust the server and/or the connection.
>
> I don't know if I'm talking about the same situation, but I sometimes
> get from Firefox a cryptic "secure connection failed" with some error
> code mnemonics I don't understand; when that happens, it annoys me
> quite a bit, because I have no easy way of figuring out whether the
> problem is with the server, with my box, or with some fascist
> firewall in the middle.
>
> If this is what will happen when we bump the number of bits (or with
> any other security setting), then I'd rather have NSM catch that and
> talk to me in a language I can understand better.  At least as an
> option, if not by default (and no, that option shouldn't be
> gnutls-min-prime-bits, as that's too technical for most users; I'm
> thinking about some non-default security level, perhaps).
>
> Does that make sense?
>
> > Just switch it back to `nil` and let GnuTLS do the right thing
> > according to the priority string for crying out loud.
>
> If you mean that people should customize the priority string, then I
> think this is again too technical and shouldn't be the primary
> solution we provide users for controlling their security level.

No, I'm saying don't override GnuTLS's defaults by default (geeez
that's a lot of defaults, hope that makes sense). If people want to
enable certain things the GnuTLS doesn't allow by default, they can
still do it by adjusting GnuTLS's priority string. The priority string
is GnuTLS's primary means for adjusting its feature set.

"The GnuTLS priority strings specify the TLS session’s handshake
algorithms and options in a compact, easy-to-use format. Thee strings
are intended as a user-specified override of the library defaults.

That is, we recommend applications using the default settings (c.f.
gnutls_set_default_priority), and provide the user with access to
priority strings for overriding the default behavior, on configuration
files, or other UI. Following such a principle, makes the GnuTLS
library as the default settings provider. That is necessary and a good
practice, because TLS protocol hardening and phasing out of legacy
algorithms, is easier to co-ordinate when happens in a single library.
"[1]

The way we use `gnutls-min-prime-bits` is also problematic, as the
docs suggests that it's been deprecated since 3.1.7. [2]

In order to throw the error back out to LISP to NSM to check when the
server presents a prime bit that's too low, we can catch the
GNUTLS_E_DH_PRIME_UNACCEPTABLE error. This is trivial judging from the
C code.

[1]: https://www.gnutls.org/manual/gnutls.html#Priority-Strings
[2]: https://www.gnutls.org/manual/gnutls.html#gnutls_005fdh_005fset_005fprime_005fbits

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 08 Jul 2018 16:06:39 +0200
> Cc: Emacs-Devel devel <emacs-devel@gnu.org>
> 
> But, yes, as Eli says, `paranoid' should perhaps do more for non-TLS
> connections.  The question is "what", though, because there's no
> fingerprint (beyond the host/port number) that we can use to verify
> that a non-TLS connection is to a previously seen host.

We could look at the browsers for inspiration, perhaps?

> 3) emacs -Q should ignore the NSM settings (and not save anything)

Agreed.

> Other than that, I'm just waiting for Jimmy's code to show up in an
> Emacs branch, and I'll probably have more comments.

Thanks.

Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

On Sun, Jul 8, 2018 at 3:55 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Lars Ingebrigtsen <larsi@gnus.org>
> > Date: Sun, 08 Jul 2018 16:06:39 +0200
> > Cc: Emacs-Devel devel <emacs-devel@gnu.org>
> >
> > But, yes, as Eli says, `paranoid' should perhaps do more for non-TLS
> > connections.  The question is "what", though, because there's no
> > fingerprint (beyond the host/port number) that we can use to verify
> > that a non-TLS connection is to a previously seen host.
>
> We could look at the browsers for inspiration, perhaps?
>

Browsers have only 1 security level, and shows a green padlock on the
address bar for HTTPS, and no padlock for cleartext connection.
There's no warning whatsoever. If you want to do the padlock think,
you might want to do it in EWW and all those Email/Newsgroup packages
instead of NSM.

Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> Date: Sun, 8 Jul 2018 15:58:45 +0100
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Emacs-Devel devel <emacs-devel@gnu.org>
> > > But, yes, as Eli says, `paranoid' should perhaps do more for non-TLS
> > > connections.  The question is "what", though, because there's no
> > > fingerprint (beyond the host/port number) that we can use to verify
> > > that a non-TLS connection is to a previously seen host.
> >
> > We could look at the browsers for inspiration, perhaps?
> 
> Browsers have only 1 security level

I meant for inspiration about what non-TLS checks can be relevant.
Whether they should be on 'paranoid' or lower is a separate question.

Re: A couple of questions and concerns about Emacs network security

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> But, yes, as Eli says, `paranoid' should perhaps do more for non-TLS
>> connections.  The question is "what", though, because there's no
>> fingerprint (beyond the host/port number) that we can use to verify
>> that a non-TLS connection is to a previously seen host.
>
> We could look at the browsers for inspiration, perhaps?

Hm...  I don't think I've seen any browsers offering anything like the
`paranoid' level, but I've only used the mainstream ones.  Perhaps
somebody else has experience with the high security forks of Firefox?
Or do I misremember?

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

Re: A couple of questions and concerns about Emacs network security

[Paul Eggert]

Richard Stallman wrote:
> OpenSSL had, in the past, a license incompatible with the GNU GPL.
> If its license is unchanged, using it with Emacs would require some
> inconvenient work to install a license exception.

The OpenSSL project announced in 2015 its intent to switch to the Apache 2.0 
license, which is compatible with the GPL v3 that Emacs uses. Switching involves 
contacting hundreds of contributors and getting their permission, and removing 
code contributed by the few who disagree. At last report in March 
<https://www.openssl.org/blog/blog/2018/03/01/last-license/> this process had 
covered 99.8% of commits to OpenSSL, and the intent was to make the license 
change in the next release, which has not happened yet. So although we're still 
not quite there yet as far as Emacs using OpenSSL on Debian goes, the licensing 
issue looks like it will be resolved in the not-too-distant future.

Re: A couple of questions and concerns about Emacs network security

[Richard Stallman]

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

We should wait for OpenSSL to actually change its license before we
start using it, but it looks like that won't be long.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)