|
Thanks Carl. Unfortunately for my server, all of those
suggestions are too tight to work with my clients.
However, I did find this web page that offers some good info on
ciphers.
https://cheatsheetseries.owasp.org/cheatsheets/TLS_Cipher_String_Cheat_Sheet.html
This was a pertinent couple of bullet points from the above web
page that helped me understand what to remove and/or what was
reasonably secure to include in the ciphers lists.
"Do not use WEAK ciphers based on 3DES e.g.
(TLS_RSA_WITH_3DES_EDE_CBC_SHA, DES-CBC3-SHA)
Never use even more INSECURE or elder ciphers based on RC2,
RC4, DES, MD4, MD5, EXP, EXP1024, AH, ADH, aNULL, eNULL, SEED
nor IDEA."
I went through my tlsserverciphers list and found a number of ADH
and SEED ciphers and removed them.
For Dovecot, it's easy to find out what ciphers clients are using
by modifying the config line as we previously discussed.
However, I'm not sure how to find out what cipers are being used
in qmail?? I've searched through logs and don't find any info on
ciphers and of course changing verbosity on qmail logs isn't
something you can do (or at least something I don't know how to
do).
Gary
On 9/4/2019 3:43 PM, Andrew Swartz
wrote:
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:g...@gbco.us]
*Sent:* Tuesday, September 03, 2019 03:35 PM
*To:* qmailtoaster-list@qmailtoaster.com
*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:g...@gbco.us]
*Sent:* Tuesday, September 03, 2019 02:58 PM
*To:* qmailtoaster-list@qmailtoaster.com
<mailto:qmailtoaster-list@qmailtoaster.com>
*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:
qmailtoaster-list-unsubscr...@qmailtoaster.com
<mailto:qmailtoaster-list-unsubscr...@qmailtoaster.com>
For
additional commands, e-mail:
qmailtoaster-list-h...@qmailtoaster.com
<mailto:qmailtoaster-list-h...@qmailtoaster.com>
---------------------------------------------------------------------
To
unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
<mailto:qmailtoaster-list-unsubscr...@qmailtoaster.com>
For
additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
<mailto:qmailtoaster-list-h...@qmailtoaster.com>
--------------------------------------------------------------------- To
unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
<mailto:qmailtoaster-list-unsubscr...@qmailtoaster.com>
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
<mailto:qmailtoaster-list-h...@qmailtoaster.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
|
