Yea I just run the script looks like it did gen the bigger key. 2048 now
> On Aug 13, 2018, at 23:53, Andrew Swartz <[email protected]> wrote: > > 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 >>> <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]> >>>>>>>>> <mailto:[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> >>>>>>>>> <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]> >>>>>>>>>> <mailto:[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/> <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 >>>>>>>>>>>>> <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
signature.asc
Description: Message signed with OpenPGP
