Re: [qmailtoaster] SSL Problem Dovecot

[Gary Bowling]

  
  


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
 

Re: [qmailtoaster] SSL Problem Dovecot

[Andrew Swartz]

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 

Re: [qmailtoaster] SSL Problem Dovecot

[Gary Bowling]

  
  


Correct, the default is 

ssl_min_protocol = TLSv1


which is newer than SSLv3 and SSLv2 is no longer even supported
  at all. 



So effectively the default is the same as your old list of
  TLSv1.2 TLSv1.1 TLSv1 !SSLv3 !SSLv2


Gary



On 9/4/2019 1:51 PM, CarlC Internet
  Services Service Desk wrote:


  
  
  
  
Yup,
turns out that’s a left over from before Dovecot 2.2…. It
was getting ignored and the default is TLSv1.
 
Removed
from my config as obsolete.
Carl
 

  
From:
Gary Bowling [mailto:g...@gbco.us] 
Sent: Wednesday, September 04, 2019 01:44 PM
To: qmailtoaster-list@qmailtoaster.com
Subject: Re: [qmailtoaster] SSL Problem Dovecot
  

 
 
Carl, when I put that statement in my dovecot conf I get the
  following in my log on startup.

  Sep 04 13:39:41 config: Warning: Obsolete setting in
  /etc/dovecot/local.conf:22: ssl_protocols has been replaced by
  ssl_min_protocol
  Sep 04 13:39:41 config: Error: Could not find a minimum
  ssl_min_protocol setting from ssl_protocols = TLSv1.2 TLSv1.1
  TLSv1 !SSLv3 !SSLv2: Unrecognized protocol 'SSLv2'
 
Thanks, Gary 
 

  On 9/4/2019 1:20 PM, CarlC Internet
Services Service Desk wrote:


  

  

  For Dovecot, I use
   
  ssl_protocols = TLSv1.2
  TLSv1.1 TLSv1 !SSLv3 !SSLv2
   
  Then under
  ssl_cipher_list, I have a long list of ciphers
  [and blocked ones] that start with the strongest
  and work downward from there. When I run a scan against
  IMAPS, any that are found to be compromised, I
  change the list to match. This is why I don’t list
  mine as its fluid based on the latest scans.
   
  $0.02,
  Carl

  

  

-
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

RE: [qmailtoaster] SSL Problem Dovecot

[CarlC Internet Services Service Desk]

Yup, turns out that’s a left over from before Dovecot 2.2…. It was getting 
ignored and the default is TLSv1.

 

Removed from my config as obsolete.

Carl

 

From: Gary Bowling [mailto:g...@gbco.us] 
Sent: Wednesday, September 04, 2019 01:44 PM
To: qmailtoaster-list@qmailtoaster.com
Subject: Re: [qmailtoaster] SSL Problem Dovecot

 

 

Carl, when I put that statement in my dovecot conf I get the following in my 
log on startup.


Sep 04 13:39:41 config: Warning: Obsolete setting in 
/etc/dovecot/local.conf:22: ssl_protocols has been replaced by ssl_min_protocol
Sep 04 13:39:41 config: Error: Could not find a minimum ssl_min_protocol 
setting from ssl_protocols = TLSv1.2 TLSv1.1 TLSv1 !SSLv3 !SSLv2: Unrecognized 
protocol 'SSLv2'

 

Thanks, Gary 

 

On 9/4/2019 1:20 PM, CarlC Internet Services Service Desk wrote:

For Dovecot, I use

 

ssl_protocols = TLSv1.2 TLSv1.1 TLSv1 !SSLv3 !SSLv2

 

Then under ssl_cipher_list, I have a long list of ciphers [and blocked ones] 
that start with the strongest and work downward from there. When I run a scan 
against IMAPS, any that are found to be compromised, I change the list to 
match. This is why I don’t list mine as its fluid based on the latest scans.

 

$0.02,

Carl

- To 
unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com 
  For additional 
commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com 
  

Re: [qmailtoaster] SSL Problem Dovecot

[Gary Bowling]

  
  


