This is copied out of qmail/bin/dh_key: openssl dhparam -2 -out /var/qmail/control/dh1024.new 2048 2>&1 > /dev/null chmod 644 /var/qmail/control/dh1024.new 2>&1 > /dev/null chown root:qmail /var/qmail/control/dh1024.new 2>&1 > /dev/null mv -f /var/qmail/control/dh1024.new /var/qmail/control/dh1024.pem 2>&1 > /dev/null
I've changed to "2048" (from 1024) toward the end of the first line. -Andy On 8/13/2018 10:39 PM, Remo Mattei wrote: > How did y-I gen the dh1024? > > Thanks > > Sent from my iPad > > On Aug 13, 2018, at 11:34 PM, Andrew Swartz <[email protected] > <mailto:[email protected]>> wrote: > >> 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 -- 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
