I must retract two cipherlist macros which I tossed out in the email
below. It was late and I was sleepy.
Both 'HIGH:-SSLv3' and 'ECDHE:DHE:-SSLv3' include ciphersuites with NULL
encryption, which means unencrypted. They can be fixed by removing the
nulls:
'HIGH:-SSLv3:-NULL'
and
'ECDHE:DHE:-SSLv3:-NULL'
However, I was just tossing those out as reasonable quickies.
As a privacy enthusiast, I think it would be more valuable to say that I
actually USE this:
'TLSv1.2:ECDHE:DHE:-NULL'
Reasons:
1. It prioritizes the TLS v 1.2 ciphers (all of them)
2. It adds (at the end) the perfect forward secrecy ciphers from SSLv3
as long as they don't have NULL encryption.
3. At the end of the list are about 20 SSLv3 cipher suites that are
pretty good among that group. It includes a couple of 3DES and RC4
ciphersuites, but I'm OK with that considering how weak all of the SSLv3
MAC routines are (i.e. SHA1 and weaker).
4. I think this yields a list which prioritizes strong ciphersuites but
is fairly flexible/tolerant when all else fails. There is no reason that
an old version of openssl cannot connect using one of the twenty SSLv3
ciphersuites it includes.
This cipherlist would be problematic for older machines with openssl <
1.0 because it would not accept the TLSv1.2 and it would add in other
ridiculously weak ciphers which are no longer available in the newer
versions (i.e. > 1.0).
Some thoughts about Eric's list
(ALL:!kRSA:!SRP:!kDHd:!DSS:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK:!RC4:!ADH:!LOW@STRENGTH):
1. It looks imported from old versions of openssl. Many of those are
no longer available.
2. When you start with ALL, you have to be very careful to exclude lots
of the weak stuff. It seems safer to start with strong ciphers and then
add some weaker ones as you see fit.
3. The @STRENGTH macro sorts based upon encryption key size, not
overall strength of the ciphersuite. Therefore a lot of SSLv3
cipersuites are prioritized above TLSv1.2 ciphersuites. That is
suboptimal (in general, in my opinion). Run this to see: /openssl
ciphers -v
'ALL:!kRSA:!SRP:!kDHd:!DSS:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK:!RC4:!ADH:!LOW@STRENGTH'/
I acknowledge that some of these choices are a matter of taste or
implementation, therefore I'm not recommending this for everyone. But I
think it makes for good discussion.
Overall, I'm glad people are interested in this.
-Andy
On 9/3/2019 9:46 PM, 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:
'HIGH:-SSLv3'
If you want "perfect forward secrecy", try this:
'ECDHE:DHE:-SSLv3'
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 end:
https://www.openssl.org/docs/man1.0.2/man1/ciphers.html
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.
-Andy
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.
Carl
*From:*Gary Bowling [mailto:[email protected]]
*Sent:* Tuesday, September 03, 2019 03:35 PM
*To:* [email protected]
*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].
Carl
*From:*Gary Bowling [mailto:[email protected]]
*Sent:* Tuesday, September 03, 2019 02:58 PM
*To:* [email protected]
<mailto:[email protected]>
*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:
echo
"!EDH:!DHE:!RC4:!ADH:!DSS:HIGH:+AES128:+AES256-SHA256:+AES128-SHA256:+SHA:!3DES:!NULL:!aNULL:!eNULL"
> /var/qmail/control/tlsserverciphers
One says to do:
openssl ciphers 'MEDIUM:HIGH:!SSLv2:!MD5:!RC4:!3DES' >
/var/qmail/control/tlsserverciphers
yet another says to create a sym link to the servercert.pem file.
ln -sf /var/qmail/control/servercert.pem
/var/qmail/control/tlsserverciphers
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:
[email protected]
<mailto:[email protected]> For
additional commands, e-mail:
[email protected]
<mailto:[email protected]>
--------------------------------------------------------------------- To
unsubscribe, e-mail: [email protected]
<mailto:[email protected]> For
additional commands, e-mail: [email protected]
<mailto:[email protected]>
---------------------------------------------------------------------
To unsubscribe, e-mail:
[email protected]
<mailto:[email protected]> For
additional commands, e-mail: [email protected]
<mailto:[email protected]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
