similar to: [PATCH] Add support for lower TLS version than default

On 27 August 2017 08:32:06 CEST, Timo Sirainen <tss at iki.fi> wrote: >> DEF(SET_STR, ssl_protocols), >> DEF(SET_STR, ssl_cert_username_field), >> DEF(SET_STR, ssl_crypto_device), >> + DEF(SET_STR, ssl_lowest_version), > >Does it really require a new setting? Couldn't it use the existing >ssl_protocols setting? You need to set a minimal version.

Hi, I came up with the following patch while trying to figure out a good solution for the situation described in Debian bug #871987[1]. In short, OpenSSL in Debian unstable has disabled TLSv1.0 and TLSv1.1 *by default*. That means that unless an application requests otherwise, only TLSv1.2 is supported. In the world of e-mail this is seemingly an issue, as there are still way too many old clients

On 26 Aug 2017, at 19.47, Sebastian Andrzej Siewior <sebastian at breakpoint.cc> wrote: > > The openssl library in Debian unstable (targeting Buster) supports > TLS1.2 by default. The library itself supports also TLS1.1 and TLS1.0. > If the admin decides to also support TLS1.[01] users he can then enable > the lower protocol version in case the users can't update their

On 2017-08-27 13:46, Sebastian Andrzej Siewior wrote: > On 27 August 2017 08:32:06 CEST, Timo Sirainen <tss at iki.fi> wrote: >>> DEF(SET_STR, ssl_protocols), >>> DEF(SET_STR, ssl_cert_username_field), >>> DEF(SET_STR, ssl_crypto_device), >>> + DEF(SET_STR, ssl_lowest_version), >> Does it really require a new setting? Couldn't it use the

Hi all, As I reported earlier (with a typo in the work [BUG]) client certification validation *does not* work even if you do everything exactly according to all documentation and attempts at helpful advice. I have seen this issue with both startssl.com and self-signed certificates, and based on what I've seen from searching the web, this is a problem that has gotten little attention because

# HG changeset patch # User David Hicks <david at hicks.id.au> # Date 1373085976 -36000 # Sat Jul 06 14:46:16 2013 +1000 # Node ID ccd83f38e4b484ae18f69ea08631eefcaf6a4a4e # Parent 1fbac590b9d4dc05d81247515477bfe6192c262c login-common: Add support for ECDH/ECDHE cipher suites ECDH temporary key parameter selection must be performed during OpenSSL context initialisation before ECDH and

Hi, I've read at least one e-mail on this list about making delivered-to in lmtpd optional, but now I need this too, so I made a patch. The default remains as is now (enabled). Rationale: I would like to dsync users and I have catchall POP mailboxes (meaning: a single mailbox gets the mails for a lot of e-mail addresses). If I deliver the e-mails to Dovecot's lmtpd as the original

This is driven by the fact that OpenSSL 1.1 does not know about SSLv2 at all and dovecot's defaults simply make OpenSSL error out with "Unknown protocol 'SSLv2'"[1]. So we change the defaults to refer to SSLv2 iff OpenSSL seems to know something about it. While at it, it's also a good idea to disable SSLv3 by default as well. [1] https://bugs.debian.org/844347

I've installed grep PRETTY /etc/os-release PRETTY_NAME="Fedora 32 (Server Edition)" dovecot --version 2.3.10.1 (a3d0e1171) openssl version OpenSSL 1.1.1g FIPS 21 Apr 2020 iiuc, Dovecot has apparently had support for setting TLS 1.3 ciphersuites since v2.3.9, per this commit lib-ssl-iostream: Support TLSv1.3 ciphersuites

Sure did! I am even playing with different options (including NONE) and it seems to ignore the contents of ssl.conf I have tried Environment=G_TLS_GNUTLS_PRIORITY=NORMAL:+TLS1.2:!TLS1.1:!TLS1.0:!ECDHE-RSA-AES256-SHA: Environment=G_TLS_GNUTLS_PRIORITY=NORMAL:+TLS1.2:!TLS1.1:!TLS1.0:!ECDHE-RSA-AES256-SHA Environment=G_TLS_GNUTLS_PRIORITY=PFS