Carl, when I put that statement in my dovecot conf I get the
  following in my log on startup.


  Sep 04 13:39:41 config: Warning: Obsolete setting in
  /etc/dovecot/local.conf:22: ssl_protocols has been replaced by
  ssl_min_protocol
  Sep 04 13:39:41 config: Error: Could not find a minimum
  ssl_min_protocol setting from ssl_protocols = TLSv1.2 TLSv1.1
  TLSv1 !SSLv3 !SSLv2: Unrecognized protocol 'SSLv2'



Thanks, Gary 



On 9/4/2019 1:20 PM, CarlC Internet
  Services Service Desk wrote:


  
  
  
  

  

  
For Dovecot, I use
 
ssl_protocols = TLSv1.2
TLSv1.1 TLSv1 !SSLv3 !SSLv2
 
Then under
ssl_cipher_list, I have a long list of ciphers [and
blocked ones] that start with the strongest and work
downward from there. When I run a scan against
IMAPS, any that are found to be compromised, I
change the list to match. This is why I don’t list
mine as its fluid based on the latest scans.
 
$0.02,
Carl
  

  

  

  


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] SSL Problem Dovecot

[Eric Broch]

Hi Carl,
I have no ssl_protocols, but I do have ssl_min_protocol
Eric

On Wed, Sep 4, 2019 at 11:20 AM CarlC Internet Services Service Desk <
ab...@carlc.com> wrote:

> For Dovecot, I use
>
>
>
> ssl_protocols = TLSv1.2 TLSv1.1 TLSv1 !SSLv3 !SSLv2
>
>
>
> Then under ssl_cipher_list, I have a long list of ciphers [and blocked
> ones] that start with the strongest and work downward from there. When I
> run a scan against IMAPS, any that are found to be compromised, I change
> the list to match. This is why I don’t list mine as its fluid based on the
> latest scans.
>
>
>
> $0.02,
>
> Carl
>
>

Re: [qmailtoaster] SSL Problem Dovecot

[Gary Bowling]

  
  


Thanks for that Carl. I will try that in my dovecot. 



An interesting note.. The default dovecot ciphers are
ALL:!kRSA:!SRP:!kDHd:!DSS:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK:!RC4:!ADH:!LOW@STRENGTH


When I did a 

openssl ciphers
'ALL:!kRSA:!SRP:!kDHd:!DSS:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK:!RC4:!ADH:!LOW@STRENGTH' 
  > /var/qmail/control/tlsserverciphers


I could then not longer send to the qmailtoaster list!!   haha...



Gary

On 9/4/2019 1:20 PM, CarlC Internet
  Services Service Desk wrote:


  
  
  
  

  

  
For Dovecot, I use
 
ssl_protocols = TLSv1.2
TLSv1.1 TLSv1 !SSLv3 !SSLv2
 
Then under
ssl_cipher_list, I have a long list of ciphers [and
blocked ones] that start with the strongest and work
downward from there. When I run a scan against
IMAPS, any that are found to be compromised, I
change the list to match. This is why I don’t list
mine as its fluid based on the latest scans.
 
$0.02,
Carl
  

  

  

  


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] SSL Problem Dovecot

[Gary Bowling]

  
  


Interesting. Thanks for the doveconf -a command, didn't know
  about that one. Also shows that I have 

ssl_prefer_server_ciphers = no


Which might need to be changed to "yes"


Gary 



On 9/4/2019 11:21 AM, Eric Broch wrote:


  
  

  

  

  
You can find out your Dovecot cipher
  list with this command:
  # doveconf -a | grep cipher
  ssl_cipher_list =
ALL:!kRSA:!SRP:!kDHd:!DSS:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK:!RC4:!ADH:!LOW@STRENGTH
  
  
  
  I changed the Dovecot cipher list to point to
a file and it works fine with above settings in
the file.
  ssl_cipher_list =

  
  
  
  When I changed the Dovecot cipher list to
point to qmail's ciphers
  ssl_cipher_list =

  
  I Get errors in the Dovecot log: imap-login:
