Hi, You will be aware of https://weakdh.org/ by now, I presume; the take-home seems to be that 1024-bit DH primes might well be too weak. I'm wondering what (if anything!) you propose to do about this issue, and what Debian might do for our users? openssh already prefers ECDH, which must reduce the impact somewhat, although the main Windows client (PuTTY) doesn't support ECDH yet. But openssh does still offer diffie-hellman-group1-sha1 (uses a 1024-bit group) and diffie-hellman-group14-sha1 (uses a 2047-bit group), which must be considered a bit suspect? Of course RFC4253 says implementations MUST offer these... The moduli file you provide has this distribution of sizes: size count 1023 36 1535 50 2047 36 3071 31 4095 41 6143 27 8191 39 Would it be sensible to remove the <2047 moduli? Generating the larger ones is quite time-consuming on non-specialist kit, which would seem to argue against re-generating them on users' machines. Regards, Matthew
Can this be addressed in ssh_config/sshd_config with the KexAlgorithms setting? -----Original Message----- From: openssh-unix-dev [mailto:openssh-unix-dev-bounces+scott_n=xypro.com at mindrot.org] On Behalf Of Matthew Vernon Sent: Thursday, May 21, 2015 6:27 AM To: openssh-unix-dev at mindrot.org Subject: Weak DH primes and openssh Hi, You will be aware of https://weakdh.org/ by now, I presume; the take-home seems to be that 1024-bit DH primes might well be too weak. I'm wondering what (if anything!) you propose to do about this issue, and what Debian might do for our users? openssh already prefers ECDH, which must reduce the impact somewhat, although the main Windows client (PuTTY) doesn't support ECDH yet. But openssh does still offer diffie-hellman-group1-sha1 (uses a 1024-bit group) and diffie-hellman-group14-sha1 (uses a 2047-bit group), which must be considered a bit suspect? Of course RFC4253 says implementations MUST offer these... The moduli file you provide has this distribution of sizes: size count 1023 36 1535 50 2047 36 3071 31 4095 41 6143 27 8191 39 Would it be sensible to remove the <2047 moduli? Generating the larger ones is quite time-consuming on non-specialist kit, which would seem to argue against re-generating them on users' machines. Regards, Matthew _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
On Thu, 21 May 2015, Matthew Vernon wrote:> Hi, > > You will be aware of https://weakdh.org/ by now, I presume; the > take-home seems to be that 1024-bit DH primes might well be too weak. > I'm wondering what (if anything!) you propose to do about this issue, > and what Debian might do for our users?I don't think much needs to be done: OpenSSH has preferred ECDH, and before that DH group-exchange with regularly refreshed modp groups for over a decade, so the diffie-hellman-group1-sha1 mode is only ever used for compatibility with legacy implementations. While it is still offered (only by the client), it is offered last in preference and will never be selected if the client and server support better options. SSH's key exchange protocol AFAIK stronger than SSL/TLS's and forcing a downgrade requires breaking both the DH exchange and the hostkey algorithm in more or less real time. We do plan on dropping diffie-hellman-group1-sha1 from the default client offer later this year. We dropped it from servers a few releases ago. As for what Debian (and other distribtors) can do: IMO the best thing is to aggressively backport recent releases of OpenSSH to older supported releases of your operating systems. We've been trying to modernise the crypto across the 6.x releases as fast as we can without breaking stuff.> openssh already prefers ECDH, which must reduce the impact somewhat, > although the main Windows client (PuTTY) doesn't support ECDH yet. But > openssh does still offer diffie-hellman-group1-sha1 (uses a 1024-bit > group) and diffie-hellman-group14-sha1 (uses a 2047-bit group), which > must be considered a bit suspect? Of course RFC4253 says implementations > MUST offer these...We'll be violating a few "MUST" clauses in the 7.0 release in the interests of security, including turning off group1 by default.> The moduli file you provide has this distribution of sizes: > > size count > 1023 36 > 1535 50 > 2047 36 > 3071 31 > 4095 41 > 6143 27 > 8191 39 > > Would it be sensible to remove the <2047 moduli? Generating the larger > ones is quite time-consuming on non-specialist kit, which would seem to > argue against re-generating them on users' machines.Darren can chime in here, but I don't think anything <2047 will actually be used since he updated dh.c:dh_estimate() a few years ago. -d
On Fri, May 22, 2015 at 10:33 AM, Damien Miller <djm at mindrot.org> wrote:> > On Thu, 21 May 2015, Matthew Vernon wrote: > > > Hi, > > > > You will be aware of https://weakdh.org/ by now, I presume; the > > take-home seems to be that 1024-bit DH primes might well be too weak. > > I'm wondering what (if anything!) you propose to do about this issue, > > and what Debian might do for our users? > > I don't think much needs to be done: OpenSSH has preferred ECDH, and > before that DH group-exchange with regularly refreshed modp groups for > over a decade,My intent was to refresh the groups for every release, but for several reasons I haven't been consistent. I am currently generating a new set.> so the diffie-hellman-group1-sha1 mode is only ever used > for compatibility with legacy implementations. > > While it is still offered (only by the client), it is offered last > in preference and will never be selected if the client and server > support better options. SSH's key exchange protocol AFAIK stronger than > SSL/TLS's and forcing a downgrade requires breaking both the DH exchange > and the hostkey algorithm in more or less real time. > > We do plan on dropping diffie-hellman-group1-sha1 from the default > client offer later this year. We dropped it from servers a few releases > ago. > > As for what Debian (and other distribtors) can do: IMO the best thing is > to aggressively backport recent releases of OpenSSH to older supported > releases of your operating systems. We've been trying to modernise the > crypto across the 6.x releases as fast as we can without breaking stuff. > > > openssh already prefers ECDH, which must reduce the impact somewhat, > > although the main Windows client (PuTTY) doesn't support ECDH yet. But > > openssh does still offer diffie-hellman-group1-sha1 (uses a 1024-bit > > group) and diffie-hellman-group14-sha1 (uses a 2047-bit group), which > > must be considered a bit suspect? Of course RFC4253 says implementations > > MUST offer these... >Note that PuTTY does do Diffie-Hellman Group Exchange, but until very recently (ie after their 0.64 release) they didn't do the one that was actually standardized in RFC4419. OpenSSH recently removed support for that non-standard one and as a result we don't offer DHGEX to PuTTY versions <= 0.64 so they'll fall back to group14 (2k bit fix group).> We'll be violating a few "MUST" clauses in the 7.0 release in the > interests of security, including turning off group1 by default.[...]> > Would it be sensible to remove the <2047 moduli? Generating the larger > > ones is quite time-consuming on non-specialist kit, which would seem to > > argue against re-generating them on users' machines. >Currently, generating the 8kbit groups takes about 12 hours on a fairly beefy 8 core x86-64 machine. Anything slower, with fewer cores or bits would take a lot longer. Generating just the 1kbit groups takes about an hour on a 500MHz Pentium class chip of the type found in smallish x86 embedded systems. (Out of curiosity I fed the 8k candidate list to the same machine: it currently estimates it'll take 281 days). Darren can chime in here, but I don't think anything <2047 will actually> be used since he updated dh.c:dh_estimate() a few years ago. >That's only true for OpenSSH clients. PuTTY does this in their ssh.c: s->pbits = 512 << ((s->nbits - 1) / 64); which means that it'll ask for 1024, 2048 and 4906 bit groups for 128 bit, 192 bit and 256 bit ciphers respectively (ie equivalent to what OpenSSH did prior to [1], which is a lot less than current recommendations[2]. That said the development versions also have ecdh which they use in preference to DH-GEX. Anyway those older PuTTYs will be around for a while, maybe we should be removing the 1024 bit groups from the moduli file? For it to have much impact it'd need to happen on the older OpenSSH servers because the current ones don't offer DH-GEX to old PuTTY versions for the reasons above. [1] https://anongit.mindrot.org/openssh.git/commit/dh.c?id=df62d71e64d29d1054e7a53d1a801075ef70335f ) [2] http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
On Thu, May 21, 2015 at 11:26 PM, Matthew Vernon <matthew at debian.org> wrote:> > You will be aware of https://weakdh.org/ by now, I presume; the > take-home seems to be that 1024-bit DH primes might well be too weak. > I'm wondering what (if anything!) you propose to do about this issue, > and what Debian might do for our users?Would you (and any other vendors) consider generating your own moduli file for your distribution? If a few vendors did that it'd increase the diversity quite a lot and it'd stop us (well, specifically me) being the point of failure for not making updates. I have some scripts to split the screening (the CPU intensive part) up into 1 shard per CPU, which would let the whole process run in about a day on a decent sized machine. If there is any interest I can tidy them up and stick them in contrib/ or something. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
On May 22, 2015 8:18 AM, "Darren Tucker" <dtucker at zip.com.au> wrote:> > On Thu, May 21, 2015 at 11:26 PM, Matthew Vernon <matthew at debian.org>wrote:> > > > You will be aware of https://weakdh.org/ by now, I presume; the > > take-home seems to be that 1024-bit DH primes might well be too weak. > > I'm wondering what (if anything!) you propose to do about this issue, > > and what Debian might do for our users? > > > Would you (and any other vendors) consider generating your own moduli file > for your distribution? If a few vendors did that it'd increase the > diversity quite a lot and it'd stop us (well, specifically me) being the > point of failure for not making updates. > > I have some scripts to split the screening (the CPU intensive part) upinto> 1 shard per CPU, which would let the whole process run in about a day on a > decent sized machine. If there is any interest I can tidy them up and > stick them in contrib/ or something.Are the scripts public ?> > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
On Thu 2015-05-21 20:33:24 -0400, Damien Miller wrote:> On Thu, 21 May 2015, Matthew Vernon wrote: >> openssh already prefers ECDH, which must reduce the impact somewhat, >> although the main Windows client (PuTTY) doesn't support ECDH yet. But >> openssh does still offer diffie-hellman-group1-sha1 (uses a 1024-bit >> group) and diffie-hellman-group14-sha1 (uses a 2047-bit group), which >> must be considered a bit suspect? Of course RFC4253 says implementations >> MUST offer these... > > We'll be violating a few "MUST" clauses in the 7.0 release in the > interests of security, including turning off group1 by default.Is it worth trying to update the RFC to change these MUSTs for something better? --dkg
On Fri 2015-05-22 00:06:29 -0400, Darren Tucker wrote:> On Thu, May 21, 2015 at 11:26 PM, Matthew Vernon <matthew at debian.org> wrote: >> >> You will be aware of https://weakdh.org/ by now, I presume; the >> take-home seems to be that 1024-bit DH primes might well be too weak. >> I'm wondering what (if anything!) you propose to do about this issue, >> and what Debian might do for our users? > > Would you (and any other vendors) consider generating your own moduli file > for your distribution? If a few vendors did that it'd increase the > diversity quite a lot and it'd stop us (well, specifically me) being the > point of failure for not making updates.(thanks for making the recent moduli update, Darren!) This is an interesting proposal as a way to increase group diversity, but it also creates a non-obvious fingerprinting channel. That is, distro-specific groups would provide a way that someone scanning to find out what distro is in use can make a more accurate guess based on the primes offered. I grant that debian's current patches that add the debian revision themselves provide a fingerprinting mechanism, but those can be disabled on Debian with "DebianBanner no" in sshd_config. We'd want to make sure that distro-specific moduli don't re-introduce fingerprinting for operators who want to hide their choice of distro. --dkg PS Darren, has there been any attempt at generating primality proofs for the values in ./moduli, as opposed to 100 rounds of Miller-Rabin? It would be a shame for a pseudoprime to slip in, however unlikely that would be.
> Can this be addressed in ssh_config/sshd_config with the KexAlgorithms setting?weakdh.org/sysadmin.html recommends adding: KexAlgorithms curve25519-sha256 at libssh.org But this thread makes it sound as if it's not necessary. Can anyone confirm? Personally I'm on openssh-6.7. - Grant> You will be aware of https://weakdh.org/ by now, I presume; the take-home seems to be that 1024-bit DH primes might well be too weak. > I'm wondering what (if anything!) you propose to do about this issue, and what Debian might do for our users? > > openssh already prefers ECDH, which must reduce the impact somewhat, although the main Windows client (PuTTY) doesn't support ECDH yet. But openssh does still offer diffie-hellman-group1-sha1 (uses a 1024-bit > group) and diffie-hellman-group14-sha1 (uses a 2047-bit group), which must be considered a bit suspect? Of course RFC4253 says implementations MUST offer these... > > The moduli file you provide has this distribution of sizes: > > size count > 1023 36 > 1535 50 > 2047 36 > 3071 31 > 4095 41 > 6143 27 > 8191 39 > > Would it be sensible to remove the <2047 moduli? Generating the larger ones is quite time-consuming on non-specialist kit, which would seem to argue against re-generating them on users' machines.