From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Jimmy Yuen Ho Wong Newsgroups: gmane.emacs.bugs Subject: bug#31946: 27.0.50; The NSM should warn about more TLS problems Date: Wed, 27 Jun 2018 06:09:25 +0100 Message-ID: References: <87fu1apchn.fsf@gmail.com> <83in65r4n9.fsf@gnu.org> <87y3f1njku.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000919ecc056f989fdc" X-Trace: blaine.gmane.org 1530076149 30495 195.159.176.226 (27 Jun 2018 05:09:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 27 Jun 2018 05:09:09 +0000 (UTC) Cc: 31946@debbugs.gnu.org, Lars Ingebrigtsen To: Noam Postavsky Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jun 27 07:09:05 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fY2hV-0007rI-0g for geb-bug-gnu-emacs@m.gmane.org; Wed, 27 Jun 2018 07:09:05 +0200 Original-Received: from localhost ([::1]:56720 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fY2jc-0006yQ-7Y for geb-bug-gnu-emacs@m.gmane.org; Wed, 27 Jun 2018 01:11:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50061) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fY2jR-0006y8-Tu for bug-gnu-emacs@gnu.org; Wed, 27 Jun 2018 01:11:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fY2jN-00043i-W4 for bug-gnu-emacs@gnu.org; Wed, 27 Jun 2018 01:11:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57104) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fY2jN-00042l-Sq for bug-gnu-emacs@gnu.org; Wed, 27 Jun 2018 01:11:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fY2jN-0007un-L2 for bug-gnu-emacs@gnu.org; Wed, 27 Jun 2018 01:11:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jimmy Yuen Ho Wong Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 27 Jun 2018 05:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31946 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: security Original-Received: via spool by 31946-submit@debbugs.gnu.org id=B31946.153007620630256 (code B ref 31946); Wed, 27 Jun 2018 05:11:01 +0000 Original-Received: (at 31946) by debbugs.gnu.org; 27 Jun 2018 05:10:06 +0000 Original-Received: from localhost ([127.0.0.1]:36768 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fY2iL-0007rJ-Du for submit@debbugs.gnu.org; Wed, 27 Jun 2018 01:10:06 -0400 Original-Received: from mail-io0-f193.google.com ([209.85.223.193]:32897) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fY2iG-0007r2-6n for 31946@debbugs.gnu.org; Wed, 27 Jun 2018 01:09:56 -0400 Original-Received: by mail-io0-f193.google.com with SMTP id d185-v6so691952ioe.0 for <31946@debbugs.gnu.org>; Tue, 26 Jun 2018 22:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HZyN1pRyOKoA6s26qIqAOYNzhunfDC3XBXXOQLQar5U=; b=pa4SlHNPhzf0UjtVl/iXFd3/5mcyj2vTQuF7a9vGsw690b87tUIbYXA6Ksv9zEWVy9 XyRxuZSJaNTRJ1KKt/5dwfDO4fjZ0XYdgpFYSd9RtEvQRf4uhC+3jK28v8BP/tvRCBa6 BZKuJLLY0MGivhh9mQm5QLEms32sLwPOoBJrZ+SCfqlAs24bhm8Bn9jX18nXqA4ocdoa +9TH+pg5WumKSBtfAP0P/XFrRAf9Myju5KVtZnHAoby9h2Kthsyme6gv/VfiRWZVUExs /dChqC2bBs039orcjZAAq82JsHUlqYUsKtrvlfJArJPTppyx+Kz0rblLKZxdxf0+BWVB r0IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HZyN1pRyOKoA6s26qIqAOYNzhunfDC3XBXXOQLQar5U=; b=J4y0EHBa1C1Q16KkX7MgebNqujAsBtugtgpvtd+mI17KfBS/M34lsSG0C/Byzne4Ia N2A4OYh/nGOyF7wb5rHJx+n6muWCQ/pSO03JmLR5/TZXwhMA/S6Axn89bznGVw4D6A99 fJ7YG5GzNR1OvX5QqVlUN3YfLI5BFAH59l3GS9KLkgWibpbgLyDgXV/GOxMW+e6C6GkP llKD7Fbzd0e24r6dawdvagBAem0QtNIsFMjQlQ2yg7ghGUBfu5GMUBuA7FieijV7E7Nx sptt0G75w3XV0rmWm8+OXu5YIpLyQDMLtS/GeJmoSRKHFBDuLvxSHDt51DEVcrSCs6CE R6fQ== X-Gm-Message-State: APt69E0CCYN+rv63WUFdYcUIQssswVrNvkbXte7vGPK2hGIaSAMjsnPq ZzoKTf9UXlnugLgCfQUlaaesD/Uog2EdnPRsdrs= X-Google-Smtp-Source: AAOMgpdDN5dOe+/Q+L+IoQ2oWEDB+cEu04kngn5oWVqP+BHGwAwVL7wyze+wX64j2UNzMlYvfRMN0IMwgav6fJ+OgZI= X-Received: by 2002:a6b:e008:: with SMTP id z8-v6mr3578151iog.296.1530076186381; Tue, 26 Jun 2018 22:09:46 -0700 (PDT) Original-Received: by 2002:a02:985d:0:0:0:0:0 with HTTP; Tue, 26 Jun 2018 22:09:25 -0700 (PDT) In-Reply-To: <87y3f1njku.fsf@gmail.com> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:147849 Archived-At: --000000000000919ecc056f989fdc Content-Type: text/plain; charset="UTF-8" On Wed, Jun 27, 2018 at 1:45 AM, Noam Postavsky wrote: > Eli Zaretskii writes: > > >> From: Lars Ingebrigtsen > >> Date: Tue, 26 Jun 2018 11:27:34 +0200 > >> Cc: 31946@debbugs.gnu.org, Jimmy Yuen Ho Wong > >> > >> 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 --000000000000919ecc056f989fdc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jun 27, 2018 at 1:45 AM, Noam Postavsky <nposta= vs@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: 319= 46@debbugs.gnu.org, Jimmy Yuen Ho Wong <wyuenho@gmail.com>
>>
>> We could get in touch with the gnutls maintainer and ask for his i= nput
>> and perhaps ask for API endpoints to allow us to check for these t= hings?
>
> 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.=C2=A0 This also solves the
composite prime problem, which is likely too expensive to check as well.
https://tools.ietf.org/html/rfc7919:

