Re: Logjam Attack: is OpenIKED and OpenSMTPD vulnerable?

2015-05-28 Thread Ruslanas Gžibovskis
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 pabl...@gmail.com wrote:

 Thanks for the update Mike, greatly appreciated.

 On Wed, May 27, 2015 at 9:02 PM, Mike Belopuhov m...@belopuhov.com
 wrote:

  On 25 May 2015 at 14:33, Pablo Méndez Hernández pabl...@gmail.com
 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?

2015-05-28 Thread Pablo Méndez Hernández
Thanks for the update Mike, greatly appreciated.

On Wed, May 27, 2015 at 9:02 PM, Mike Belopuhov m...@belopuhov.com wrote:

 On 25 May 2015 at 14:33, Pablo Méndez Hernández pabl...@gmail.com
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?

2015-05-27 Thread Mike Belopuhov
On 25 May 2015 at 14:33, Pablo Méndez Hernández pabl...@gmail.com 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?

2015-05-25 Thread Pablo Méndez Hernández
Hi,

Any statement for iked?

On Thu, May 21, 2015 at 12:51 AM, Gilles Chehade gil...@poolp.org 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
1r2=1.32f=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?

2015-05-20 Thread Gilles Chehade
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.31r2=1.32f=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