Debian bugs requesting "safer" default algos/etc.

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 



Hi.

Another FYI:
Along with the recent publications about alleged NSA attacks against
SSH, we got some bug[0][1] reports in Debian about "please use more
secure algos" (i.e. disable all others).

Perhaps something you might want to look at.


- With respect to the DH group sizes, which is requested there to be
increased... well I've already opened #2302 and #2303, but these are
more related around DH-GEX, not about disabling e.g.
diffie-hellman-group1-sha1, diffie-hellman-group14-sha1 and possibly
even diffie-hellman-group-exchange-sha1 nor do they deal with the
request from the submitters of the bugs in Debian to no longer generate
small moduli by default.


- With respect to those submitters request to drop many "legacy" alogs
from the default lists... well it's difficult because of
interoperability, but I'd basically agree with that request... people in
need for those algos can still enable them manually or (for the client
side) even just on a per host basis.
I for example allow on my systems only these per default (in ssh_config
and sshd_config: 
HostKeyAlgorithms       ssh-ed25519,ssh-ed25519-cert-v01@xxxxxxxxxxx,ecdsa-sha2-nistp521,ecdsa-sha2-nistp521-cert-v01@xxxxxxxxxxx,ecdsa-sha2-nistp384,ecdsa-sha2-nistp384-cert-v01@xxxxxxxxxxx,ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-v01@xxxxxxxxxxx,ssh-rsa,ssh-rsa-cert-v01@xxxxxxxxxxx
KexAlgorithms           curve25519-sha256@xxxxxxxxxx,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256
Ciphers                 chacha20-poly1305@xxxxxxxxxxx,aes256-gcm@xxxxxxxxxxx,aes128-gcm@xxxxxxxxxxx,aes256-ctr,aes192-ctr,aes128-ctr
MACs                    hmac-sha2-512-etm@xxxxxxxxxxx,hmac-sha2-256-etm@xxxxxxxxxxx,umac-128-etm@xxxxxxxxxxx

I.e. everything that matches:
- dss, v00
- diffie-hellman
  => in principle I woluld allow diffie-hellman-group-exchange-sha256,
     but not as long as #2302 and #2303 are issues.
- arcfour, cbc
- sha1, md5, ripemd, umac-64 or that not matches etm
  => I have no real reason to believe that umac-64-etm@xxxxxxxxxxx isn't
     secure enough... I just thought better more bits, it doesn't hurt.

And I'm still thinking about removing all nist curves algos.
Also I'm well aware that the algos I've decided to drop are not
necessarily fully broken... but again,... better safe than sorry.


I'm not sure how much upstream is willing here to "harden" defaults,
since this usually goes on out-of-the-box interoperability... but I
think it would be better if any such hardening takes place on the
upstream side, than every distro cooking it's own stuff.


Cheers,
Chris.

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774711
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774793

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux