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: 3974 bytes --]

On Wed, Jun 27, 2018 at 1:45 AM, Noam Postavsky <npostavs@gmail.com> wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Lars Ingebrigtsen <larsi@gnus.org>
> >> Date: Tue, 26 Jun 2018 11:27:34 +0200
> >> Cc: 31946@debbugs.gnu.org, Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> >>
> >> We could get in touch with the gnutls maintainer and ask for his input
> >> and perhaps ask for API endpoints to allow us to check for these things?
> >
> > Yes, I think that's the right way for moving forward.
>
> By the way, I've researched this a bit more, it seems like there is no
> practical way to detect small subgroups at all, the only solution is to
> move to standardized domains (the smallest of which is 2048 bits)
> similar to how ECDHE uses standard curves.  This also solves the
> composite prime problem, which is likely too expensive to check as well.
>
> https://tools.ietf.org/html/rfc7919:
>
>    Additionally, the DH parameters selected by the server may have a
>    known structure that renders them secure against a small subgroup
>    attack, but a client receiving an arbitrary p and g has no efficient
>    way to verify that the structure of a new group is reasonable for
>    use.
>

According to Dorey et all [1], the RFC you've linked is one of the 4
strategies she
proposed, and the the most feasible in 2016 but still computationally
expensive.

Another strategy involves disabling DHE, which she didn't really like as
that will be
TLS 1.3's only fallback, but Safari[2], Chrome[3] have since removed them,
and Firefox
[4] is on the verge, so I think this option is also viable for Emacs. Just
need to pick out the
appripriate DHE ciphers and add a - for everyone of them in the constructed
priority string
in `gnutls-boot`.

As to why these browsers are still "failing" the dh-small-subgroup and
dh-composite tests,
the negotiated ciphersuite on both Chrome and Firefox is
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, so the effects of small subgroup
attack is basically mitigated (if I understand the papers correctly).

`(setq gnutls-log-level 999)` in Emacs currently doesn't tell me what KX
algo was used
, it just tells me AES-256-GCM was negotiated as a cipher. However,

`$ gnutls-cli -V --x509cafile /opt/local/etc/openssl/cert.pem -p 443
dh-small-subgroup.badssl.com`

gives me

- Status: The certificate is trusted.
- Description: (TLS1.2)-(DHE-RSA-2048)-(AES-128-GCM)
- Session ID: ...
- Ephemeral Diffie-Hellman parameters
 - Using prime: 2048 bits
 - Secret key: 507 bits
 - Peer's public key: 2048 bits
 - PKCS#3 format:

-----BEGIN DH PARAMETERS-----
...
-----END DH PARAMETERS-----

- Version: TLS1.2
- Key Exchange: DHE-RSA
- Server Signature: RSA-SHA512
- Cipher: AES-128-GCM
- MAC: AEAD
- Compression: NULL
- Options: safe renegotiation,
- Channel binding 'tls-unique': ...
- Handshake was completed

This is just plain... weird. It's TLS_DHE_RSA_AES_128_GCM_SHA512 with 2048
bit prime, and it's nowhere to be found in browsers' ciphersuites.
Although, TLS_DHE_RSA_AES_128_GCM_SHA256 does still exist on browsers,
and does offer perfect forward secrecy according to SSLLabs[5], but it's
fairly low in
their preferences.

So.... this look o...kay if you cut out the signature algorithm? Someone
should
doublecheck this.

Alternatively, we can wait for widespread adaption of TLS 1.3 (Cloudflare
predicts
50% of TLS connection will be 1.3 by the end of this year[6]), time fixes
everything...

Tidbit: The GnuTLS basically ignored a group of Adobe researchers when they
reported to them GnuTLS was susceptible to the small group attack[7]...

[1]: https://eprint.iacr.org/2016/999.pdf
[2]: https://groups.google.com/a/chromium.org/forum/#!topic/
blink-dev/AAdv838-koo
[3]: https://www.chromestatus.com/feature/5128908798164992
[4]: https://bugzilla.mozilla.org/show_bug.cgi?id=1227519
[5]: https://www.ssllabs.com/ssltest/viewMyClient.html
[6]: https://blog.cloudflare.com/our-predictions-for-2018/
[7]: https://eprint.iacr.org/2016/995.pdf

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