similar to: FREAK/Logjam, and SSL protocols to use

List, good afternoon, I was reading up on a TLS Diffie Hellman protocol weakness described here https://weakdh.org/sysadmin.html which is similar to the earlier FREAK attack, and can result in downgrade of cipher suites. Part of the solution workaround that the researchers describe for Dovecot here https://weakdh.org/sysadmin.html includes altering DH parameters length to 2048, and

Quoting Gedalya <gedalya at gedalya.net>: > On 05/26/2015 10:37 AM, Ron Leach wrote: >> https://weakdh.org/sysadmin.html >> >> includes altering DH parameters length to 2048, and re-specifying the >> allowable cipher suites - they give their suggestion. > > It looks like there is an error on this page regarding regeneration. In > current dovecots

Quoting Gedalya <gedalya at gedalya.net>: > On 05/27/2015 09:55 AM, Rick Romero wrote: >> Quoting Gedalya <gedalya at gedalya.net>: >> >>> On 05/26/2015 10:37 AM, Ron Leach wrote: >>>> https://weakdh.org/sysadmin.html >>>> >>>> includes altering DH parameters length to 2048, and re-specifying the >>>> allowable

On 05/27/2015 09:55 AM, Rick Romero wrote: > Quoting Gedalya <gedalya at gedalya.net>: > >> On 05/26/2015 10:37 AM, Ron Leach wrote: >>> https://weakdh.org/sysadmin.html >>> >>> includes altering DH parameters length to 2048, and re-specifying the >>> allowable cipher suites - they give their suggestion. >> >> It looks like there

>But when you write NOT to regenerate, are you saying that using larger primes makes regenerating unnecessary, or are you telling us that it's somehow harmful? For a given computational effort, you get the most bang-for-the-buck by choosing large parameters (and checking very carefully that they are "safe") rather than smaller parameters (and/or checking them less carefully)

On 05/26/2015 10:37 AM, Ron Leach wrote: > > https://weakdh.org/sysadmin.html > > includes altering DH parameters length to 2048, and re-specifying the > allowable cipher suites - they give their suggestion. It looks like there is an error on this page regarding regeneration. In current dovecots ssl_parameters_regenerate defaults to zero, and this means regeneration is

On 27/05/2015 05:22, Gedalya wrote: > It looks like there is an error on this page regarding regeneration. > In current dovecots ssl_parameters_regenerate defaults to zero, and > this means regeneration is disabled. The old default was 168 hours (1 > week). > The language on http://wiki2.dovecot.org/SSL/DovecotConfiguration is > confusing and could be understood to mean that the

> For a given computational effort, you get the most bang-for-the-buck by > choosing large parameters (and checking very carefully that they are > "safe") rather than smaller parameters (and/or checking them less > carefully) which you then regenerate. This discussion (on the OpenSSH mailing list) http://marc.info/?t=143221614200001 may be helpful to those thinking

> Can this be addressed in ssh_config/sshd_config with the KexAlgorithms setting? weakdh.org/sysadmin.html recommends adding: KexAlgorithms curve25519-sha256 at libssh.org But this thread makes it sound as if it's not necessary. Can anyone confirm? Personally I'm on openssh-6.7. - Grant > You will be aware of https://weakdh.org/ by now, I presume; the take-home seems to be

Hi, You will be aware of https://weakdh.org/ by now, I presume; the take-home seems to be that 1024-bit DH primes might well be too weak. I'm wondering what (if anything!) you propose to do about this issue, and what Debian might do for our users? openssh already prefers ECDH, which must reduce the impact somewhat, although the main Windows client (PuTTY) doesn't support ECDH yet. But

Based on the recent found weaknesses in DH key exchange, http://weakdh.org/ I increased ssl_dh_parameters_length to 2048 bits, and found waited for 5+ minutes for dovecot to come back online after a restart. Unless you got a fast machine, the initialization of DH parameters can exceed your patience. Regeneration may not be a problem (if ssl_parameters_regenerate=0 or if Dovecot uses old

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here's the output from running sshd in debug mode: debug1: sshd version OpenSSH_3.7p1 debug1: private host key: #0 type 0 RSA1 debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA debug1: setgroups() failed:

> *** openbsd-compat/bsd-nextstep.h.orig Sun Feb 4 00:16:16 2001 > --- openbsd-compat/bsd-nextstep.h Sun Feb 4 00:19:09 2001 > *************** > *** 48,52 **** > --- 48,56 ---- > speed_t cfgetispeed(const struct termios *t); > int cfsetospeed(struct termios *t, int speed); > int cfsetispeed(struct termios *t, int speed); > + > + /* LIMITS */ > + #define

On Fri 2015-05-22 00:06:29 -0400, Darren Tucker wrote: > On Thu, May 21, 2015 at 11:26 PM, Matthew Vernon <matthew at debian.org> wrote: >> >> You will be aware of https://weakdh.org/ by now, I presume; the >> take-home seems to be that 1024-bit DH primes might well be too weak. >> I'm wondering what (if anything!) you propose to do about this issue, >>

Are there any plans to include support for SRP or a similar zero-knowledge password protocol into OpenSSH? -- Jeremy

I was reading https://weakdh.org/sysadmin.html They also have a very interesting paper as a PDF. Anyway it appears that most ssh servers, when using DHE key exchange, use the 1024-bit Oakley Group 2 and there is suspicion the NSA has done the pre-computations needed to passively decrypt any tls communication using DHE with that particular prime group. They recommend setting the following:

On MacOSX 10.6, I get: ld: duplicate symbol _cmd_batch in dsync/.libs/libdsync.a(doveadm-dsync.o) and doveadm-mail-batch.o for architecture x86_64 collect2: ld returned 1 exit status make[4]: *** [doveadm] Error 1 when compiling Dovecot 2.2.0. By contrast, 2.1.16 compiled (and runs) just fine. I'm surprised that this hasn't cropped up elsewhere.

Am 18.08.2015 um 11:27 schrieb lhecking at users.sourceforge.net: > >> Maybe so, but still a side issue. Openssl 0.9.8e was recently updated. >> Some change in this update has broken something. I would like to understand >> what, and so ought the package maintainers. C5 isn't EOL until March 2017. > > rpm -q --changelog openssl-0.9.8e. You weren't clear which

I have been reading up on TLS and Dovecot and came across this URL: https://www.weakdh.org/sysadmin.html which recommended these settings for Dovecot. I would like to know if they are correct? Some much documentation on the web is pure garbage. Dovecot These changes should be made in /etc/dovecot.conf Cipher Suites

Hello, Does the recent Logjam[1] vulnerability affect Tinc? The security section of the Tinc website says: "Although tinc uses the OpenSSL library, it does not use the SSL protocol to establish connections between daemons" What would that mean, specifically, in regards to Logjam? Thank you for your time and for providing a great piece of VPN software! [1]