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  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?

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  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?

2015-05-27 Thread Mike Belopuhov
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?

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  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?

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.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