> over IPv6 your SMTP server does have a rather noticeable pre-greet
Thanks for checking. While the server is moving north of 80 Mbyte/s of
network traffic (evenly spread between in- and outbound) over thousands
of connections, I don't know if that might be a possible reason for the
delay you observed?
> On 13 Apr 2019, at 00:57, Dominic Raferd <[hidden email]> =
> > I too find that hardenize complains about my STARTTLS without any =
> details as to why. Like @lbutlr (and most of us) I offer STARTTLS on =
> port 25 but not AUTH. However I see this message in my log after the =
> test ran, I think hardenize is hitting my server too hard and maybe that =
> is why it is (wrongly) saying there is a problem with the server:
> > 2019-04-13 07:36:23 streamingbats postfix/smtpd: warning: =
> Connection rate limit exceeded: 31 from =
> outbound.hardenize.com[18.104.22.168] for service smtp
> Checking my logs:
> postfix/smtpd: connect from outbound.hardenize.com[22.214.171.124]
> postfix/smtpd: SSL_accept error from outbound.hardenize.com[126.96.36.199]: -1
> postfix/smtpd: lost connection after STARTTLS from outbound.hardenize.com[188.8.131.52]
> postfix/smtpd: disconnect from outbound.hardenize.com[184.108.40.206] ehlo=1 starttls=0/1 ...
Same here. Speculation: they require PKI certificate verification.
> On Apr 13, 2019, at 10:23 AM, Wietse Venema <[hidden email]> wrote:
>> postfix/smtpd: connect from 3[220.127.116.11]
>> postfix/smtpd: SSL_accept error from outbound.hardenize.com[18.104.22.168]: -1
>> postfix/smtpd: lost connection after STARTTLS from outbound.hardenize.com[22.214.171.124]
>> postfix/smtpd: disconnect from outbound.hardenize.com[126.96.36.199] ehlo=1 starttls=0/1 ...
> Same here. Speculation: they require PKI certificate verification.
One might also speculate that they try various ciphers and protocols, some of which
don't pan out. The only way to determine which ciphers a server supports is to
try lots of connections, servers don't send their complete cipherlist to clients,
they only send the one cipher they accepted. Ditto with protocol versions.
So one would expect a failed handshake any time an unsupported cipher or protocol
I am the founder/developer of Hardenize. I was alerted to this thread by one or two participants (thanks!) and I thought it would be a good idea to join the list to respond. (I don't have an earlier email from the same thread to respond to, but perhaps reusing the same subject may do the trick.) I've read the entire thread and here are my thoughts:
- Wherever you're seeing unexpected results, the root cause is probably some sort of server throttling of our connections. To discover all supported TLS suites we need one connection per suite, and then we do that for each protocol separately. If in doubt, whitelist outbound.hardenize.com and try again.
- At present our report tries to be factual, without any recommendations except for the obvious. As a rule of thumb, if the report card (left) shows orange or red, that's because something is broken or clearly insecure. We may show additional orange and red on the right, but we often do that to call out some insecure elements. For example, TLS 1.0 as a protocol is weak and we need to call it out as such, even if it's all right (or acceptable) to use with SMTP.
- As a rule of thumb, I think it would be very difficult for a commercially-viable operation to eliminate all the warnings.
- When it comes to SMTP and TLS, we think that servers should support modern protocols (so TLS 1.2 or better) with forward secrecy. That's pretty much it, except for some protocol elements that are so dangerous that could be used to compromise other servers (e.g., HTTPS). We have different (stricter) requirements when MTA-STS is enabled.
- Re DMARC, at this point I believe we factually report on whether DMARC is supported, without endorsing a particular configuration. When we start to recommend it, we will add more content to describe the caveats.
If you have specific objections and recommendations, I'd appreciate it if you could open a ticket here https://github.com/hardenize/hardenize-public/issues and we'd be happy to discuss and learn. Please have in mind that our report is by no means complete today; we're on a journey and we have a pretty long to-do list internally of things we wish to work on and improve.