bug#31946: 27.0.50; The NSM should warn about more TLS problems

[Jimmy Yuen Ho Wong <wyuenho@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3635 bytes --]

`dh-composite` can be mitigated by using the "NORMAL:%PROFILE_MEDIUM"
priority string[1], "NORMAL:%PROFILE_HIGH" [2] will pass all 26 badssl test
while still allowing connection to ELPA/MELPA without even supplying CRL
files (GnuTLS already does OCSP stapling verifcation transparently, and
Emacs is using it already minus surfacing `GNUTLS_CERT_MISSING_OCSP_STATUS`
when it fails). The exact meaning these levels appears to be spread out
among different tables in ENISA's Algorithms, Key Sizes and Parameters
Report - 2013 [3].

As a possible way to avoid confusion, I would suggest we consolidate the 2
different meaning of profiles (NSM and GnuTLS) into GnuTLS's. Instead of
having users to edit an alist like Lars has done in commit 6584bc67, we
could:

1. Append `network-security-level` to `gnutls-algorithm-priority`, i.e.
`network-security-level` will be a list of predefined symbols that will be
mapped to GnuTLS's `%PROFILE_*` strings, and append to it when setting up
`gnutls-boot-parameters`.
2. Forget about letting users decide whether they want to accept
problematic certs or not, no modern browsers does it anymore. Doing network
security checks in 2 different places also introduces impedance mismatch.
Specifically, GnuTLS by default disables a number of cyphers and hashes.
The only way to stop it from generating fatal alerts is to enable
everything GnuTLS has implemented and reinvent all the wheels in LISP (do
you really want to reenable SSL3?). This is insane from both a security and
performance perspective, as we don't have reliable NETSEC resources to
respond to any security issues that we may introduce during the process.
Even if we do, there's a larger problem of Emacs's release process.
3. To solve the problem of letting users fine tune the client's acceptable
cyphersuite, MACs and whatnot for emergencies out of Emacs' release cycles,
let's introduce a bunch of new defcustoms such as `gnutls-cyphersuite`,
`gnutls-key-exchange` etc, see [1] for the table.
4. Normally, the fine tuning defcustoms in 3) will be nil, in which case
`gnutls-algorithm-priority` takes precedence, otherwise they are combined
into a final priority string supplied to `gnutls-boot-parameters`.
5. Merge nsm into the gnutls group. No more distinction between interactive
and non-interactive sessions due to 2).

References:
[1]: https://gnutls.org/manual/html_node/Priority-Strings.html
<https://gnutls.org/manual/html_node/Priority-Strings.html>
[2]: https://gnutls.org/manual/html_node/Selecting-cryptographic-
key-sizes.html#tab_003akey_002dsizes
<https://gnutls.org/manual/html_node/Selecting-cryptographic-key-sizes.html#tab_003akey_002dsizes>
[3]: https://www.enisa.europa.eu/publications/algorithms-key-
sizes-and-parameters-report
<https://www.enisa.europa.eu/publications/algorithms-key-sizes-and-parameters-report>

On Tue, Jun 26, 2018 at 2:23 AM, Noam Postavsky <npostavs@gmail.com> wrote:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
> > There are also more protocol stuff we should warn about on various
> > levels.  These should be on `high':
>
> >>            "https://dh-small-subgroup.badssl.com/"        ;; fail
> >>            "https://dh-composite.badssl.com/"             ;; fail
>
> So these ones seem kind of problematic, as alluded to on emacs-devel.
> It doesn't look like gnutls has an API to get or check the value of the
> DH primes (calc-prime-test bails out when given a 1024 bit prime, so we
> definitely need library support for this).
>
> https://lists.gnu.org/archive/html/emacs-devel/2018-06/msg00805.html
> https://lists.gnu.org/archive/html/emacs-devel/2018-06/msg00807.html
>
>
>

[-- Attachment #2: Type: text/html, Size: 4875 bytes --]