=C2=A0 =C2=A0Additionally, the DH parameters selected by the server may hav= e a
=C2=A0 =C2=A0known structure that renders them secure against a small subgr= oup
=C2=A0 =C2=A0attack, but a client receiving an arbitrary p and g has no eff= icient
=C2=A0 =C2=A0way to verify that the structure of a new group is reasonable = for
=C2=A0 =C2=A0use.

Acc= ording to Dorey et all [1], the RFC you've linked is one of the 4 strat= egies she
proposed, and the the most feasible in 2016 but still c= omputationally expensive.

Another strategy involves disa= bling 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, a= nd Firefox
[4] is on the verge, so I think this option is also vi= able for Emacs. Just need to pick out the
appripriate DHE ciphers= and add a - for everyone of them in the constructed priority string
<= div>in `gnutls-boot`.

As to why these browser= s are still "failing" the dh-small-subgroup and dh-composite test= s,
the negotiated ciphersuite on both Chrome and Firefox is
<= /div>
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, so the effects of sm= all subgroup
attack is basically mitigated (if I understand the p= apers correctly).

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

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

gives me

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

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

= - Version: TLS1.2
- Key Exchange: DHE-RSA
- Server Signature: RSA-SHA= 512
- Cipher: AES-128-GCM
- MAC: AEAD
- Compression: NULL
- Opt= ions: 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&#= 39; 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&#= 39;s fairly low in
their preferences.
<= br>So.... this look o...kay if you cut out the signature algorithm? Someone= should
doublecheck this.

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

Tidbit: The GnuTLS basicall= y ignored a group of Adobe researchers when they
reported to them GnuTLS was susceptible to the small group attack[7].= ..
[2]: https://groups.go= ogle.com/a/chromium.org/forum/#!topic/blink-dev/AAdv838-koo
[3]: https://www.chromestatus.com/<= wbr>feature/5128908798164992
[4]: https://bugzilla.mozilla.org/show_bug.cgi?id=3D1227519
<= div class=3D"gmail_extra">[5]: https://www.ssllabs.com/ssltest/vi= ewMyClient.html
[6]: https= ://blog.cloudflare.com/our-predictions-for-2018/
[7]: https://eprint.iacr.org/2016/995.pdf
--000000000000919ecc056f989fdc--