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

>It is not at this point emphasized anywhere, including on weakdh.org, that it is actually of high importance to regenerate your DH parameters frequently. That's not really correct. If you're using a prime of length at least 2048 bits, then the corresponding discrete-log problem is well-beyond the pre-computation ability of the NSA (or anyone else). It is computationally intensive to

> 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

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

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

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

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

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

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

On Wed, Mar 04, 2015 at 06:36:07PM +0200, Adrian Minta wrote: > Thank you for the answer. > The "!EXPORT" part is included in "ECDH at STRENGTH:DH at STRENGTH:HIGH", or it > must be added as well ? This is not the cipher list I sent. It was: ECDH at STRENGTH:DH at STRENGTH:HIGH:!RC4:!MD5:!DES:!aNULL:!eNUL Mine does not contain any export cipher, yours does. You can

> 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 version you upgraded from, but you mentioned testing against openssl-0.9.8e-27.el5_10.1

On 04.03.2015 18:19, Emmanuel Dreyfus wrote: > On Wed, Mar 04, 2015 at 06:13:31PM +0200, Adrian Minta wrote: >> Hello, >> about the CVE-2015-0204, in apache the following config seems to disable >> this vulnerability: >> SSLProtocol All -SSLv2 -SSLv3 >> SSLCipherSuite >> HIGH:MEDIUM:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4 >> >> Is

On Wed, Mar 04, 2015 at 06:13:31PM +0200, Adrian Minta wrote: > Hello, > about the CVE-2015-0204, in apache the following config seems to disable > this vulnerability: > SSLProtocol All -SSLv2 -SSLv3 > SSLCipherSuite > HIGH:MEDIUM:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4 > > Is something similar possible with dovecot ? I use this with some succes: # dovecot

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]

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

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

In article <55D2ED32.6040000 at hogranch.com>, John R Pierce <pierce at hogranch.com> wrote: > On 8/18/2015 1:27 AM, Tony Mountifield wrote: > >> You should now be using mysql55 on CentOS-5, not mysql-5.0 > > That may well be the case, but isn't relevant to the point I'm making, > > which is that something changed in openssl-0.9.8e-36 that has broken

An update: I found that the "ADD32: output is not int:" messages are caused by the enhancer. When I turn the enhancer off, the messages vanish, but the "freak out" of the codec is still there - so the problem seems not to be related to the overflow messages. best regards, Frank ---------- Urspr?ngliche Nachricht ---------- Von: Frank Lorenz <Frank_wtal at web.de> An:

Hi Jean-Marc, all, I didn't get any response to my issue up to now and would like to now if anyone can reproduce this behaviour and if there is some idea what happens. I am willing to fix this issue, but because I do not know the internals of speex, I need some advice on how to proceed... best regards, Frank Frank Lorenz <Frank_wtal at web.de> hat am 21. Dezember 2009 um 10:49

Hi again. I've realized exactly now that my whole system has freak date/time information on my shares: For example: 01/03/aaaa In Linux the date/times are ok, but in the Windows point of view all the files are wrong. I'm using Samba 3.0.37 with OpenLDAP as my PDC. The date/time of the server is ok, I've checked now and I've run again ntpdate. I've changed permissions and