Error: Failed to initialize SSL server context:
Can't set cipher list to (output list below).
  
  
  
  
  
  
  
]# cat /var/qmail/control/tlsclientciphers
DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:ADH-SEED-SHA:SEED-SHA:IDEA-CBC-SHA:KRB5-IDEA-CBC-SHA:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:AECDH-AES256-SHA:ADH-AES256-GCM-SHA384:ADH-AES256-SHA256:ADH-AES256-SHA:ADH-CAMELLIA256-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:AECDH-AES128-SHA:ADH-AES128-GCM-SHA256:ADH-AES128-SHA256:ADH-AES128-SHA:ADH-CAMELLIA128-SHA:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:CAMELLIA128-SHA:PSK-AES128-CBC-SHA
  
  
  

  

  

  

  
  
  
On Wed, Sep 4, 2019 at 9:02 AM
  CarlC Internet Services Service Desk 
  wrote:


  

  Gary,
   
  https://www.immuniweb.com/ssl/
is perfect way to test. I think everyone agrees, we just
don’t want to set it “X” and assume it’s the best.
   
  Since Dovecot can use a different
encryption list than Qmail, that’s why you need to test
each port. I think you got the main idea of it now.
   
  Carl
   
  

  From:
  Gary Bowling [mailto:g...@gbco.us]
  
  Sent: Wednesday, September 04, 2019 10:50
  AM
  To: qmailtoaster-list@qmailtoaster.com
  Subject: Re: [qmailtoaster] SSL Problem
  Dovecot

  
   
   
  Yes it's a bit tricky for sure. Phones for email, which
I have a lot of. I have a customer with a fax machine
that emails faxes, so it has an email account configured
in it. All these things run TLSv1 and aren't things I
can dictate go away.
   
  I also found that squirrelmail uses TLSv1 and
ECDHE-RSA-AES256-SHA. Since it's logging in from

RE: [qmailtoaster] SSL Problem Dovecot

[CarlC Internet Services Service Desk]

For Dovecot, I use

 

ssl_protocols = TLSv1.2 TLSv1.1 TLSv1 !SSLv3 !SSLv2

 

Then under ssl_cipher_list, I have a long list of ciphers [and blocked ones] 
that start with the strongest and work downward from there. When I run a scan 
against IMAPS, any that are found to be compromised, I change the list to 
match. This is why I don’t list mine as its fluid based on the latest scans.

 

$0.02,

Carl

RE: [qmailtoaster] Qmail Toaster Repos Timing Out

[Matt Weakly]

ping ftp.whitehorsetc.com
PING whitehorsetc.com (66.62.95.221) 56(84) bytes of data.
64 bytes from 66-62-95-221.cybernet1.com (66.62.95.221): icmp_seq=1 ttl=50 
time=147 ms
…
ping qmt-server.carlc.com
PING qmt-server.carlc.com (72.35.89.3) 56(84) bytes of data.
64 bytes from qmt-server.carlc.com (72.35.89.3): icmp_seq=1 ttl=50 time=58.2 ms
…

ftp://qmt-server.carlc.com/pub/repo/qmt/CentOS/7/current/x86_64/ & 
ftp://ftp.whitehorsetc.com/pub/repo/qmt/CentOS/7/current/x86_64/ work fine:
[cid:image001.png@01D5630F.D3873350]

curl 
ftp://ftp.whitehorsetc.com/pub/repo/qmt/CentOS/7/current/x86_64/repodata/repomd.xml
curl: (7) Failed connect to ftp.whitehorsetc.com:21; Connection timed out

curl 
ftp://qmt-server.carlc.com/pub/repo/qmt/CentOS/7/current/x86_64/repodata/repomd.xml
curl: (7) Failed connect to qmt-server.carlc.com:21; Connection timed out

Uhm - Eric, FTP in the server’s network is blocked…website loads from desktop, 
but failed curl from server (via ssh) was the clue…I’ll use a different 
server/network...and let you know how it goes…

Thanks Eric!!

From: Eric Broch 
Sent: Wednesday, September 4, 2019 10:40 AM
To: qmailtoaster-list@qmailtoaster.com
Subject: Re: [qmailtoaster] Qmail Toaster Repos Timing Out

Try (and let me know the output)
# ping ftp.whitehorsetc.com
# ping qmt-server.carlc.com

