On Thu, May 12, 2016 at 4:52 PM, Jeffry Dwight
wrote:
> I can't figure out how to tell the
> difference between a "real" untrusted root and a cert issued by some
> admin's
> personal CA.
>
Because there is none.
___
mailop
On Thu, May 12, 2016, Jeffry Dwight wrote:
> Is it even worth checking the cert chain at all?
Sure, if you want to enable further requirements.
For example, I use something like this:
smtpc_rcpt_conf:@$IMPORTANTDOMAIN tls_requirements { flags={verified};
cipher_bits_min=256; hostnames =
In the case of STARTTLS failure SMTP falls back to cleartext (unless
DANE or SMTP STS is used to indicate STARTTLS is required). Encryption
with invalid certificate in this case is better than no encryption.
Jeffry Dwight пишет:
> Thanks for all the replies.
>
> Is it even worth checking the
Thanks for all the replies.
Is it even worth checking the cert chain at all?
Right now, I've taken your advice and am ignoring the following errors:
Untrusted CA
Untrusted Root
Untrusted Test Root
CN Name Mismatch
Cert Expired
This leave only revocation, invalid cert use, and miscellaneous
STARTTLS itself doesn't protect against active MitM attack, because
attacker can strip STARTTLS from server's banner and according to
standard, client should fall back to cleartext in this case. To protect
against passive MitM, there is no need to validate certificate because
self-signed
On Thu, May 12, 2016, Jeffry Dwight wrote:
> So, what do you all do? Right now, I'm verifying the cert and its chain, but
> ignoring CN mismatches. That seems to be fine for ensuring encryption, but
Only log "problems" (why should I trust some CA?) unless explicitly
configured to check (for a
On Thu, May 12, 2016 at 1:24 PM, Jeffry Dwight
wrote:
> So, what do you all do? Right now, I'm verifying the cert and its chain,
> but
> ignoring CN mismatches. That seems to be fine for ensuring encryption, but
> rather defeats the purpose of knowing we're connecting
We've recently modified our main outgoing MTA to perform STARTTLS if advertised
by the server. This is primarily to satisfy our Gmail customers, because GMail
now sports a nasty red lock symbol beside any incoming mail that was not
encrypted.
We've discovered that many servers don't have a CN