I just went through the qmail-tls patch (http://inoa.net/qmail-tls/netqmail-1.05-tls-20060104.patch).
Lines 65-68 explain that if TLSCIPHERS is not present (in tcp.smtp) then qmail-smtpd uses the ones in /var/qmail/control/tlsclientciphers. I interpret that as it not being necessary. Over the last couple days I've discovered a couple things which might interest you: 1. you can put any size dhparams into /var/qmail/control/dh1024.pem. I'm currently using 2048 bit dhparams in that file, and I proved it to work with 4096 bit (just for fun). I went through the patch and confirmed that it does not check the size of the dhparams in the file; if the file is present, qmail-smtpd passes it to openssl without any checks. I mention this because 1024 bits is currently considered insecure, and experts now recommend a minimum of 2048 bits. 2. The same goes for /var/qmail/control/rsa.512.pem. I've put a 2048 bit key in the file but cannot detect any change in behavior (i.e. connecting with s_client and using -debug). I have NO IDEA what that file is used for. It is hardly used in the patch and it is gone from the newer version of the patch. I've searched the file contents of qmail/control and qmail/bin, and the only mention is in qmail/bin/dh_key, which is a very short bash script for cron which regenerates a new dh512.pem, dh1024.pem, and rsa512.pem daily. Therefore it is a RSA private key with no associated public key or cert. Qmail uses the contents of servercert.pem for all connections, at least as far as I can ascertain. I've sent an email to the patch author, but I've not heard back. If you want larger dhparams/keys, the easiest way is to edit the sizes in /var/qmail/bin/dh_key and just wait for the daily cron job to generate new files. -Andy On 8/13/2018 10:03 PM, Remo Mattei wrote: > I have the default one here it is.. should I add the TLS one like you > mention below? > > :allow,BADMIMETYPE="",BADLOADERTYPE="M",CHKUSER_RCPTLIMIT="50",CHKUSER_WRONGRCPTLIMIT="10",NOP0FCHECK="1",QMAILQUEUE="/var/qmail/bin/simscan",DKQUEUE="/var/qmail/bin/qmail-queue.orig",DKVERIFY="DEGIJKfh",DKSIGN="/var/qmail/control/domainkeys/%/private” > > >> On Aug 13, 2018, at 22:43, Andrew Swartz <[email protected] >> <mailto:[email protected]>> wrote: >> >> Remo, >> >> I don't think the order matters in tlsserverciphers. I cat'd the >> cert, the key, and the chain into my file, in that order, and it >> works fine. >> >> Nice bug catch on the cipher list. I made the script on the latest >> centos-7 toaster which installs with a cipher list of >> "DH:!LOW:!MEDIUM" in tcp.smtp. The sed command merely replaces it. >> If it's not present, or different, nothing happens (i.e. it fails >> gracefully). It did not seem to affect your connection, as that was >> just a cert verify problem. >> >> Do you have a TLSCIPHERS environ. variable in tcp.smtp? In my file, >> the line for remote mail ends with: >> TLSCIPHERS="ECDHE:DHE:ECDH:DH:AES:!SSLv2!SSLv3" >> >> I just checked a centos-5 installation, and there is no TLSCIPHERS >> variable in tcp.smtp. I just connected to that machine with s_client >> and it established a TLSv1.0 connection, so apparently there is a >> default cipher list present in qmail-smtpd (I confirmed that port 587 >> does not go through spamdyke). >> >> Specifying ciphers is merely due to my over paranoia. 99.999% of >> people will likely be happy with the defaults. >> >> -Andy >> >> >> >> On 8/13/2018 9:25 PM, Remo Mattei wrote: >>> I think I need to add the intermediary cert. looks like.. trying to >>> figure that out now.. not sure which order they go. >>> >>> Andrew Swartz wrote on 8/13/18 22:24: >>>> Remo, >>>> >>>> I just did this: >>>> >>>> openssl s_client -starttls smtp -crlf -connect qmail.rm.ht:587 >>>> >>>> and got the same result. >>>> >>>> Therefore you've probably had this problem for a while. >>>> >>>> Are you using the cert with the "full chain"? Apparently bare certs >>>> rarely verify, and I've read several recommendations to provide the >>>> server with the pem file containing the full chain. >>>> >>>> If you read the stuff at the "STARTTLS Everywhere" site, they state that >>>> most mail servers to not require (or even attempt) cert verification, >>>> and changing this is one of their goals. >>>> >>>> -Andy >>>> >>>> >>>> >>>> On 8/13/2018 8:56 PM, Remo Mattei wrote: >>>>> Any suggestions on this Andy? >>>>> >>>>> openssl s_client -crlf -connect qmail.rm.ht:465 >>>>> CONNECTED(00000005) >>>>> depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = qmail.rm.ht >>>>> verify error:num=20:unable to get local issuer certificate >>>>> verify return:1 >>>>> depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = qmail.rm.ht >>>>> verify error:num=27:certificate not trusted >>>>> verify return:1 >>>>> depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = qmail.rm.ht >>>>> verify error:num=21:unable to verify the first certificate >>>>> verify return:1 >>>>> --- >>>>> Certificate chain >>>>> 0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=qmail.rm.ht >>>>> i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO >>>>> RSA Domain Validation Secure Server CA >>>>> --- >>>>> >>>>> >>>>> I do have a valid cert as you can see it’s from COMODO. But not sure >>>>> about the first few lines >>>>> >>>>> Remo >>>>> >>>>>> On Aug 13, 2018, at 21:42, Andrew Swartz <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>> >>>>>> I just realized that the plain text line-wrapped the script, so here >>>>>> is an unwrapped version in case anyone else wants to use it. Also, I >>>>>> made it multiline so you can cut and paste it into a terminal and >>>>>> accomplish this in about 3 seconds with netstat confirming success (it >>>>>> should print a single line showing tcpserver listening on 465). >>>>>> >>>>>> rfc8314 <https://tools.ietf.org/html/rfc8314> in Jan of this year >>>>>> reinstates port 465/tls because starttls (port 587) is broken beyond >>>>>> repair (from a security perspective). So eventually everyone may >>>>>> eventually need to go back to port 465. But since servers get to >>>>>> dictate setting to their clients without creating interoperability >>>>>> issues, it will likely be many years before this occurs. >>>>>> >>>>>> The critical flaw in starttls is that some ISP's and/or governments >>>>>> have been caught filtering out the STARTTLS packet and thus preventing >>>>>> the initiation of encryption (a "starttls downgrade attack"). In that >>>>>> case, the client's username and password are sent in the clear. And >>>>>> if an eavesdropper gets those, they can wreak havoc on your your life >>>>>> (i.e. by resetting the password for your bank or other online >>>>>> accounts, etc). With port 465/tls, the client connection either >>>>>> establishes encryption or fails; it cannot be tricked into using >>>>>> clear-text. >>>>>> >>>>>> Anyway, here is the paste-able script: >>>>>> >>>>>> qmailctl stop; \ >>>>>> cp -r /var/qmail/supervise/submission /var/qmail/supervise/smtps; \ >>>>>> chown -R qmaill:qmail /var/qmail/supervise/smtps; \ >>>>>> sed -i 's/REQUIRE_AUTH=1/REQUIRE_AUTH=1\nexport SMTPS=1/' >>>>>> /var/qmail/supervise/smtps/run; \ >>>>>> sed -i 's/587/465/' /var/qmail/supervise/smtps/run; \ >>>>>> sed -i 's/submission/smtps/' /var/qmail/supervise/smtps/log/run; \ >>>>>> sed -i 's/DH:!LOW:!MEDIUM/ECDHE:DHE:ECDH:DH:AES:!SSLv2:!SSLv3/' >>>>>> /etc/tcprules.d/tcp.smtp; \ >>>>>> qmailctl cdb; \ >>>>>> qmailctl start; \ >>>>>> netstat -lnp | grep 465 >>>>>> >>>>>> >>>>>> -Andy >>>>>> >>>>>> PS: If old clients cannot connect, then remove the "!SSLv3" from the >>>>>> cipher list in tcp.smtp >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 8/13/2018 7:32 PM, Remo Mattei wrote: >>>>>>> Cool! I remember I did it like Eric described but the bottom line is >>>>>>> it works either way. I do not offer 465 any longer :) >>>>>>> >>>>>>> *dal mio iPhone X* >>>>>>> >>>>>>> Il giorno 13 ago 2018, alle ore 20:25, Andrew Swartz >>>>>>> <[email protected] <mailto:[email protected]>> ha scritto: >>>>>>> >>>>>>>> I eventually figured this out, and accomplished the same result though >>>>>>>> I >>>>>>>> went about it slightly differently. It is now fully functional. Below >>>>>>>> is the script which I created and accomplishes this in very few lines. >>>>>>>> It copies the supervise/smtp directory to supervise/smtps and it then >>>>>>>> edits a few values in two files files (plus editing the cipher list in >>>>>>>> tcp.smtp). >>>>>>>> >>>>>>>> >>>>>>>> qmailctl stop >>>>>>>> cp -r /var/qmail/supervise/submission /var/qmail/supervise/smtps >>>>>>>> chown -R qmaill:qmail /var/qmail/supervise/smtps >>>>>>>> sed -i 's/REQUIRE_AUTH=1/REQUIRE_AUTH=1\nexport SMTPS=1/' >>>>>>>> /var/qmail/supervise/smtps/run >>>>>>>> sed -i 's/587/465/' /var/qmail/supervise/smtps/run >>>>>>>> sed -i 's/submission/smtps/' /var/qmail/supervise/smtps/log/run >>>>>>>> sed -i 's/DH:!LOW:!MEDIUM/ECDHE:DHE:ECDH:DH:AES:!SSLv2/' >>>>>>>> /etc/tcprules.d/tcp.smtp >>>>>>>> qmailctl cdb >>>>>>>> qmailctl start >>>>>>>> >>>>>>>> >>>>>>>> Thanks for confirming that I did it right, >>>>>>>> Andy >>>>>>>> >>>>>>>> >>>>>>>> On 8/13/2018 7:06 PM, Eric Broch wrote: >>>>>>>>> Stock CentOS 7 does not have SMTPS standard. You must create the >>>>>>>>> supervise scripts. >>>>>>>>> >>>>>>>>> You could stop qmail >>>>>>>>> >>>>>>>>> # qmailctl stop >>>>>>>>> >>>>>>>>> and copy smtp supervise scripts to smtps (make sure qmail is stopped >>>>>>>>> or >>>>>>>>> else you'll have a mess): >>>>>>>>> >>>>>>>>> # cp -Rp /var/qmail/supervise/smtp /var/qmail/supervise/smtps >>>>>>>>> >>>>>>>>> Then change two files: >>>>>>>>> >>>>>>>>> /var/qmail/supervise/smtps/run >>>>>>>>> >>>>>>>>> <run> >>>>>>>>> >>>>>>>>> #!/bin/sh >>>>>>>>> QMAILDUID=`id -u vpopmail` >>>>>>>>> NOFILESGID=`id -g vpopmail` >>>>>>>>> MAXSMTPD=`cat /var/qmail/control/concurrencyincoming` >>>>>>>>> SMTPD="/var/qmail/bin/qmail-smtpd" >>>>>>>>> TCP_CDB="/etc/tcprules.d/tcp.smtp.cdb" >>>>>>>>> HOSTNAME=`hostname` >>>>>>>>> VCHKPW="/home/vpopmail/bin/vchkpw" >>>>>>>>> export SMTPS=1 >>>>>>>>> >>>>>>>>> exec /usr/bin/softlimit -m 128000000 \ >>>>>>>>> /usr/bin/tcpserver -v -R -H -l $HOSTNAME -x $TCP_CDB -c >>>>>>>>> "$MAXSMTPD" \ >>>>>>>>> -u "$QMAILDUID" -g "$NOFILESGID" 0 465 \ >>>>>>>>> $SMTPD $VCHKPW /bin/true 2>&1 >>>>>>>>> >>>>>>>>> </run> >>>>>>>>> >>>>>>>>> & >>>>>>>>> >>>>>>>>> /var/qmail/supervise/smtps/log/run >>>>>>>>> >>>>>>>>> <run> >>>>>>>>> >>>>>>>>> #!/bin/sh >>>>>>>>> LOGSIZE=`cat /var/qmail/control/logsize` >>>>>>>>> LOGCOUNT=`cat /var/qmail/control/logcount` >>>>>>>>> exec /usr/bin/setuidgid qmaill /usr/bin/multilog \ >>>>>>>>> t s$LOGSIZE n$LOGCOUNT /var/log/qmail/smtps 2>&1 >>>>>>>>> >>>>>>>>> </run> >>>>>>>>> >>>>>>>>> Start qmail (# qmailctl start) >>>>>>>>> >>>>>>>>> >>>>>>>>> On 8/11/2018 6:36 PM, Andrew Swartz wrote: >>>>>>>>>> I just installed qmailtoaster onto CentOS-7. The qt_install script >>>>>>>>>> opened port 465 on the firewall. However, s_client cannot connect to >>>>>>>>>> port 465 and netstat shows that nothing is listening on port 465. >>>>>>>>>> >>>>>>>>>> Can anyone point me at appropriate instructions for setting up >>>>>>>>>> listening >>>>>>>>>> on port 465 which are specific (or applicable) to qmailtoaster? I >>>>>>>>>> searched wiki.qmailtoaster.com <http://wiki.qmailtoaster.com> >>>>>>>>>> <http://wiki.qmailtoaster.com/> and >>>>>>>>>> found nothing. I did some general >>>>>>>>>> googling and found several somewhat conflicting descriptions but I'm >>>>>>>>>> unsure which apply to the configuration used in qmailtoaster. >>>>>>>>>> >>>>>>>>>> My interest is because 465 has been reinstated (in Jan 2018) as the >>>>>>>>>> preferred submission port due to security problems with STARTTLS >>>>>>>>>> (https://tools.ietf.org/html/rfc8314). >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> -Andy >>>>>>>>>> >>>>>>>>>> >>>>>>>> -- >>>>>>>> Andrew W. Swartz, MD >>>>>>>> Departments of Emergency Medicine, Family Medicine, and Surgery >>>>>>>> Yukon-Kuskokwim Delta Regional Hospital >>>>>>>> Bethel, Alaska >>>>>>>> >>>>>> -- >>>>>> Andrew W. Swartz, MD >>>>>> Departments of Emergency Medicine, Family Medicine, and Surgery >>>>>> Yukon-Kuskokwim Delta Regional Hospital >>>>>> Bethel, Alaska >>> >>> -- >>> Sent from Postbox <https://www.postbox-inc.com/> >> >> -- >> Andrew W. Swartz, MD >> Departments of Emergency Medicine, Family Medicine, and Surgery >> Yukon-Kuskokwim Delta Regional Hospital >> Bethel, Alaska > -- Andrew W. Swartz, MD Departments of Emergency Medicine, Family Medicine, and Surgery Yukon-Kuskokwim Delta Regional Hospital Bethel, Alaska
smime.p7s
Description: S/MIME Cryptographic Signature