Can you go directly to the web sites?
ftp://qmt-server.carlc.com/pub/repo/qmt/CentOS/7/current/x86_64/
ftp://ftp.whitehorsetc.com/pub/repo/qmt/CentOS/7/current/x86_64/

Run the following commands and let me know the output
# curl 
ftp://ftp.whitehorsetc.com/pub/repo/qmt/CentOS/7/current/x86_64/repodata/repomd.xml
# curl 
ftp://qmt-server.carlc.com/pub/repo/qmt/CentOS/7/current/x86_64/repodata/repomd.xml

Let me know the output

On Wed, Sep 4, 2019 at 9:32 AM Matt Weakly mailto:m...@fes.org>> 
wrote:
I have the same issue as Roxanne, identical qmt.repo and qmt-mirrorlist-current…

CentOS7 (OpenVZ).

yum –y install … error (qt_install.sh):
…
ftp://qmt-server.carlc.com/pub/repo/qmt/CentOS/7/current/x86_64/repodata/repomd.xml:
 [Errno 12] Timeout on 
ftp://qmt-server.carlc.com/pub/repo/qmt/CentOS/7/current/x86_64/repodata/repomd.xml:
 (28, 'Connection timed out after 30001 milliseconds')
Trying other mirror.
ftp://ftp.whitehorsetc.com/pub/repo/qmt/CentOS/7/current/x86_64/repodata/repomd.xml:
 [Errno 12] Timeout on 
ftp://ftp.whitehorsetc.com/pub/repo/qmt/CentOS/7/current/x86_64/repodata/repomd.xml:
 (28, 'Connection timed out after 30001 milliseconds')
…

Thanks!!
Matt

Re: [qmailtoaster] SSL Problem Dovecot

[Eric Broch]

You can find out your Dovecot cipher list with this command:
# doveconf -a | grep cipher
ssl_cipher_list =
ALL:!kRSA:!SRP:!kDHd:!DSS:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK:!RC4:!ADH:!LOW@STRENGTH

I changed the Dovecot cipher list to point to a file and it works fine with
above settings in the file.
ssl_cipher_list =  wrote:

> Gary,
>
>
>
> https://www.immuniweb.com/ssl/
> 
> is perfect way to test. I think everyone agrees, we just don’t want to set
> it “X” and assume it’s the best.
>
>
>
> Since Dovecot can use a different encryption list than Qmail, that’s why
> you need to test each port. I think you got the main idea of it now.
>
>
>
> Carl
>
>
>
> *From:* Gary Bowling [mailto:g...@gbco.us]
> *Sent:* Wednesday, September 04, 2019 10:50 AM
> *To:* qmailtoaster-list@qmailtoaster.com
> *Subject:* Re: [qmailtoaster] SSL Problem Dovecot
>
>
>
>
>
> Yes it's a bit tricky for sure. Phones for email, which I have a lot of. I
> have a customer with a fax machine that emails faxes, so it has an email
> account configured in it. All these things run TLSv1 and aren't things I
> can dictate go away.
>
>
>
> I also found that squirrelmail uses TLSv1 and ECDHE-RSA-AES256-SHA. Since
> it's logging in from 127.0.0.1 to 127.0.0.1 it's not a problem. But it IS a
> problem for setting these things in the server.
>
>
>
> At this point, I have NO ssl_cipher_list configured in dovecot, so it's
> using whatever the default is. I set it back this way (that's what it was
> when I started this exercise) because everything I configured caused me
> problems. I need to leave the users alone for a bit so they can get some
> work done :)
>
>
>
> With it set this way, I scanned my server using
> https://www.immuniweb.com/ssl/
> 
>
>
>
> Looks like it scans both the mail protocols and the web protocols. The
> only big problem is shows is the use of TLSv1, which I'm not sure I can do
> anything about at this point.
>
>
>
> There are a few other things it points out that I need to look in to..
>
> - Doesn't support TLSv1.3. Not sure I can do anything about this one as I
> would assume it requires an update to openssl.
>
> - The server does not prefer cipher suites. Need to do some research on
> this one.
>
> - The server does not enforce HTTP Strict Transport Security. FIXED by
> adding the following to my virtualhost.
>
> Header always set Strict-Transport-Security "max-age=63072000;
> includeSubdomains;"
>
>
>
> Gary
>
>
>
>

