Koozali.org: home of the SME Server
Obsolete Releases => SME 9.x Contribs => Topic started by: guest22 on April 14, 2017, 07:15:09 AM
-
Hi,
I remember some of us discussing Forward Secrecy. Just can't seem to find where on the wiki or forums. Maybe my bad, but would one of you have some pointers pls
TIA
-
It was properly discussed as part as TLS where the small parameter "SSL_honor_cipher_order" had to be added.
https://bugs.contribs.org/show_bug.cgi?id=9204
-
Thanks!
I added to the bug. I see no reason why this topic has been stalled. We need to be on our qui vive, especially nowadays where advanced techniques and attempts endanger email traffic.
I see no reason to wait for a non responsive person on the bugtracker, for it has delayed this topic (and the technical solution/future) for more then a year whilst the rest of the world progresses.
-
I honestly do not think that PFS is the most important thing for the SME server even though its rather easy to activate. The most critical is that the SME cannot send anything encryptet using TLS and that DKIM is not supported. This is really what prevents security...
The inbound system (using qpsmtpd) is actually very OK and allows for modifications whereas the outbound (using qmail) is restricting simple changes.
/Knuddi
-
If so, please let us do those changes.
-
If so, please let us do those changes.
well.. it seems that qmail is the culprit here..
-
I hope Knuddi can enlighten us a bit more on what is 'required' with the least amount of effort BUT with the most positive effect on security.
-
AFAIK patching qmail is a PITA
but you're right, I'll wait for Jesper to give us some advices
-
I have actually replaced qmail in my systems (at ScanMailX) basically since I could modify them as I wanted. I have written an outbound mailer based on qpsmtpd with queues in MySQL to give me 100% control.
Somewhere someone mentioned that using TLS outbound would be a challange with self-signed certificated. I am not so sure that is a problem as they seemed to work (as I remember).
Again, inbound the SME supports SPF, DKIM and DMARC check and allows for TLS connected with PFS (I think its enabled in SME 9.x not?). To go all crazy one can add DNSSEC and the DANE but the two latter properly wont add a lot of extra security as it is not widely accepted/supported.
I can find this patch for qmail but do not have a build environment.
http://inoa.net/qmail-tls/
What you ultimately want it all green like this:
https://ssl-tools.net/mailservers/swerts-knudsen.dk
Having made all this, I think that the biggest challanges are not whether we are being listened in on (hence TLS) but whether the mail system allows for "bad" emails with nasty stuff to come through. The standard SME with all the available DNSBL cannot prevent attachments to come through and the users are extremele stup.... - they keep on opening "Invoice XXX" or "Itenary XXX" XLS/DOCX files. The system can also use an improved attachment filter beyound the one we have today.
So maybe a community based attachment HASH system (alá VirusTotal) where an attachment can be checked up against would be awsome. I did start the smeoptimizer (https://wiki.contribs.org/SMEOptimizer) to stimulate us to help each other. Initially with a DNSBL but this could be extended...
-
Outbound dkim signing is available out of the box in sme 9.2 (done at the qpsmtpd level when client submit it), so what's really missing is outbound TLS support, which indeed is something the MTA should handle. We have several ways to implement it (replace qmail, patch qmail, or use a outbound proxy). But 1 important thing about SMTP+TLS: it's always an oportunistic encryption, and only protect against passive attacks. Active ones will still be a problem because there no way to check the remote end cerificate CN. Unlike https, there's no way to do this in SMTP. That's still something we should try to enable, we just have to be aware of this limitation.
-
AFAIK patching qmail is a PITA
Technically it may be a PITA, but legally it's no issue at all--qmail is now in the public domain, so we're free to patch it, and distribute our patches, at will. Whether it's wise to do so, or technically feasible to do so, is another issue, but legally there's no issue at all.
-
@Daniel, you are absolutely right, TLS will always be opportunistic as both end need to be enabled. We could reject connections that do not support TLS but that will have a consequence and good mail will get lost.
The real battle is, as you point out, the active attacks - these are also super hard to protect against and most often require many level of tests. But the fundament I think is a job for the SME distribution and TLS is one of them.
Replacing qmail is going to be a forever project so I would suggest to get qmail patched.
The fight the active attacks, then currently the most nasty ones (Ransomware especially) are carried via attachments of all kinds. Here we should find a stronger method then just rejecting all MS Office and ZIP/Jar files. I will try to make a DNS based system where file sha256 hashes can be checked up against.
-
@Daniel, you are absolutely right, TLS will always be opportunistic as both end need to be enabled. We could reject connections that do not support TLS but that will have a consequence and good mail will get lost.
I mean, even when both end supports TLS, the CN of the remote peer will not be verified (unlike, for example https, where CN verification is one of the important things). So you can have encrypted connections. But you can not be sure you're talking to the one you think you are. There's nothing we can do about this, it's not possible to implement CN checking on SMTP (except with manual cert pinning, but it's not something which scale very well ;-) )
Replacing qmail is going to be a forever project so I would suggest to get qmail patched.
I agree we should try to patch qmail to add outbound TLS support.
The fight the active attacks, then currently the most nasty ones (Ransomware especially) are carried via attachments of all kinds. Here we should find a stronger method then just rejecting all MS Office and ZIP/Jar files. I will try to make a DNS based system where file sha256 hashes can be checked up against.
I was thinking about something like this which could check attachments hash against virustotal (a new qpsmtpd plugin), but never had time to implement it.
-
I have made a system that checks against VirusTotal but you cannot do that inline due to API at VT. This has to be done in a side queue and re-injected back when the attachment has been verified. Also VT has serious rate limits so it has to be used with care.
Just captured some attachments data in a SQL DB to start the work of sharing nasty attachment which is NOT caught by Clam (with all extra signatures). These attachments have been de-queued and checked on the side, sha256 stored and now used to check inline for new mails arriving. "hits" indicated when the sha256 has been used to reject a mails based on the sha256 signature. The sha256 can be verified at VT (e.g https://virustotal.com/en/file/0aae7246fcd8e88e798df043c4bc60aa414831e404942574f8f07dd36c610e12/analysis/).
+------------------------------------------------------------------+----------------------------+--------+---------------------+------+-----------------------------------+
| sha256 | filename | size | inserted | hits | description |
+------------------------------------------------------------------+----------------------------+--------+---------------------+------+-----------------------------------+
| 0aae7246fcd8e88e798df043c4bc60aa414831e404942574f8f07dd36c610e12 | 874574.doc | 194048 | 2017-04-17 16:59:09 | 0 | Win32.SuspectCrc |
| 5bcb952aa60540f0b8020b8a3d09d05a5138fd913aecc12482c8b8b647e769a6 | order size.420096.pdf.jar | 540623 | 2017-04-17 22:53:40 | 1 | Win32.Outbreak |
| dc1e0353844fce38a83cdf6e4f6f592231bfbb9ce5310d5ecaae90d81e5e35ad | revised pi.jar | 541443 | 2017-04-18 08:00:59 | 0 | UDS:DangerousObject.Multi.Generic |
| ce9c6911bf301f2a665f84cc83f373e768d8aedf05874299ff2495f943cb319a | request for quotation.jar | 540937 | 2017-04-18 09:20:47 | 0 | Win32.Outbreak |
| 604e6e2ab29742cb86ac476cb0607455c5fb1fd127273346262c39d0faed04b7 | ratequotesfo240417-058.zip | 528318 | 2017-04-18 17:00:26 | 4 | Java:Malware-gen [Trj] |
| f4aec175a8f24493597ded7ccc8e08649bbc45c9eb237f4dce9dca78225f9dc6 | quotation.jar | 540640 | 2017-04-18 17:03:52 | 1 | Win32.Outbreak |
| 9df9b78bfab244d0f42fad6e78aa085d9919ef1111805dad37a149129d1674f9 | ttpaymentslip.zip | 527784 | 2017-04-18 18:03:06 | 2 | Win32.SuspectCrc |
| 23d9ae37b39e78f2271da6fac697377cce56fbbee7abbfbc9264f344757dc57a | payment_copy.doc | 126976 | 2017-04-19 09:35:06 | 0 | Trojan-Downloader.JS.Agent.asdgau |
| b7f7e012b817e7f9afd36cf853ed6ccda1f7f21af6ae23db16b543430030f102 | attachment-9990-1213.txt | 546901 | 2017-04-19 09:50:56 | 0 | a variant of Java/Kryptik.AO |
| 1ff93fa6a69c3ff03e380e13d8cbe6b8c5b614a211d597ab24e141d2caff293e | attachment-9990-1074.dat | 541346 | 2017-04-19 11:03:35 | 1 | HEUR:Trojan.Java.Agent.gen |
| 7865173c0b57d08c80dae13ce63e7c6e45cc58ace67d3af3c4783331a58759bb | purchase order.jar | 668875 | 2017-04-19 11:21:33 | 0 | Trojan.Java.Agent.ensjfz |
| 6413fec8e288d6f0b62547b5da6c4cac1b571aacde8ff9649844d2315253cde0 | payment slip1006.jar | 541666 | 2017-04-19 12:36:57 | 0 | HEUR:Trojan.Java.Agent.gen |
| fc5265bcd065930cd8ff15a7d2235bdbbc7535b159f7c71f11c4a6fbf1c2c663 | payment advice.zip | 532478 | 2017-04-19 13:10:35 | 0 | HEUR:Trojan.Java.Agent.gen |
| a6c7852805f028bbdf95528f77644f4644d4264b114adde39a36ec6d7e55ee59 | quote.jar | 545630 | 2017-04-19 13:44:48 | 2 | Win32.Outbreak |
| abff5964b709d05633cc8feef1e66671acc86b595ca04a04c9f421247615e9b3 | romania order.jar | 635313 | 2017-04-19 14:14:50 | 0 | Trojan.Java.Agent.ensjfz |
| 8b7c44311cd76f7a753779a6cf73a373e054863dad5c5b9cb8abc0cea27e5b18 | attachment-30256-407.dat | 189952 | 2017-04-19 14:19:20 | 0 | Win32.Outbreak |
| 0d27447dd3fc4f06a213a1076699b83df36723888190a521f863e966214c7c08 | 132799.doc | 189952 | 2017-04-19 15:10:16 | 0 | W97M/Fakealert |
| 2cf081278bbc033b39d7db71be4f73918047f795d09ac5b080dac81817b63c9d | 700700.doc | 189952 | 2017-04-19 15:25:37 | 0 | W97M/Fakealert |
| 9fd35bf2be25290edfbc67d98b7434f6efee0ab9855519030745a87ddc3f91c2 | 247421.doc | 189952 | 2017-04-19 15:54:38 | 0 | Win32.SuspectCrc |
| 8195b41eb82b05fbf2b8e0ed2771499eb90608529e3f23a9c829841d4885cbe6 | 951701.doc | 189952 | 2017-04-19 16:38:03 | 0 | Win32.Outbreak |
| 85e60f45d551649c2e3b95b280b0abeb954b93984b38e819c92d051b45b11aa8 | 985322.doc | 189952 | 2017-04-19 16:59:12 | 0 | Win32.Outbreak |
| fbb1eb0ee1986af34bf31fa3ffc31de6e5ef59dd2865e6e463b9b0366955caa6 | 138548.doc | 189952 | 2017-04-19 17:10:20 | 0 | Win32.SuspectCrc |
| d35b7607ef5b797105682cbc5020d7d903fbbd864c530383116d6043a576da58 | 172528.doc | 189952 | 2017-04-19 17:36:04 | 0 | Win32.Outbreak |
| 79f21ec99af9cfccebaf381712e7e47a707149d346afc029f77162c50bad26d7 | 252711.doc | 189952 | 2017-04-19 17:53:55 | 0 | Win32.Outbreak |
| 3482fd6b720f33fac957070682c423a3fe1562e18bf2d65ce85eb8635e3cfd57 | attachment-2022-404.dat | 189952 | 2017-04-19 19:07:09 | 0 | Win32.SuspectCrc |
+------------------------------------------------------------------+----------------------------+--------+---------------------+------+-----------------------------------+
-
@Daniel B,
Just noticed that using TLS and DANE will validate the CN from the remote part. I have added DNSSEC and DANE for ScanMailX and you can see how it gets validated via
https://www.huque.com/bin/danecheck
using domain: mxdk01.scanmailx.com
Port: 25
Application: smtp
TLSA records found: 1
TLSA: 3 0 1 031b0131361fd53916d5dd5b25b0bcabf23de7818cc5935e9b5ac6ab1ee0cba4
Connecting to IPv4 address: 5.57.55.196 port 25
recv: 220 mx1-3.scanmailx.com ESMTP
send: EHLO cheetara.huque.com
recv: 250-scanmailx.com Hi cheetara.huque.com [50.116.63.23]
recv: 250-PIPELINING
recv: 250-8BITMIME
recv: 250-SIZE 100000000
recv: 250 STARTTLS
send: STARTTLS
recv: 220 Go ahead with TLS
TLSv1.2 handshake succeeded.
Cipher: TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384
Peer Certificate chain:
0 Subject CN: *.scanmailx.com
Issuer CN: RapidSSL SHA256 CA - G3
1 Subject CN: RapidSSL SHA256 CA - G3
Issuer CN: GeoTrust Global CA
2 Subject CN: GeoTrust Global CA
Issuer CN: (None)
SAN dNSName: *.scanmailx.com
SAN dNSName: scanmailx.com
DANE TLSA 3 0 1 [031b0131361f...] matched EE certificate at depth 0
Validated Certificate chain:
0 Subject CN: *.scanmailx.com
Issuer CN: RapidSSL SHA256 CA - G3
SAN dNSName: *.scanmailx.com
SAN dNSName: scanmailx.com
[0] Authentication succeeded for all (1) peers.
-
Ok, didn't know that. Still, it'd have continued if the CN didn't match I guess, but you'd have a log trace at least
-
If the destination domain (or mail server) has a DANE record (TLSA record) and the key there does not match the presented key when connecting, the sending server should not continue. But very very few domain advertise this TLSA key (yet) and hence as of now its not super effective.