Subject: [Uta] E-Mail Protocol Security Measurements

From: Aaron Zauner <[email-masked]>
Date: Mon, 27 Jul 2015 15:17:52 +0200

Hi,

UTA chairs recommended sending a mail about this to the UTA and IETF
lists. We're currently analyzing our datasets -- so more/detailed data
will become available shortly.

Over the past couple of months we've been collecting SMTP, IMAP and POP
(implicit TLS, STARTTLS) security measurements (primarily relating to
TLS, X.509 Certs and offered protocol extensions). I've given a short
talk at IETF93 in SAAG on the topic, the slides can be found over here:
https://www.ietf.org/proceedings/93/slides/slides-93-saag-2.pdf

 * RC4 support is at about 83-85%
 * unsurprisingly TLS 1.0 is most widely supported
 * ~60% of certificates are self-signed
 * a huge number of servers offer AUTH PLAIN (some without STARTTLS)
 * 512bit DH(E) primes are very common
 * ECDH: most use 256bit group size
 * RC2-CBC-MD5 is supported by 40% of SMTP servers we've studied,
 * IDEA-CBC-MD5 by 14%

We've also found 5-6% support of export ciphers in these protocols.

If you have any questions regarding any of our scans or need data points
for your drafts, recommendations or any current work - we'd be happy to
help you out there as best as we can.

Note that we have an outstanding TLS enumeration scan on port 587. We've
collected banner messages and certificates from 465 and 587 already though.

We don't yet have a publication ready and our data sets are currently
not public, but will be in the foreseeable future. However we're happy
to provide details if any of you have questions.

Thanks,
Aaron

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 27 Jul 2015 23:16:44 +0000

>  * ECDH: most use 256bit group size

No surprises in the above.

>  * 512bit DH(E) primes are very common

With export ciphers, or with non-export ciphers?  I would expect
non-export ciphersuites to be accompanied by stronger DHE primes,
with 512-bit DHE primarily used with export ciphers.  Do you have
a break-down?

>  * RC2-CBC-MD5 is supported by 40% of SMTP servers we've studied,

This looks implausible, I've not seen it once in SMTP connection
logs.  Slide 8 even mentions this "preferred" by ~25% of servers.
Preferred to what?

This is an SSL 2.0 ciphersuite, and OpenSSL will never choose it
unless the selected protocol is SSL 2.0.  And indeed it is by
default the most preferred ciphersuite if you force SSL 2.0.

But SSLv2-only servers are VERY rare (at least for SMTP), the above
datapoint is at least misleading.

>  * IDEA-CBC-MD5 by 14%

This is also SSLv2 only.

-- 
	Viktor.

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 28 Jul 2015 01:39:40 +0200

> No surprises in the above.

Yep, we didn't expect anything else. This is also consistent with
reports we've seen from E-mail Service Providers and universities.

> with 512-bit DHE primarily used with export ciphers.  Do you have

I'll provide a detailed mapping in the coming days.

> datapoint is at least misleading.

Yes, these are exclusive SSLv2 cipher-suites. With about 40% of SMTP
servers still supporting SSLv2 this seems to be correct. Note that
these are not measurements of how many mail servers do actually
establish connections on these protocols, it's just a figure of
support for protocols/cipher-suites. That wasn't meant to be
misleading, thanks for pointing out that my slides do not explicitly
state the tested protocol version there.

Please keep in mind that these are rough numbers from our initial
aggregation of data in the data-sets we've collected, not a paper.

Aaron

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 29 Jul 2015 18:27:18 +0000

> aggregation of data in the data-sets we've collected, not a paper.

Yes, if you offer only SSLv2, then I'd expect to see a lot of
RC2-CBC-MD5, because "RC4" is by default pushed to the bottom of
the list of 128-bit ciphers by OpenSSL, so anything other than RC4
looks "better" (and perhaps actually is better).

Since almost nobody negotiates SSLv2 (by default disabled in the
Postfix SMTP client for example, and also in the server along SSLv3
in more recent releases), this data-point is much less alarming
than it seems.  With SSLv2 the choice (in OpenSSL) of > 64-bit
ciphers is rather limited:

    IDEA-CBC-MD5            SSLv2 Kx=RSA      Au=RSA  Enc=IDEA(128) Mac=MD5
    RC2-CBC-MD5             SSLv2 Kx=RSA      Au=RSA  Enc=RC2(128)  Mac=MD5
    RC4-MD5                 SSLv2 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5
    DES-CBC3-MD5            SSLv2 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=MD5