Re: [qmailtoaster] Qmail Toaster Repos Timing Out

[Eric Broch]

Try (and let me know the output)
# ping ftp.whitehorsetc.com
# ping qmt-server.carlc.com

Can you go directly to the web sites?
ftp://qmt-server.carlc.com/pub/repo/qmt/CentOS/7/current/x86_64/
ftp://ftp.whitehorsetc.com/pub/repo/qmt/CentOS/7/current/x86_64/

Run the following commands and let me know the output
# curl
ftp://ftp.whitehorsetc.com/pub/repo/qmt/CentOS/7/current/x86_64/repodata/repomd.xml
# curl
ftp://qmt-server.carlc.com/pub/repo/qmt/CentOS/7/current/x86_64/repodata/repomd.xml

Let me know the output

On Wed, Sep 4, 2019 at 9:32 AM Matt Weakly  wrote:

> I have the same issue as Roxanne, identical qmt.repo and
> qmt-mirrorlist-current…
>
>
>
> CentOS7 (OpenVZ).
>
>
>
> yum –y install … error (qt_install.sh):
>
> …
>
>
> ftp://qmt-server.carlc.com/pub/repo/qmt/CentOS/7/current/x86_64/repodata/repomd.xml:
> [Errno 12] Timeout on
> ftp://qmt-server.carlc.com/pub/repo/qmt/CentOS/7/current/x86_64/repodata/repomd.xml:
> (28, 'Connection timed out after 30001 milliseconds')
>
> Trying other mirror.
>
>
> ftp://ftp.whitehorsetc.com/pub/repo/qmt/CentOS/7/current/x86_64/repodata/repomd.xml:
> [Errno 12] Timeout on
> ftp://ftp.whitehorsetc.com/pub/repo/qmt/CentOS/7/current/x86_64/repodata/repomd.xml:
> (28, 'Connection timed out after 30001 milliseconds')
>
> …
>
>
>
> Thanks!!
>
> Matt
>

Re: [qmailtoaster] Qmail Toaster Repos Timing Out

[Matt Weakly]

I have the same issue as Roxanne, identical qmt.repo and 
qmt-mirrorlist-current...

CentOS7 (OpenVZ).

yum -y install ... error (qt_install.sh):
...
ftp://qmt-server.carlc.com/pub/repo/qmt/CentOS/7/current/x86_64/repodata/repomd.xml:
 [Errno 12] Timeout on 
ftp://qmt-server.carlc.com/pub/repo/qmt/CentOS/7/current/x86_64/repodata/repomd.xml:
 (28, 'Connection timed out after 30001 milliseconds')
Trying other mirror.
ftp://ftp.whitehorsetc.com/pub/repo/qmt/CentOS/7/current/x86_64/repodata/repomd.xml:
 [Errno 12] Timeout on 
ftp://ftp.whitehorsetc.com/pub/repo/qmt/CentOS/7/current/x86_64/repodata/repomd.xml:
 (28, 'Connection timed out after 30001 milliseconds')
...

Thanks!!
Matt

RE: [qmailtoaster] SSL Problem Dovecot

[CarlC Internet Services Service Desk]

Gary,

 

https://www.immuniweb.com/ssl/ 

  is perfect way to test. I think everyone agrees, we just don’t want to set it 
“X” and assume it’s the best.

 

Since Dovecot can use a different encryption list than Qmail, that’s why you 
need to test each port. I think you got the main idea of it now.

 

Carl

 

From: Gary Bowling [mailto:g...@gbco.us] 
Sent: Wednesday, September 04, 2019 10:50 AM
To: qmailtoaster-list@qmailtoaster.com
Subject: Re: [qmailtoaster] SSL Problem Dovecot

 

 

Yes it's a bit tricky for sure. Phones for email, which I have a lot of. I have 
a customer with a fax machine that emails faxes, so it has an email account 
configured in it. All these things run TLSv1 and aren't things I can dictate go 
away.

 

I also found that squirrelmail uses TLSv1 and ECDHE-RSA-AES256-SHA. Since it's 
logging in from 127.0.0.1 to 127.0.0.1 it's not a problem. But it IS a problem 
for setting these things in the server.

 

