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 <address@hidden> wrote:
> On Mon, 25 Jun 2018 19:33:49 +0200 Lars Ingebrigtsen <address@hidden>
> wrote:
>> Jimmy Yuen Ho Wong <address@hidden> 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                address@hidden