Which would you choose?  (Arguably 3DES, but its strength is 112-bit
in many implementations, so it often sorts after the nominally
128-bit peers).

The remedy is mostly to not bother with SSLv2.  Beyond perhaps
noting which servers support it, the details are hardly relevant,
and even measuring SSLv2 support is largely pointless, servers in
opportunistic TLS are generally willing to do whatever the client
is capable of, because (barring othe factors) even weak crypto is
better than cleartext.  Setting a floor security policy is left up
to the client.

The only issue is whether offering weaker options to some clients
creates downgrade opportunities against other clients.  With Logjam
as a recent example, we're deprecating "export" ciphers, single-DES,
SSLv2 and SSLv3  in Postfix SMTP servers, because no real clients
need these.  The plan is to drop support for weak crypto once it
is no longer needed for interoperability.  For now, we're retaing
RC4 support until the number of systems requiring RC4 drops further.

So what's important to measure is which servers support *only* RC4.
Note that Exchange 2003 appears to also support 3DES, but that
implementation is broken (post-handshake).  To detect those systems,
if the negotiated cipher is DES-CBC3-SHA, you need to send both
EHLO and QUIT:

	C: EHLO <yourname><CRLF>
	S: 250-...
	   ...
	S: 250 ...
	C: QUIT<CRLLF>
	S: 221 Goodbye

and if TLS detects problems with the QUIT response (garbage in the
TLS record-layer) then you have a server that supports only RC4
(the 3DES implementation is broken due to incorrect padding).

Such servers also only process the first 64 ciphersuite code-points
in the client handshake.  If their desired RC4-SHA or RC4-MD5 does
not appear in the first 64 slots, they'll try use 3DES and fail if
that does.

Dropping support for RC4 in Postfix is blocked on the substantial
disappearance of such servers, and measuring their population
periodically would be very useful.

-- 
	Viktor.

P.S.

If you have a dataset of hosts that offer STARTTLS on port 25, and
especially if that also includes the CN or first DNS altname in
the certificate (and/or the hostname from the first line of the
EHLO response), that would be most useful for my DANE surveys.

Drop me a line if you're willing to share.  My DANE SMTP server
hunt has so far found around 1700 DNSSEC domains served by just
over 900 DNSSEC TLSA-record validated MX hosts.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 29 Jul 2015 18:41:10 +0000

It kinda bothers me that at times the entire Internet security policy is being driven solely by data from one particular MTA.

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 29 Jul 2015 19:11:08 +0000

On Wed, Jul 29, 2015 at 06:41:10PM +0000, Salz, Rich wrote:

> It kinda bothers me that at times the entire Internet security policy is
> being driven solely by data from one particular MTA.

You don't have to read all my posts... :-)

Also, my perspective is not from "one particular MTA", rather it
is a perspective based on a decade and half of building usable SMTP
transport security, which is a diverse mixture of opportunistic
and mandatory TLS, and interacts in interesting ways with DNS.

The converse viewpoint is that for too long Internet security has
been too narrowly driven solely by HTTPS.  Perhaps it is time to
consider additional perspectives (though of course not only such
perspectives).

There is a large majority of folks in all the various WGs who are
not working on SMTP let alone Postfix.  I don't think there's a
serious risk of hyper-focus.

-- 
	Viktor.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 30 Jul 2015 00:28:44 -0400

On Wed 2015-07-29 14:41:10 -0400, Salz, Rich wrote:
> It kinda bothers me that at times the entire Internet security policy
> is being driven solely by data from one particular MTA.

I share Rich's concern, and wish that more people were doing the kind of
excellent work that Victor is doing with Postfix.  We need more
engagement from other MTAs (and other network applications for that
matter).

Victor, thanks for your work, please keep it up.

          --dkg

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 30 Jul 2015 18:16:53 +0200

Hey Viktor,

> looks "better" (and perhaps actually is better).