At this point, I have NO ssl_cipher_list configured in dovecot, so it's using 
whatever the default is. I set it back this way (that's what it was when I 
started this exercise) because everything I configured caused me problems. I 
need to leave the users alone for a bit so they can get some work done :)

 

With it set this way, I scanned my server using https://www.immuniweb.com/ssl/ 

 

 

Looks like it scans both the mail protocols and the web protocols. The only big 
problem is shows is the use of TLSv1, which I'm not sure I can do anything 
about at this point. 

 

There are a few other things it points out that I need to look in to.. 

- Doesn't support TLSv1.3. Not sure I can do anything about this one as I would 
assume it requires an update to openssl.

- The server does not prefer cipher suites. Need to do some research on this 
one.

- The server does not enforce HTTP Strict Transport Security. FIXED by adding 
the following to my virtualhost.

Header always set Strict-Transport-Security "max-age=63072000; 
includeSubdomains;"

 

Gary

 

Re: [qmailtoaster] SSL Problem Dovecot

[Gary Bowling]

  
  


Yes it's a bit tricky for sure. Phones for email, which I have a
  lot of. I have a customer with a fax machine that emails faxes, so
  it has an email account configured in it. All these things run
  TLSv1 and aren't things I can dictate go away.



I also found that squirrelmail uses TLSv1 and
  ECDHE-RSA-AES256-SHA. Since it's logging in from 127.0.0.1 to
  127.0.0.1 it's not a problem. But it IS a problem for setting
  these things in the server.


At this point, I have NO ssl_cipher_list configured in dovecot,
  so it's using whatever the default is. I set it back this way
  (that's what it was when I started this exercise) because
  everything I configured caused me problems. I need to leave the
  users alone for a bit so they can get some work done :)



With it set this way, I scanned my server using https://www.immuniweb.com/ssl/


Looks like it scans both the mail protocols and the web
  protocols. The only big problem is shows is the use of TLSv1,
  which I'm not sure I can do anything about at this point. 



There are a few other things it points out that I need to look in
  to.. 

- Doesn't support TLSv1.3. Not sure I can do anything about this
  one as I would assume it requires an update to openssl.
- The server does not prefer cipher suites. Need to do some
  research on this one.
- The server does not enforce HTTP Strict Transport Security.
  FIXED by adding the following to my virtualhost.

Header always set Strict-Transport-Security "max-age=63072000;
  includeSubdomains;"



Gary


On 9/4/2019 10:01 AM, CarlC Internet
  Services Service Desk wrote:


  
  
  
  
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 1.2].
 
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 correctly.
 
Carl
 

  
From:
Gary Bowling [mailto:g...@gbco.us] 
Sent: Wednesday, September 04, 2019 09:19 AM
To: qmailtoaster-list@qmailtoaster.com
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
  verification.
 
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
   

Re: [qmailtoaster] SSL Problem Dovecot

[Andrew Swartz]

Theoretically, you can be more strict with dovecot because you are the 
admin for all of those users and you can set the client software 
requirement.  But you have zero input into what every other smtp server 
in the world will use, so you have to be more flexible there.   At least 
in theory.


In monitoring dovecot logs, make sure your .conf has specified the 
ciphers in the highest to lowest order.  If your cipherlist is something 
like 'SSLv3:TLSv1.2" and the client offers SSLv3 ciphers, then your 
server will CHOOSE a SSLv3 cipher.  Example:


Compare the output of /openssl ciphers -v 'SSLv3:TLSv1.2'/ to /openssl 
ciphers -v 'TLSv1.2:SSLv3'/.


Remember, your list is also your order of preference.  I hate using 
'ALL' in the cipherlist because the order is quite random ( try /openssl 
ciphers -v 'ALL'/) and many of the SSLv3 ciphers precede TLSv1.2 
ciphers.  I like to add ciphers in my preferred order rather than state 
ALL and then remove the weak ones.


I used to monitor qmail logs for encryption of incoming mail. But I now 
use spamdyke and it does the encryption, therefore qmail thinks nothing 
is encrypted.  I've yet to find a way around that.


-Andy


On 9/4/2019 5:19 AM, Gary Bowling wrote:



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 verification.



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 

