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

[Jimmy Yuen Ho Wong]

On Sat, Jun 23, 2018 at 1:05 PM, Lars Ingebrigtsen <address@hidden> wrote:

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

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.