That I didn't know. Interesting detail on OpenSSL. Of course there's a
very small percentage of hosts that only offer SSLv2. Another issue we
have is in figuring out what the e.g. SMTP hosts we find actually are.
Could be embedded devices or printers exposed on the internet that don't
really do a lot of traffic. Still I think it's an interesting study, I
don't know of anybody doing a similar one previously (as in: enumerating
TLS for the whole IPv4 space. Hubert Kario has monthly reports on the
Alexa Top 1 Mio for HTTPS). I'm currently comparing to MX records
associated with the Alexa Top 1 Mio, but these aren't necessarily
domains that also amount to significant e-mail traffic. What I do see
there is that a huge percentage are using GMail, some Office 365 and
similar cloud hosted solutions (run hasn't finished yet). Are you aware
of any data that'd be similar to a alexa list but for mail servers? What
we can do is to compare to transparency reports by Google or compare to
large universities, but that's far from definitive.

> in many implementations, so it often sorts after the nominally

Triple-DES would be the algorithm I'd chose here, it's below '128bit
security' but is to be the algorithm with the least known cryptanalytic
attacks known from the above list.

> better than cleartext.  Setting a floor security policy is left up

I agree to some extent. The problem is that SSLv2 and v3 are deprecated
protocols and these should /really/ be phased out. In terms of e-mail;
everything is moving far slower there than for Web (browsers vendors
penalize bad crypto settings). I don't know of a similar approach for
any mail protocol. People have suggested delaying e-mail from hosts that
offer weak security. But in the end that's not a good solution - it only
results in losing or annoying customers for providers that actively do
this for penalizing..

> RC4 support until the number of systems requiring RC4 drops further.

Sure, that's also the only option I currently see. Good that people are
working on that and giving some thought to this though!

> not appear in the first 64 slots, they'll try use 3DES and fail if

That's another detail I wasn't aware of, hence we haven't scanned
specifically for this (would also be useful to fingerprint the software
vendor / distribution of the servers we're connecting to).

We can do this kind of scan still, if you're interested. Can't put it on
the top of our priorities currently, but it would certainly be valuable
information.

> periodically would be very useful.

Sure. I hope we can continue these scans for as long as is relevant to
give some insights into deployment / security of the email ecosystem.
Details like the one's you've mentioned are exactly stuff we're looking
for if we're to continue our scans.

Thanks a lot for all your operational insights, very valuable!

Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 30 Jul 2015 18:23:27 +0200

Hi,

> EHLO response), that would be most useful for my DANE surveys.

We have collected this information and had already a look at it, though
not yet thoroughly. So we've compared CN and sAN entries to the hostname
we see in banner messages. Because we work on IP basis rather can
host-names, this information is not always something you can work with
(load balancers, large email hosting environments with lot's of servers
et cetera) - that's also an issue for doing DNS-based lookups on the
hosts we're scanning. Starting with PTR records isn't really a great
solution, but for some servers it does work.

> over 900 DNSSEC TLSA-record validated MX hosts.

I'd be interesting to compare our results for sure. I think I can
provide you with either the raw dataset or our results (CSV-file with
statistics).

Thanks again,
Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 30 Jul 2015 18:34:49 +0200

Hi Michael,

Michael Richardson wrote:
> RC4 is supported by 83% of end points that support crypto, or of 83% of
> end points that answer TCP?

This percentage is based on hosts that did complete a SSL/TLS handshake.

> I didn't see the total number of hosts scanned in the slides.

The number fluctuates from scan to scan (also our blacklist grows
slowly, but surely -- admins that wish their host or range to be excluded).

For the RC4 specific results:

	Supports RC4 | Does not Support RC4 |Total
SMTPS	2346023		505575		2851598
SMTP	1343406		213882		1557288
IMAPS	3373919		673466		4047385
IMAP	654987		109224		764211
POP3S	3303738		641314		3945052
POP3	3035752		473240		3508992

Our initial scans were based on Hosts collected by UMichigan (dataset:
3d2hbz9r9kh2fbrk-zgrab-results-25-smtp-starttls-full_ipv4-20150413T040703.json)
- We've since gone on to do our own IPv4 wide discovery scans (which
also include banners and X.509 data).

Aaron

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 30 Jul 2015 18:15:36 +0000

On Thu, Jul 30, 2015 at 06:16:53PM +0200, Aaron Zauner wrote:

> Still I think it's an interesting study, I
> TLS for the whole IPv4 space.

Back in January 2015 I got some data conducted by a contact in
Germany who had access to a 50Gbps link for a few days.  That scan
found 4.5 million IPv4 addresses with STARTTLS on port 25.

