similar to: DH Parameter

I?m setting up Dovecot using Homebrew on a new server and am getting this when I try to login via IMAP: Nov 13 14:13:35 auth: Debug: auth client connected (pid=30719) Nov 13 14:13:35 imap-login: Info: Aborted login (no auth attempts in 0 secs): user=<>, rip=::1, lip=::1, secured, session=<gM0HNIN6HtoAAAAAAAAAAAAAAAAAAAAB> Nov 13 14:18:33 auth: Debug: Loading modules from directory:

Actually you need to use ssl_dh=</usr/local/etc/dovecot/dh.pemNote the <Aki -------- Original message --------From: "Michael A. Peters" <mpeters at domblogger.net> Date: 13/11/2018 05:44 (GMT+02:00) To: dovecot at dovecot.org Subject: Re: New install - getting error: "Failed to initialize SSL server context: Couldn't parse DH parameters" tryopenssl dhparam

Hello, from my understanding, using 1024bit DH parameters results in a not sufficiently secure key exchange for DH(E). Therefore I think it would be advisable to have parameters of at least 2048bit . In fact, I would see a great benefit in chosing parameter length arbitrarily. I also do not see the benefit of parameter regeneration. What were the design goals here? Thanks, J?rg L?bbert

http://bugzilla.mindrot.org/show_bug.cgi?id=567 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|critical |major Component|Build system |ssh-keygen Summary|pb at the end of compil with|ssh-keygen: DH parameter

Hello everybody, An issue was reported in RH bugzilla [1] about the size of the used DH group when combined with the 3des-cbc cipher. OpenSSH uses the actual key length for the size estimation. This is probably fine as far as the cipher has the same number of bits of security as the key length. But this is not true for 3TDEA where the key size is 168 resp 192 but it's security is only 112.

On 09/24/2017 12:21 AM, Mark D. Baushke wrote: > I suggest you upgrade to a more recent edition of the OpenSSH software. > The most recent release is OpenSSH 7.5 and OpenSSH 7.6 will be released > very soon. This problem is in v7.5 and v7.6. See dh.c:436. > OpenSSH 6.6 was first released on October 6, 2014. I brought up v6.6 to give an example that older clients wouldn't be

With the default openssh configuration, the selected cipher is aes128-ctr. This means that dh_estimate gets called with bits=128, so dh_estimate selects a DH modulus size of 1024 bits. This seems questionable. Since the NSA seems to be sniffing most internet traffic, keeping SSH sessions secure against after-the-fact offline attack matters, and 1024-bit DH is not convincingly secure against

Here's my config: # 2.3.2 (582970113): /etc/dovecot/dovecot.conf # OS: Linux 4.17.5-1-ARCH x86_64 Arch Linux # Hostname: vault passdb { ? driver = pam } protocols = imap service imap-login { ? inet_listener imap { ??? port = 0 ? } } ssl = required ssl_cert = </etc/letsencrypt/live/myhostname.com/fullchain.pem ssl_cipher_list =

On Fri, 29 May 2015, Hubert Kario wrote: > Not really, no. > > We can use this time an initial seed of "OpenSSH 1024 bit prime, attempt #1". > Next time we generate the primes we can use the initial seed of "2017 OpenSSH > 1024 bit prime, attempt #1", but we can use just as well a "2nd generation > OpenSSH 1024 bit DH parameters, try number 1".

Hi, I'm interested in requiring a minimum of 3072-bit DH moduli when using the "diffie-hellman-group-exchange-sha256" kex, so I edited my /etc/ssh/moduli file such that only 3071+ moduli are left. However, when clients ask for a max of 2048-bit moduli, they actually get one (!). I poked around and found that a fallback mechanism exists (dh.c:185), which returns back the

I did that the last time one year ago, now on another machine with the same software (Ubuntu 16.04) it fails. openssl dhparam 4096 > /var/lib/dovecot/ssl-parameters.dat dd if=/var/lib/dovecot/ssl-parameters.dat bs=1 skip=88 | openssl dhparam -inform der > /etc/dovecot/dh.pem last command fails with 681+0 records in 681+0 records out 681 bytes copied, 0,00278343 s, 245 kB/s unable to load

https://bugzilla.mindrot.org/show_bug.cgi?id=2302 --- Comment #13 from Darren Tucker <dtucker at zip.com.au> --- (In reply to Christoph Anton Mitterer from comment #10) [...] > Even though an attacker cannot (AFAIU??) for a connection to > downgrade to the weaker groups, The server's DH-GEX exchange hash includes the DH group sizes it received from the client. If these are

> On 19 August 2018 at 20:55 Aki Tuomi <aki.tuomi at dovecot.fi> wrote: > > > > > On 19 August 2018 at 19:38 Kai Schaetzl <maillists at conactive.com> wrote: > > > > > > Aki Tuomi wrote on Sun, 19 Aug 2018 18:21:31 +0300: > > > > > Just generate new parameters on some machine with good entropy source. > > > > So, if

On 25 September 2017 at 02:32, Mark D. Baushke <mdb at juniper.net> wrote: > [+CC Loganaden Velvindron <logan at hackers.mu>] primary author of > the RFC 4419 refresh draft. https://datatracker.ietf.org/doc/draft-lvelvindron-curdle-dh-group-exchange/ ? Tangent: has any consideration been given to increasing the maximum allowed beyond 8192 bits (which is below the current NIST

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-06:23.openssl Security Advisory The FreeBSD Project Topic: Multiple problems in crypto(3) Category: contrib Module: openssl Announced:

https://bugzilla.mindrot.org/show_bug.cgi?id=2303 Bug ID: 2303 Summary: ssh (and perhaps even sshd) should allow to specify the minimum DH group sizes for DH GEX Product: Portable OpenSSH Version: 6.7p1 Hardware: All OS: All Status: NEW Severity: security Priority: P5

Hi Aki, On 30/10/2017 12:43 AM, Aki Tuomi wrote: >> On October 29, 2017 at 1:55 PM Reuben Farrelly <reuben-dovecot at reub.net> wrote: >> >> >> Hi again, >> >> Chasing down one last problem which seems to have been missed from my >> last email: >> >> On 20/10/2017 9:22 PM, Stephan Bosch wrote: >>> >>> Op 20-10-2017 om

Hi again, Chasing down one last problem which seems to have been missed from my last email: On 20/10/2017 9:22 PM, Stephan Bosch wrote: > > > Op 20-10-2017 om 4:23 schreef Reuben Farrelly: >> On 18/10/2017 11:40 PM, Timo Sirainen wrote: >>> On 18 Oct 2017, at 6.34, Reuben Farrelly <reuben-dovecot at reub.net> >>> wrote: This problem below is still

On 09/22/2017 06:55 PM, Tim Broberg wrote: > Do I understand correctly, that you find the security of group 14 unacceptable and yet you left it enabled? In the end, I'm trying to ensure a minimum equivalent of 128-bits of security. Group14 is 2048-bits, which roughly translates to 112-bits. [1] To this end, I disabled the "diffie-hellman-group14-sha1" and

I'm using SSL for dovecot, and dovecot kindly warned me on startup that I needed the ssl_dh parameter, which I specified: # grep -P '^ssl_dh' /etc/dovecot/conf.d/10-ssl.conf ssl_dh = </etc/dovecot/dh.pem And I generated the file, as specified in the comment: # openssl dhparam -out /etc/dovecot/dh.pem 4096 The file contains the appropriate headers: # grep -P '^\-'