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

[Jimmy Yuen Ho Wong]

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 <address@hidden> wrote:

Jimmy Yuen Ho Wong <address@hidden> 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