Today, I took a random sample of 100 hosts from that data, and was
able to complete a STARTTLS handshake with 76 of them.  Extrapolating,
we can estimate 3 million SMTP hosts with STARTTLS in that dataset.

> Hubert Kario has monthly reports on the
> domains that also amount to significant e-mail traffic.

The Alexa data correlates poorly with SMTP.

> What I do see
> of any data that'd be similar to a Alexa list but for mail servers?

I am not aware of any good source of volume-ranked email domains,
or just mail-receiving domains.  Google's transparency report is
not comprehensive.  They don't list "small" domains.  I receive
email from Gmail users, but my domain has never been listed in
Google's report.  Still their report can be viewed a good sample
of the larger domains.

> What

Yes, that's all one can do for now.

> attacks known from the above list.

Ditto, but since its nominal ranking is 112-bits, RC2 comes out on
top much of the time.

> > Setting a floor security policy is left up to the client.
> 
> penalize bad crypto settings).

With opportunistic security:

	https://tools.ietf.org/html/rfc7435

when a server or client sets the crypto bar too high, the result
is not more security, but less, because peers often resort to
cleartext when TLS fails.  Therefore, setting the bar too high is
counter-productive.

It is not very useful to measure the weakest ciphers supported,
you want to know the strongest supported (or most preferred), which
is what is negotiated in practice.

> I don't know of a similar approach for

That would be counter-productive (even foolish).  Cleartext is
weaker still.  The right thing to do is evangelize stronger security,
and encourage upgrades, so that once the weak options are inessential,
they can be dropped.  This takes longer than in the browser space,
but that's to be expected.  On the other hand 80% of Google's
outbound email is TLS encrypted.  What do you think the ratio
of HTTPS to HTTP is?

> > if the negotiated cipher is DES-CBC3-SHA, you need to send both

Both of course *after* STARTTTLS, (there's another EHLO before
STARTTLS, but that's not the one I'm talking about).

> vendor / distribution of the servers we're connecting to).

Yes, the particular Microsoft Exchange release number in the banner
is often a good indication of potential for this problem.  But the
issue is also present in some other SMTP products running on Windows
2003 (server appliances).

> the top of our priorities currently, but it would certainly be valuable

It would be very valuable to know which systems interoperate ONLY
via RC4-SHA/RC4-MD5 and fail with all other ciphers (despite
appearing to support 3DES).  If that's something you can scan for,
that would be great.

I have a reasonable dataset of IPs (from January), but not the
bandwidth (or software on hand) to repeat the scan.

-- 
	Viktor.

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 30 Jul 2015 21:09:17 +0200

Hi,

> found 4.5 million IPv4 addresses with STARTTLS on port 25.

Our infrastructure is currently limited to a single i7 box with 8 cores
on a 100mbit connection with our provider insisting we can't do more
than 70k connections per second, because that interferes with their
network core :)

So if providers would be willing to help us out with VMs or bare metal
which we can use for continued scans - we'd be very grateful for that.

Our TLS enumeration scans take months at a time because we needed to
build in delays between handshakes for a given host - some daemons are
seem to be easily DoSed otherwise.

> we can estimate 3 million SMTP hosts with STARTTLS in that dataset.

Sounds about right.

> The Alexa data correlates poorly with SMTP.

Certainly. The amount of large websites not using their own email
infrastructure is an interesting observation in my opinion.

> is what is negotiated in practice.

I know of that RFC and I agree. There's currently no other viable
approach than to "spread the word". Opportunistic and weak crypto is
certainly better than plaintext. Most mail clients are by default not
set to *require* TLS, so for an active attacker it's easy downgrading to
plaintext.

> they can be dropped.

Totally agree there. I've argued against any of these suggestions in the
past.

> appearing to support 3DES).  If that's something you can scan for,

We'll take a look into that in the future!

> bandwidth (or software on hand) to repeat the scan.

There's two options which we can work out rather quickly to set this up;
either integrate support for SMTP and STARTTLS messaging in `masscan`,
or write a simple plugin to `sslyze` to perform such scans. I don't have
an exchange 2003 server I can test this against during development though.

