On 15.06.2015 21:31, Christian Weisgerber wrote:> On 2015-06-15, Gerhard Wiesinger <lists at wiesinger.com> wrote: > >> I saw that OpenSSH release 6.7 removed all CBC ciphers by default. Is >> CBC therefore considered as broken and unsecure (in general or SSH >> implementation)? > CBC modes in SSH use the last encrypted block of the previous packet > as the IV for the next packet. The protocol is specified this way.As the new IV depends on the (unknown) key and an unbroken crypto/hash algorithms I don't see any problem with this assuming normal behaviour with new keys on a new connection and correct implementation. Am I wrong?> >> I also read a lot of references (see below) but still not clear to me >> what's the actual "security status" of CBC and why it has been removed >> in general. > These are pertinent: > >> http://www.kb.cert.org/vuls/id/958563 > http://www.openssh.com/txt/cbc.adv >But that should be already covered by: http://www.openssh.com/txt/release-5.2 We believe that these attacks are rendered infeasible by these changes. BTW: If you didn't know, here you find the details about the attacks (already in my link list): http://isg.rhul.ac.uk/~kp/SandPfinal.pdf I think it was unknown at the time OpenSSH 5.2 was released. E.g. some assumptions are wrong: After at most 2^14 connections ... With each new ssh connection I will have a new symmetrical key so the assumption is not feasible. Also: One of the main challenges for building an exploit based on our proof-of-concept code would be to find a service which tolerates SSH connection failures and reconnects on these failures. I think such assumptions are just theoretical. Also according to the paper encrypt then-MAC schemes are also vulnerable (which are considered secure): But it is not hard to see that this construction would still be vulnerable to our attacks. There is another paper available: Some Fixes To SSH https://eprint.iacr.org/2013/151.pdf BTW: Jan Zerebecki also doesn't recommend the AES CTR modes as they disclose packet length. https://wiki.mozilla.org/Security/Guidelines/OpenSSH Any comments on this? Ciao, Gerhard -- http://www.wiesinger.com/
On 16.06.2015 11:52, Gerhard Wiesinger wrote:> On 15.06.2015 21:31, Christian Weisgerber wrote: >> On 2015-06-15, Gerhard Wiesinger <lists at wiesinger.com> wrote: >> >>> I saw that OpenSSH release 6.7 removed all CBC ciphers by default. Is >>> CBC therefore considered as broken and unsecure (in general or SSH >>> implementation)? >> CBC modes in SSH use the last encrypted block of the previous packet >> as the IV for the next packet. The protocol is specified this way. > > As the new IV depends on the (unknown) key and an unbroken crypto/hash > algorithms I don't see any problem with this assuming normal behaviour > with new keys on a new connection and correct implementation. Am I wrong? > >> >>> I also read a lot of references (see below) but still not clear to me >>> what's the actual "security status" of CBC and why it has been removed >>> in general. >> These are pertinent: >> >>> http://www.kb.cert.org/vuls/id/958563 >> http://www.openssh.com/txt/cbc.adv >> > > But that should be already covered by: > http://www.openssh.com/txt/release-5.2 > We believe that these attacks are rendered infeasible by these changes. > > BTW: If you didn't know, here you find the details about the attacks > (already in my link list): > http://isg.rhul.ac.uk/~kp/SandPfinal.pdf > I think it was unknown at the time OpenSSH 5.2 was released. > E.g. some assumptions are wrong: After at most 2^14 connections ... > With each new ssh connection I will have a new symmetrical key so the > assumption is not feasible. > > Also: One of the main challenges for building an exploit based on our > proof-of-concept code would be to find a service which tolerates SSH > connection failures and reconnects on these failures. > I think such assumptions are just theoretical. > Also according to the paper encrypt then-MAC schemes are also > vulnerable (which are considered secure): But it is not hard to see > that this construction would still be vulnerable to our attacks. > > There is another paper available: Some Fixes To SSH > https://eprint.iacr.org/2013/151.pdf > > BTW: Jan Zerebecki also doesn't recommend the AES CTR modes as they > disclose packet length. > https://wiki.mozilla.org/Security/Guidelines/OpenSSH > Any comments on this? >Jan answered me, as the packet length is transmitted in plaintext, see: http://blog.djm.net.au/2013/11/chacha20-and-poly1305-in-openssh.html Ciao, Gerhard -- http://www.wiesinger.com/
Hi Gerhard, This is not exactly true. CTR modes have the length field encrypted. etm MAC modes and AES-GCM have the length field in cleartext. CBC is dangerous because the length field is encrypted with CBC. aes128-ctr + hmac-sha256 doesn't have any known vulnerability and encrypts the packet length, but uses the bad practice of e&m. chacha20-poly1305 encrypts both payload and packet len + uses authenticated encryption (best practice), even if the implementation looks very similar to etm. Aris>> BTW: Jan Zerebecki also doesn't recommend the AES CTR modes as they >> disclose packet length. >> https://wiki.mozilla.org/Security/Guidelines/OpenSSH >> Any comments on this? >> > > Jan answered me, as the packet length is transmitted in plaintext, see: > http://blog.djm.net.au/2013/11/chacha20-and-poly1305-in-openssh.html > > Ciao, > Gerhard > > -- http://www.wiesinger.com/ > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >