The problem is, you have to walk a fine line with your “customers”. If they are 
on an old version of Outlook on Windows 7, it’s possible they can’t do TLS 1.2 
or even 1.1… I had a few clients like that and explained that they had to run 
Windows Update to get the W7 system up to TLS 1.1/1.2. The reason they don’t 
see this using web based? The browser can have its own library of TLS. Another 
email client, Thunderbird, has issues as well and you have to be careful as to 
how high you make the settings [unless you can dictate the email client to your 
customer base, then you can demand a client that supports all high level TLS 


And, just putting it on “HIGH” will result in some breakable ciphers being 
used. You really need to run a TLS/SSL scan against your ports to see which 
ones you still have open or in use to make sure you lock down the system 




From: Gary Bowling [] 
Sent: Wednesday, September 04, 2019 09:19 AM
Subject: Re: [qmailtoaster] SSL Problem Dovecot



FYI. I wanted to see in the log files, what version people were using prior to 
making changes. To do that you need to add a %k to the 
login_log_format_elements line in the dovecot configuration. So I added this to 
the /etc/dovecot/local.conf file on my toaster.


login_log_format_elements = user=<%u> method=%m rip=%r lip=%l mpid=%e %c %k


After doing this, and watching the logs. I was surprised to find quite a few 
logins with TLSv1. The log file shows "TLSv1 with cipher ECDHE-RSA-AES256-SHA 
(256/256 bits)"


So much for using HIGH:-SSLv3 in the dovecot config!


I'm not sure how to log the version in qmail. Or even which log it would be in. 


Which also brings up another question. When you require (as we all do now) 
verification of user/password on "send" in the clients. Which is an SMTP 
outgoing server config in most clients. Will that show up in the dovecot logs 
or in the qmail/smtp/send logs? I'm not sure which application does that 


Thanks, Gary


On 9/4/2019 8:04 AM, Gary Bowling wrote:


That's excellent info Andy, many thanks for that!! I'm going to have to go back 
and read it about 10 times and possibly go read the referenced material too!


Questions, I think you are saying that I can put either 'HIGH:-SSLv3' in the 
tlsserverciphers file (and also in the dovecot.conf file) or I can do openssl 
ciphers -v 'HIGH:-SSLv3' > tlsserverciphers to put the full individual ciphers 
in the list?


Can I also put the full individual ciphers in the dovecot.conf? I probably 
wouldn't, but just curious. 


I understand the info about the client/server negotiation. But then you talk 
about other servers, I suppose the server to server delivery over smtp. In that 
scenario, does the sending server send the list of ciphers and the receiving 
server match that to what it has and pick the first overlapping cipher to use?


In the case of dovecot, if you specify a cipher list and also a min protocol, 
I'm assuming it won't use a cipher for something lower than the specified 
protocol, even if it's in the list? Maybe it doesn't offer up a cipher that 
doesn't meet the min protocol spec?


For my server, I'm not sure I care whether I receive mail from a Centos 5 
server. I realize many here are still using them, but it's been out of support 
for a while so it should be either patched or upgraded. I guess bottom line is 
I need to try something like the following:


tlsservercipher contains ''ECDHE:DHE:-SSLv3'   (without the quotes?)

toaster.conf (in the /etc/dovecot/ dir) contains

ssl_cipher_list = ECDHE:DHE:-SSLv3

ssl_min_protocol = TLSv1.2


Then I need to watch logs to see if I have problems. I'm guessing problems 
would show up in both the dovecot.log and the /var/log/qmail/smtp or 
/var/log/qmail/send logs.


Thanks, Gary



On 9/4/2019 1:46 AM, Andrew Swartz wrote:

Some background: 

During the TLS negotiation, the client gives the server a list of ciphers which 
it supports, then from that list the server chooses which one to use. 

The server's cipher list is a list, in order of preference, of the ciphers it 
will use (from the client's list).  If there is no overlap between what the 
client offers and what the server requires, then the connection fails. 

The server dose not use the cipher list itself, but rather just passes the list 
to openssl when it requests establishment of the TLS connection.  Therefore 
essentially all servers/clients use the same format cipherlist. 

The next thing to know is that the list can specify individual ciphers or 
macros like "TLSv1.2".  Most people do not specify individual ciphers but 
rather just use the macros. 

There is no right or wrong for a cipher list, as the most appropriate list is 
the one which best meets your security requirements. 

The cipherlist "builds" a list of ciphers: 

'ALL' adds all of the ciphers (including those with no encrpytion). 

'ALL:-SSLv2' adds all the ciphers and then removes all of the SSLv2 ciphers. 

A reasonable cipherlist is: 

If you want "perfect forward secrecy", try this: 
This will yield a subset of the TLSv1.2 ciphers which has the elliptic-curve 
diffie-hellman-ephemerel ciphers first and then standard 
diffie-hellman-ephemerel ciphers after that. 

If you put that into openssl ciphers ( openssl ciphers -v 'HIGH:-SSLv3') you 
will note that you only get TLSv1.2 ciphers.  That is because an important 
concept is the difference between ciphers and protocols.  TLS 1.0 and 1.1 
updated the protocol but added no new ciphers.  (you can confirm this by 
comparing "openssl ciphers -v 'SSLv3' | md5sum" to "openssl ciphers -v 'TLSv1' 
| md5sum"; you'll get an error if you do it with TLSv1.1 because it does not 
even have a list of ciphers). 

But note that older servers, such as centos 5, will not be able to connect to 
you (if you use 'ECDHE:DHE:-SSLv3') because their old version of openssl does 
not support TLSv1.2.  In that case, for STARTTLS, it will fail, which will 
default to smtp transmission as cleartext.  SMTP is somewhat forgiving, as a 
failed STARTTLS connection will fall back to cleartext, whereas most other TLS 
protocols will fail to connect. 

This is a segway into the related topic of "protocols".  Many servers (like 
dovecot) have separate a setting for "TLS cipherlist" and "TLS protocol".  The 
protocol is the algorithm for establishing the connection, and it is 
independent of the ciphers.  You should avoid the SSLv3 or TLSv1 protocols, as 
the these protocols have been found to have weaknesses in how they negotiate 
the connection (completely unrelated to the strength of the ciphers). 

This manpage is a good explanation of all the macros and has examples at the 

People with older versions of openssl (i.e. Centos 5) cannot do TLSv1.2 and 
will have no choice but to use ciphers/protocols with known weaknesses, and 
then hope that the other servers do not try to force a certain level of 
cipher/protocol.  That is not supposed to happen (per smtp/STARTTLS protocol), 
but I know for a fact that does:  I finally decided to upgrade from centos-5 
because an important mail server started refusing to receive mail from mine, 
with a complaint about not accepting the SSLv3 ciphers.  I think it was Outlook 
Server, but I'm not sure. 

Hope this helps. 


PS: Someone running the old version of openssl will need to put '-SSLv2" at the 
end of the cipherlist, whereas the newer version no longer supports it so it 
doesn't require removing it.  And NO ONE should be using the SSLv2 protocol, as 
hacking it is trivial. 

On 9/3/2019 1:22 PM, CarlC Internet Services Service Desk wrote: 

Actually, doing the openssl ciphers > /var/qmail/control/tlsservercipher is a 
starting point. 

After I did that, I then ran my server through some tests. I happen to use 
OpenVAS [which tool you want to use to find insecure SSL connections is up to 
you]. It was able to tell me which ciphers to disable and why. Whichever 
product you use to test the SSL should be one that’s up to date [or can be 
brought up to date]. For example, I run the tests against my email server every 
week [for example, I test against port 25, 465 and 587]. In my case, I also use 
OpenVAS to test the HTTPS side as well. 

If you’re using dovecot, you will want to also put the ssl_cipher_list in 
/etc/dovecot/dovecot.conf as well as the ssl_protocols list. This protects your 
IMAPS and POP3S protocols. Again, OpenVAS is set to run against those protocols 
as well. 


*From:*Gary Bowling [] 
*Sent:* Tuesday, September 03, 2019 03:35 PM 
*Subject:* Re: [qmailtoaster] SSL Problem Dovecot 

Thanks for that Carl. I'm running openssl-1.0.2k-16.el7_6.1.x86_64 

Pretty much everything about my server is continuously updated stock Centos 7. 
Currently at CentOS Linux release 7.6.1810 (Core) 

I do have epel installed, which updates some things and the qmt repo. That's 
it, and I'm a stickler for NOT installing anything that isn't done through yum 
and those repos. I've done this long enough to know that it's much easier to 
maintain, migrate to a new server, etc. is you're running everything in a 
managed way. So installing the repos and doing yum installs is pretty much the 
only way anything ever changes on my server, sans config files. 

Would be very interested in knowing not only the proper tlsservercipher file 
for this type of server, but also how to create/recreate it if it's a command 
done from openssl. Looks like you can create it with the command. 

openssl ciphers > /var/qmail/control/tlsservercipher 

But what I'm reading is that your advice is to NOT do that due to security 
concerns. So what would you recommend? 

Thanks, Gary 

On 9/3/2019 3:28 PM, CarlC Internet Services Service Desk wrote: 

    Your real problem is that this file is different based on which 
    CentOS you’re on [or should I say, which openssl is loaded]. If you 
    have CentOS 7, with openssl 1.0.2k, you can tune this file to 
    include each cipher you want [the file can actually be 10+ lines 
    long wrapped]. This is so you can remove all the “hacked” ciphers, 
    especially to force your clients security to remain high. If your 
    running openssl 0.9.x, you don’t get the newer TLS ciphers you need 
    to be secure. 

    Using the default is way too low, and if you do, you will where 
    someone gets hacked over a ‘free’ WiFi connection [because you had 
    SSL 3.0/TLS 1.0 on]. 


    *From:*Gary Bowling [] 
    *Sent:* Tuesday, September 03, 2019 02:58 PM 
    *Subject:* Re: [qmailtoaster] SSL Problem Dovecot 

    So this may be an issue of the tlsserverciphers file. Some times 
    it's interesting not knowing what your doing! haha 

    I guess the question I have is.. What is the proper tlsserverciphers 
    for a qmailtoaster with a letsencrypt certificate. If that even 
    makes sense. 

    And what is the proper way to actually do it. I've read multiple 
    things on various forums, including here. 

    One says to do: 

     > /var/qmail/control/tlsserverciphers 

    One says to do: 

    openssl ciphers 'MEDIUM:HIGH:!SSLv2:!MD5:!RC4:!3DES' > 

    yet another says to create a sym link to the servercert.pem file. 

    ln -sf /var/qmail/control/servercert.pem 

    I guess it has to do with how tight you want security to be and 
    maybe tlsserverciphers can contain various forms of how to define 
    that. Just looking for what "most" people would use for an up to 
    date Centos 7 server. 

    Thanks, Gary 

    On 9/3/2019 11:04 AM, Gary Bowling wrote: 

        I had to get a new cert for my server, which I installed 
        yesterday. Now I'm having problems with certain clients logging 
        in. I get the following error in the dovecot.log. 

        TLS handshaking: SSL_accept() failed: error:1408A10B:SSL 
        routines: ssl3_get_client_hello:wrong version number 

        Any help would be appreciated. 

        Thanks, Gary 

        --         ____________________ 
        Gary Bowling 

        To unsubscribe, e-mail: 
<> For 
        additional commands, e-mail: 

    --------------------------------------------------------------------- To 
    unsubscribe, e-mail: 
<> For 
    additional commands, e-mail: 

--------------------------------------------------------------------- To 
unsubscribe, e-mail: 
<> For additional 
commands, e-mail: 

To unsubscribe, e-mail: 
For additional commands, e-mail: 

--------------------------------------------------------------------- To 
unsubscribe, e-mail: 
<>  For additional 
commands, e-mail: 

--------------------------------------------------------------------- To 
unsubscribe, e-mail: 
<>  For additional 
commands, e-mail: 

Reply via email to