The first thing we analyzed was the percentages of TLS versions and
cipher-suites shared among all scanned host and protocols. I have
forgotten to include these in my slides. TLS 1.0 is most widely
supported. Attached is a CSV file with a mapping of TLS protocol
version, accepted-, recjected and preferred cipher-suites. It also
contains the total (for all the protocols we've scanned). We'll publish
our raw datasets to scans.io in the foreseeable future.

Also attached is a mapping of TLS versions to cipher-suite and DH group
size, which you requested a few days ago (for SMTP and SMTPS [465]).

We haven't yet finished our scan on MSA port 587.

HTH,
Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 30 Jul 2015 21:14:31 +0200

Hi Hector,

Hector Santos wrote:
> I see what was written as the conclusions; you're the first, more data
> is needed and you have data for others to see.  What were the goals?
>  EMail is not secured?
> 

Getting a better view of TLS and security extensions as deployed
currently on the internet for e-mail protocols and possible to track
change over time. People do these scans regularly for the Web (HTTPS), I
think it's important to have such studies for E-Mail as well.

Aaron

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 30 Jul 2015 21:50:08 +0000

On Thu, Jul 30, 2015 at 04:10:56PM -0400, Michael Richardson wrote:

>     >> RC4 is supported by 83% of end points that support crypto, or of 83%
>     >> of end points that answer TCP?
> 
> okay, so whle we might cringe at how many hosts are using weak crypto,
> we might also be elated (if we had numbers) about how many hosts support
> *any* crypto...

Note that RC4 *use* is much lower than RC4 *support*...

Lots of servers support RC4, to interoperate with legacy peers,
but in practice very rarely negotiate it.  Many of the below support
RC4, but in practice you get much stronger crypto:

    $ for d in gmail.com outlook.com yahoo.com aol.com hotmail.com microsoft.com gmx.de t-online.de web.de
      do
	posttls-finger -c -lencrypt -Lsummary $d
      done
    posttls-finger: ... gmail-smtp-in.l.google.com... TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
    posttls-finger: ... mx2.hotmail.com... TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)
    posttls-finger: ... mta7.am0.yahoodns.net... TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
    posttls-finger: ... mailin-03.mx.aol.com... TLSv1 with cipher ADH-AES256-SHA (256/256 bits)
    posttls-finger: ... mx2.hotmail.com... TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)
    posttls-finger: ... microsoft-com.mail.protection.outlook.com... TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)
    posttls-finger: ... mx01.emig.gmx.net... TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)
    posttls-finger: ... mx03.t-online.de... TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
    posttls-finger: ... mx-ha03.web.de... TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)

    $ for d in gmail.com outlook.com yahoo.com aol.com hotmail.com microsoft.com gmx.de t-online.de web.de
      do
	posttls-finger -c -lencrypt -o tls_medium_cipherlist=RC4-SHA -Lsummary $d
      done
    posttls-finger: ... gmail-smtp-in.l.google.com... TLSv1.2 with cipher RC4-SHA (128/128 bits)
    posttls-finger: ... mx4.hotmail.com... TLSv1.2 with cipher RC4-SHA (128/128 bits)
    posttls-finger: ... mta5.am0.yahoodns.net... TLSv1.2 with cipher RC4-SHA (128/128 bits)
    posttls-finger: ... mailin-01.mx.aol.com... TLSv1 with cipher RC4-SHA (128/128 bits)
    posttls-finger: ... mx2.hotmail.com... TLSv1.2 with cipher RC4-SHA (128/128 bits)
    posttls-finger: SSL_connect error to microsoft-com.mail.protection.outlook.com... lost connection
    posttls-finger: SSL_connect error to mx01.emig.gmx.net... -1
    posttls-finger: ... mx03.t-online.de... TLSv1.2 with cipher RC4-SHA (128/128 bits)
    posttls-finger: SSL_connect error to mx-ha02.web.de... -1

Lack of RC4 support at three of the above just means that email
they receive from some legacy systems is sent in the clear.

It has been rumoured that Yahoo's outboud systems prefer RC4, and
unless servers impose their own cipher priority, mail from Yahoo
uses RC4.  I've not personally tested that for some time, so that
"factoid" may be stale...

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 30 Jul 2015 22:34:16 +0000

> an exchange 2003 server I can test this against during development though.

