How did y-I gen the dh1024? Thanks
Sent from my iPad > On Aug 13, 2018, at 11:34 PM, Andrew Swartz <[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]> 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/> 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 >>> >>> -- >>> 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
