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
>