FWIW here's a sample problem server (name and IP of guilty party
sent off-list only):

    $ posttls-finger -o 'tls_medium_cipherlist=3DES' amnesiac.example
    posttls-finger: Connected to amnesiac.example[192.0.2.1]:25
    posttls-finger: < 220 amnesiac.example Microsoft ESMTP MAIL Service, Version: 6.0.3790.4675 ready at  Thu, 30 Jul 2015 22:15:28 +0000
    posttls-finger: > EHLO amnesiac.local
    posttls-finger: < 250-amnesiac.example Hello [192.0.2.2]
    posttls-finger: < 250-TURN
    posttls-finger: < 250-SIZE
    posttls-finger: < 250-ETRN
    posttls-finger: < 250-PIPELINING
    posttls-finger: < 250-DSN
    posttls-finger: < 250-ENHANCEDSTATUSCODES
    posttls-finger: < 250-8bitmime
    posttls-finger: < 250-BINARYMIME
    posttls-finger: < 250-CHUNKING
    posttls-finger: < 250-VRFY
    posttls-finger: < 250-TLS
    posttls-finger: < 250-STARTTLS
    posttls-finger: < 250 OK
    posttls-finger: > STARTTLS
    posttls-finger: < 220 2.0.0 SMTP server ready
    posttls-finger: amnesiac.example[192.0.2.1]:25: Matched subjectAltName: *.example
    posttls-finger: amnesiac.example[192.0.2.1]:25: subjectAltName: example
    posttls-finger: amnesiac.example[192.0.2.1]:25 CommonName *.example
    posttls-finger: server certificate verification failed for amnesiac.example[192.0.2.1]:25: certificate has expired
    posttls-finger: Untrusted TLS connection established to amnesiac.example[192.0.2.1]:25: TLSv1 with cipher DES-CBC3-SHA (112/168 bits)
    posttls-finger: > EHLO amnesiac.local
    posttls-finger: < 250-amnesiac.example Hello [192.0.2.2]
    posttls-finger: < 250-TURN
    posttls-finger: < 250-SIZE
    posttls-finger: < 250-ETRN
    posttls-finger: < 250-PIPELINING
    posttls-finger: < 250-DSN
    posttls-finger: < 250-ENHANCEDSTATUSCODES
    posttls-finger: < 250-8bitmime
    posttls-finger: < 250-BINARYMIME
    posttls-finger: < 250-CHUNKING
    posttls-finger: < 250-VRFY
    posttls-finger: < 250 OK
    posttls-finger: > QUIT
    posttls-finger: warning: TLS library problem: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:362:
    posttls-finger: warning: lost connection while sending QUIT command

The QUIT command sees a bad TLS packet because the preceding (inner)
EHLO command elicited a packet with extraneous padding, which messes
up the next response from the server.

The same server just hangs up (no alerts) if neither RC4 nor 3DES
are in the first 64 ciphersuites.

-- 
	Viktor.

---

From: Aaron Zauner <[email-masked]>
Date: Fri, 31 Jul 2015 09:53:33 +0200

> we might also be elated (if we had numbers) about how many hosts support

I think Carsten Bormann should have already pointed this out in his
message to this list earlier. His numbers are pretty similar to what we see.

Aaron

---

From: Tony Finch <[email-masked]>
Date: Fri, 31 Jul 2015 12:58:52 +0100

Viktor Dukhovni <[email-masked]> wrote:
> but in practice very rarely negotiate it.

Yes (with help from Viktor) my servers have a special cipher priority list
to ensure that they negotiate RC4 with old Windows 2003 Exchange servers.
I haven't checked recently if this is still necessary...

http://archives.neohapsis.com/archives/postfix/2013-11/0121.html

> uses RC4.

That's what it looks like to me.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Bailey: Northeasterly 6 to gale 8 at first in northwest, otherwise cyclonic 4
or 5. Rough at first in northwest, otherwise moderate. Rain or showers. Good,
occasionally poor.

---

From: Tom Ritter <[email-masked]>
Date: Fri, 31 Jul 2015 23:13:46 -0500

> outbound email is TLS encrypted.  What do you think the ratio

Agreed, although I would add "Name & Shame" to "Evangelize".  Especially
when one considers how much of corporate mail is hosted by third party
services - those services have a particular business interest in staying
up-to-date, lest their customers see them as being lackadaisical.

The email security tools that I'm aware of (Email Privacy Tester, checktls)
are great. But they need to slap a grade on it[0] and make it even more
friendly to use. Then we need to promote it like we have promoted SSLLabs.

-tom

[0] Unlike SSLLabs, the grade should not ding them for supporting weak
ciphers (like RC4) unless they actually prefer those ciphers. It should
have the correct context for email.