RE: [qmailtoaster] SSL Problem Dovecot

[CarlC Internet Services Service Desk]

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 
1.2].

 

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 
correctly.

 

Carl

 

From: Gary Bowling [mailto:g...@gbco.us] 
Sent: Wednesday, September 04, 2019 09:19 AM
To: qmailtoaster-list@qmailtoaster.com
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 
verification.

 

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 

Re: [qmailtoaster] SSL Problem Dovecot

[Gary Bowling]

  
  


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 verification.



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: 
'HIGH:-SSLv3' 

If you want "perfect forward secrecy", try this: 

Re: [qmailtoaster] SSL Problem Dovecot

[Andrew Swartz]

I just fact-checked my statement about enclosing the list in 
single-quotes.  The man page for openssl ciphers specifies only a 
colon-separated list.  The enclosing in single quotes may just be 
community habit rather than an actual requirement.


-Andy


On 9/4/2019 5:04 AM, Andrew Swartz wrote:



On 9/4/2019 4: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?


Yes, that is correct. But if you use the individual ciphers, the 
format is the same (i.e. enclosed in single quotes, separated by 
colons).  I think the only advantage of using the individual ciphers 
is that you get to put them in the order you prefer.  The advantage of 
the macros is that if you upgrade to openssl 1.1.1 which has TLSv1.3, 
then you automatically get the new ciphers (without having to manually 
regenerate the cipher list).


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



Yes, you can (enclosed in single-quotes, colon separated).

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?



With smpt server-to-server, the sending server is considered the 
"client" and the receiving server is considered the "server". Thus the 
two files: //var/qmail/control/tlsserverciphers/ for when you are the 
server and //var/qmail/control/tlsclientciphers/ for when you are the 
client/. /I have the former file as a link to the latter.  I see no 
reason to use a different list for outgoing mail (when you are the 
client) than for incoming mail (when you are the server).  Also, I 
link clientcert.pem to servercert.pem (for the same logic).


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?



I believe that that is wrong.  If you configure as such, it will use 
the SSLv3 protocol with TLSv1.2 ciphers.  I'm only 80% sure of this 
answer.


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?)


Yes, but use a single-quote at beginning and end.


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

ssl_cipher_list = ECDHE:DHE:-SSLv3


use a single-quote at beginning and end


ssl_min_protocol = TLSv1.2


Yes.  Those are good, secure settings.


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.



Yes.


Thanks, Gary




-Andy




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:
'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 

Re: [qmailtoaster] SSL Problem Dovecot

[Andrew Swartz]

On 9/4/2019 4: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?


Yes, that is correct. But if you use the individual ciphers, the format 
is the same (i.e. enclosed in single quotes, separated by colons).  I 
think the only advantage of using the individual ciphers is that you get 
to put them in the order you prefer.  The advantage of the macros is 
that if you upgrade to openssl 1.1.1 which has TLSv1.3, then you 
automatically get the new ciphers (without having to manually regenerate 
the cipher list).


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



Yes, you can (enclosed in single-quotes, colon separated).

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?



With smpt server-to-server, the sending server is considered the 
"client" and the receiving server is considered the "server".  Thus the 
two files: //var/qmail/control/tlsserverciphers/ for when you are the 
server and //var/qmail/control/tlsclientciphers/ for when you are the 
client/. /I have the former file as a link to the latter.  I see no 
reason to use a different list for outgoing mail (when you are the 
client) than for incoming mail (when you are the server).  Also, I link 
clientcert.pem to servercert.pem (for the same logic).


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?



I believe that that is wrong.  If you configure as such, it will use the 
SSLv3 protocol with TLSv1.2 ciphers.  I'm only 80% sure of this answer.


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?)


Yes, but use a single-quote at beginning and end.


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

ssl_cipher_list = ECDHE:DHE:-SSLv3


use a single-quote at beginning and end


ssl_min_protocol = TLSv1.2


Yes.  Those are good, secure settings.


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.



Yes.


Thanks, Gary




-Andy




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:
'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" 

Re: [qmailtoaster] SSL Problem Dovecot

[Gary Bowling]

  
  


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:
  
  '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