I've just noticed that Dovecot 1.0-stable and 1.0-test78 don't include mbox folders with names beginning with "." in the IMAP LIST output. These are often used to store "hidden" folders for storing things like IMAP client configuration (e.g. Pine 4.x, IMHO, Prayer). Usually the user shouldn't be able to see these, but there are occassions when they might. It seems

I went from a nightly of about 20051117 or so (about alpha4 generation) to 1.0beta1 yesterday, and dovecot is now spinning the CPU furiously apparently every ~10 minutes per: Jan 18 13:04:36 server dovecot: SSL parameters regeneration completed Jan 18 13:14:14 server dovecot: SSL parameters regeneration completed Jan 18 13:24:00 server dovecot: SSL parameters regeneration completed Jan 18

On Fri, 25 Mar 2016 16:50, Eero Volotinen wrote: > > Stop paranoia? Tlsv1.0 is not recommended when storing credit card data. > > Eero > Hi List, > > Does anyone know why the above URL is still using TLS V1.0. > > I can't connect to it unless I enable TLS V1.0 which I was under the > impression that it should not be used > anymore. > > Thanks for any

Thanks, Randal for the response. But it did not work. Here the results: #yum info cockpit Name : cockpit Arch : x86_64 Version : 195.1 Release : 1.el7.centos.0.1 Size : 51 k Repo : installed >From repo : extras Summary : Web Console for Linux servers URL : https://cockpit-project.org/ License : LGPLv2+ [root at cockpit ~]# cat

On Thu, Oct 13, 2016 at 8:48 AM Christian Kivalo <ml+dovecot at valo.at> wrote: > > > > > Am 13. Oktober 2016 08:41:06 MESZ, schrieb arnaud gaboury < > arnaud.gaboury at gmail.com>: > > >I run dovecot + postfix as my email server. Everything is working as > > >expected, but I see an error in the dovecot logs: > > > > > >lmtp(7331):

On 25.03.2016 17:29, Eero Volotinen wrote: >> @Eero: IMHO you are missing some points here. There are more and more >> browsers that are unable to use SSL{2,3} as well as TLS1.0, not just >> disabled via config, but this decission was made at compile time. >> Newer Android and Apple-iOS devices for example. >> >> > This is not true. it works fine with latest

> @Eero: IMHO you are missing some points here. There are more and more > browsers that are unable to use SSL{2,3} as well as TLS1.0, not just > disabled via config, but this decission was made at compile time. > Newer Android and Apple-iOS devices for example. > > This is not true. it works fine with latest android and ios. I just tested it. > And the point is not that the

Oops, excuse my typo Create /etc/systemd/system/cockpit.service.d/ssl.conf containing [Service] Environment=G_TLS_GNUTLS_PRIORITY=NORMAL:-VERS-SSL3.0:-VERS-TLS1.0:-VERS-TLS1.1 Then systemctl daemon-reload systemctl restart cockpit To verify that TLS 1.1 is disabled, echo test | openssl s_client -connect localhost:9090 -tls1_1 2>&1 | grep -e Protocol -e Cipher The expected result is:

In lib-storage/index/maildir/maildir-storage.c maildir_is_valid_create_name() and maildir_is_valid_existing_name() the following sequence of tests appear but I don't really understand why if ((storage->flags & MAIL_STORAGE_FLAG_FULL_FS_ACCESS) != 0) return TRUE; if (*name == '~' || strchr(name, '/') != NULL) return FALSE; If MAIL_STORAGE_FLAG_FULL_FS_ACCESS is

CentOS 7 Dovecot 2.2.36 Nov 14 07:13:08 mail dovecot: pop3-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=73.0.0.0, lip=192.64.118.242, TLS handshaking: SSL_accept() failed: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher, session=<> Was working fine for over a year, until the cert expired and I replaced it. I've tried the good cert I have for