Re: "Logjam Attack": is OpenIKED and OpenSMTPD vulnerable?
Hi team! Sorry for interruption, but why not just switch to 4096? So no problems for future... I expect that there will be something more then just it uses more cpu time to operate the same... please fix/explane me. Thank you. Have a nice $day_time ;) Ruslanas On Thu, 28 May 2015 12:16 Pablo Méndez Hernández wrote: > Thanks for the update Mike, greatly appreciated. > > On Wed, May 27, 2015 at 9:02 PM, Mike Belopuhov > wrote: > > > On 25 May 2015 at 14:33, Pablo Méndez Hernández > wrote: > > > Hi, > > > > > > Any statement for iked? > > > > > > > iked implements IKEv2 which doesn't use SSL/TLS. So this > > attack doesn't directly apply to IKEv2. However we would > > accept MODP 1024 and better by default. Perhaps we > > should bump it to 2048 minimum. > > > > > > -- > > Pablo Méndez Hernández
Re: "Logjam Attack": is OpenIKED and OpenSMTPD vulnerable?
Thanks for the update Mike, greatly appreciated. On Wed, May 27, 2015 at 9:02 PM, Mike Belopuhov wrote: > On 25 May 2015 at 14:33, Pablo Méndez Hernández wrote: > > Hi, > > > > Any statement for iked? > > > > iked implements IKEv2 which doesn't use SSL/TLS. So this > attack doesn't directly apply to IKEv2. However we would > accept MODP 1024 and better by default. Perhaps we > should bump it to 2048 minimum. > -- Pablo Méndez Hernández
Re: "Logjam Attack": is OpenIKED and OpenSMTPD vulnerable?
On 25 May 2015 at 14:33, Pablo Méndez Hernández wrote: > Hi, > > Any statement for iked? > iked implements IKEv2 which doesn't use SSL/TLS. So this attack doesn't directly apply to IKEv2. However we would accept MODP 1024 and better by default. Perhaps we should bump it to 2048 minimum.
Re: "Logjam Attack": is OpenIKED and OpenSMTPD vulnerable?
Hi, Any statement for iked? On Thu, May 21, 2015 at 12:51 AM, Gilles Chehade wrote: > On Wed, May 20, 2015 at 11:55:42PM +0200, L.R. D.S. wrote: > > Anyone write today on @misc and @tech about this, so I'll ask just to > make sure: > > is OpenIKED and/or OpenSMTPD vulnerable to this new "Logjam Attack"? > > This vulnerability allow "a man-in-the-middle attacker to downgrade > vulnerable TLS > > connections to 512-bit export-grade cryptography" and "[Since] Millions > of HTTPS, > > SSH, and VPN servers all use the same prime numbers for Diffie-Hellman > key exchange" > > "[using it] an attacker can quickly break individual connections" [...] > "attacks on > > VPNs are consistent with having achieved such a break."[1]. They have a > proof of > > concept[2] and a research paper[3]. > > > > As far as OpenSMTPD is concerned: > > "The attack affects any server that supports DHE_EXPORT ciphers, > and affects all modern web browsers." (from weakdh.org) > > The default cipher-suite is "HIGH:!aNULL:!MD5" which doesn't support any > DHE_EXPORT cipher (obvious but verified with both LibreSSL and OpenSSL): > > $ openssl ciphers HIGH:!aNULL:!MD5|grep EXPORT > $ > > > "Millions of HTTPS, SSH, and VPN servers all use the same prime numbers > for Diffie-Hellman key exchange. [...]" > > Yes, there is a very popular set of 512-bits DH parameters that everyone > uses because it was considered safe to share the params if generated the > right way. It is part of tons of examples, documented as "safe to reuse" > and it ended pretty much everywhere (openssl s_server to name one). > > We have switched to 1024-bits DH parameters 4 years ago: > > > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/smtpd/ssl.c.diff?r1=1.3 1&r2=1.32&f=h > > The DH parameters were generated by myself on a safe machine, so there's > very very low chances "millions of servers" are sharing the same ones ;) > > The article suggests that 1024-bits DH isn't enough and that you need it > to be at least 2048-bits, however before we bump this default, we need a > fair amount of testing: last time I tried, it broke A LOT of exchanges. > > Discussions will take place with regard to what we'll do anways... > > > -- > Gilles Chehade > > https://www.poolp.org @poolpOrg > > -- Pablo Méndez Hernández
Re: "Logjam Attack": is OpenIKED and OpenSMTPD vulnerable?
On Wed, May 20, 2015 at 11:55:42PM +0200, L.R. D.S. wrote: > Anyone write today on @misc and @tech about this, so I'll ask just to make > sure: > is OpenIKED and/or OpenSMTPD vulnerable to this new "Logjam Attack"? > This vulnerability allow "a man-in-the-middle attacker to downgrade > vulnerable TLS > connections to 512-bit export-grade cryptography" and "[Since] Millions of > HTTPS, > SSH, and VPN servers all use the same prime numbers for Diffie-Hellman key > exchange" > "[using it] an attacker can quickly break individual connections" [...] > "attacks on > VPNs are consistent with having achieved such a break."[1]. They have a proof > of > concept[2] and a research paper[3]. > As far as OpenSMTPD is concerned: "The attack affects any server that supports DHE_EXPORT ciphers, and affects all modern web browsers." (from weakdh.org) The default cipher-suite is "HIGH:!aNULL:!MD5" which doesn't support any DHE_EXPORT cipher (obvious but verified with both LibreSSL and OpenSSL): $ openssl ciphers HIGH:!aNULL:!MD5|grep EXPORT $ "Millions of HTTPS, SSH, and VPN servers all use the same prime numbers for Diffie-Hellman key exchange. [...]" Yes, there is a very popular set of 512-bits DH parameters that everyone uses because it was considered safe to share the params if generated the right way. It is part of tons of examples, documented as "safe to reuse" and it ended pretty much everywhere (openssl s_server to name one). We have switched to 1024-bits DH parameters 4 years ago: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/smtpd/ssl.c.diff?r1=1.31&r2=1.32&f=h The DH parameters were generated by myself on a safe machine, so there's very very low chances "millions of servers" are sharing the same ones ;) The article suggests that 1024-bits DH isn't enough and that you need it to be at least 2048-bits, however before we bump this default, we need a fair amount of testing: last time I tried, it broke A LOT of exchanges. Discussions will take place with regard to what we'll do anways... -- Gilles Chehade https://www.poolp.org @poolpOrg