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