Closed dibble5504 closed 7 years ago
Please try this version and let me know if it works.
No difference from what I can tell. I will try to look at the changes to see if I can see a problem, but I'm no expert.
On 11/21/2015 6:04 AM, GDR! wrote:
Please try this version and let me know if it works.
http://f.gdr.name/paranoia-issue-14.xpi
— Reply to this email directly or view it on GitHub https://github.com/gjedeer/paranoia/issues/14#issuecomment-158538655.
Well, it's just a regular expression
I've just installed Paranoia and find it great help! Thank you! The only thing, I also get false alarms. For example, this Received-line
Received: from serv23.server-center.de ([87.119.209.207])
by smtp.rzone.de (RZmta 37.14 OK)
with ESMTPS id I01ecbrB8IC7P9v
(using TLSv1 with cipher AES256-SHA (256 bits))
[…]
results in an alarm, since Paranoia assumes that the name of the protocol is “cipher” (which it doesn't know) instead of “ESMTPS”. Another example is
Received: from mout01.posteo.de ([185.67.36.65])
by smtp.rzone.de (RZmta 37.14 OK)
with ESMTPS id H04058rB5JmUm0u
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA))
[…]
where Paranoia assumes that the name of the protocol is “521” (which again it doesn't know). As before, the protocol is actually “ESMTPS” and should be considered as safe.
Apparently, Paranoia searches for occurrences of with
in the Received-entries and assumes that the following word is the name of the protocol. In cases of multiple occurrences of with
within one Received-entry, Paranoia goes for the last one. However, it's not the last but rather the first occurrences of with
actually specifies the protocol.
@stryx When I configure my Postfix server with smtpd_tls_received_header = yes
, the cipher text is added before the ESMTPS in the Received:
header (and thus no issue with the extension).
Received: from my-domain.com (unknown [IP])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by mail.my-domain.com (Postfix) with ESMTPSA id C035A601BA2A
for <notmyrealmail@gmx.net>; Thu, 28 Apr 2016 10:16:07 +0000 (UTC)
RZmta
seems to behave differently.
I don't understand the RegEx well enough to fix it, though.. :blush:
@sdellenb @stryx I'll try to support this format in the next release if nobody submits a pull request... but that's going to happen somewhere between now and +INF ;)
Other not recognized formats are:
Received: from [192.168.1.0] (xxx [123.234.456.678]) (authenticated bits=0) by yyy (8.1.6.6) with ESMTP id u3LACxbA081544 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT) for <name@domain.de>; Thu, 21 Apr 2016 12:11:59 +0200 (MEST)
Received: from mail.gate.smtp.com ([7.8.9.10]) by inbox.mail.edu with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Apr 2016 13:51:16 +0200
One more example sent by Dennis to my email:
Received from: mx.hs-offenburg.de ([141.79.11.25])
by something.something.hs-offenburg.de with ESMTP (TLS encrypted); Wed, 18 Jan 2017 11:22:33 +0100
Here one that is currently not recognized as encrypted (similar to the one posted by c3431936)
Received: from mout.gmx.net ([111.222.333.444])
by xxx.yyy with ESMTP/TLS/DHE-RSA-AES128-GCM-SHA256; 07 Sep 2017 18:13:27 +0200
This one should work for all the headers from this issue:
https://f.gdr.name/paranoia-issue-14-take-2.xpi
When it doesn't find a secure transport method by parsing the header, it falls back to just searching for these substrings in Received headers:
var additionalSecureMethods = ['with ESMTP/TLS', 'with ESMTP (TLS encrypted)', 'version=TLSv', 'using TLSv', 'over TLS secured channel']
I don't have Thunderbird installed on any machine now so it's untested.
Thanks! I can confirm the one posted above is recognized! Do you plan to put it on the official mozilla page also?
Soon.
Hi. Seems that the following type of TLS connections are not recognised as secure:
Received: from github-smtp2a-ext-cp1-prd.iad.github.net ([192.30.252.192]) by BAY004-PAMC2F9.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23143); Sat, 14 Nov 2015 22:30:08 -0800