Why is STARTTLS preferred over tls_on_connect_ports?

[Marc Sherman]

After writing the answer to Guy De Leeuw's question about TLS, I got to
thinking; why is STARTTLS after connection on ports 25/587 preferred to
tls_on_connect_ports on port 465? I know that the latter was only
implemented recently, and previously it required a seperate daemon
running with a command line switch, but the emails discussing that
implied that implementing tls_on_connect_ports wasn't just a pain, it
was distasteful and wrong as well. What's the reasoning behind that?

It seems to me that with tls_on_connect_ports, you get a slightly* more
secure session, because the HELO/EHLO doesn't travel in the clear,
reducing the info available for traffic analysis by an attacker.

* Ok, minutely.

- Marc

[Lars Mainka]

Hi Marc,

Post by Marc Sherman
After writing the answer to Guy De Leeuw's question about TLS, I got to
thinking; why is STARTTLS after connection on ports 25/587 preferred to
tls_on_connect_ports on port 465? I know that the latter was only
implemented recently, and previously it required a seperate daemon
running with a command line switch, but the emails discussing that
implied that implementing tls_on_connect_ports wasn't just a pain, it
was distasteful and wrong as well. What's the reasoning behind that?

Don't know, but IMHO SMTP should only be used on port 25. Every other port have to be known before
to connect to, and this is usually only possible for known mail hosts.

Post by Marc Sherman
It seems to me that with tls_on_connect_ports, you get a slightly* more
secure session, because the HELO/EHLO doesn't travel in the clear,
reducing the info available for traffic analysis by an attacker.

In my opinion, tls_on_connect is nothing else than STARTTLS in the meaning of security. Since you
can configure Exim to allow only EHLO/HELO and STARTTLS on connect the result will be the same. You
won't get more informations about the client connecting the server if you did not use
tls_on_connect, cause the layer 3 informations, like IP address and so on will be the same.

And it is definitly not correct, that tls_on_connect will give you more security. Both tls on
connect and STARTTLS will (or better should) use the same level of security. The encryption is the
same, the main difference is *when* the encryption will be negotiated between the hosts. On connect,
you have to agree connection informations before to connect, on the other hand with STARTTLS you can
negotiate those informations within an established connection. TLSv1 is more comfortable than to
agree these informations before.

[Marc MERLIN]

Post by Lars Mainka
Don't know, but IMHO SMTP should only be used on port 25. Every other
port have to be known before to connect to, and this is usually only
possible for known mail hosts.

Actually 587 is quite useful: you can set it as an accept STARTTLS/AUTH
only port for all your remote users who would otherwise get their
outbound 25 traffic blocked.
I've never liked the fact that MUA to MTA communication used the same
port as MTA to MTA communication. It just made configuration and
filtering that much harder. 587 is poised to fix this.

Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems & security ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | Finger ***@merlins.org for PGP key

[Tony Finch]

Post by Marc Sherman
After writing the answer to Guy De Leeuw's question about TLS, I got to
thinking; why is STARTTLS after connection on ports 25/587 preferred to
tls_on_connect_ports on port 465?

It's because of IETF policy. Protocols should only be run on one port and
should have built-in security, rather than having a separate secure
version of the protocol on a different port.

Post by Marc Sherman
It seems to me that with tls_on_connect_ports, you get a slightly more secure
session, because the HELO/EHLO doesn't travel in the clear, reducing the info
available for traffic analysis by an attacker.

Actually the information in the HELO command is completely uninteresting
to an attacker. The real reason that TLS-on-connect is more secure than
STARTTLS is because it is more resistant to downgrade attacks. However
this is mostly to do with the bad quality of implementation of most SMTP
clients - they encourage users to make security optional rather than
required, which makes the attacker's job much easier.

Tony.

[Marc Sherman]

Post by Tony Finch
It's because of IETF policy. Protocols should only be run on one port
and should have built-in security, rather than having a separate
secure version of the protocol on a different port.

That makes sense. But given that I'm interested in "465 or 587 for
submission?" rather than "25 or 25+465 for SMTP?", it seems like a wash
to me.

Post by Tony Finch
Actually the information in the HELO command is completely
uninteresting to an attacker.

Completely uninteresting? Ok, I'll bite. I'm a junior IT guy at
Acquisicorp. I get minimum wage to sit on a stool in the network
closet, watching the blinking lights, changing the bulbs as they burn
out. I've managed to get a box on the network doing passive
eavesdropping on all our incomming traffic on port 587. No-one was
worried about the possibility, since the only unencrypted traffic on
that port is completely unintersting.

I happen to know that a certain hotshot M&A guy at Acquisicorp has his
laptop set up to send "EHLO hot.grits". It's a bogus EHLO string, but
it is (fairly) unique. My eavesdropping box can record IP/EHLO pairs
for all incomming connections on port 587, before the STARTTLS command.
By searching for hot.grits, and doing reverse lookups on the IP
addresses, I can figure out what possible target companies Mr. Hotshot
M&A guy is scouting for hostile takeover this week, and Buy Low, Sell
High! It's a victimless crime!

Post by Tony Finch
The real reason that TLS-on-connect is more secure than STARTTLS is
because it is more resistant to downgrade attacks. However this is
mostly to do with the bad quality of implementation of most SMTP
clients - they encourage users to make security optional rather than
required, which makes the attacker's job much easier.

Yeah, I'd thought of that, too, but I've already got my clients secured
against that, so I didn't mention it.

- Marc

[Lars Mainka]

Post by Tony Finch
Actually the information in the HELO command is completely uninteresting
to an attacker. The real reason that TLS-on-connect is more secure than
STARTTLS is because it is more resistant to downgrade attacks. However
this is mostly to do with the bad quality of implementation of most SMTP
clients - they encourage users to make security optional rather than
required, which makes the attacker's job much easier.

If STARTTLS is used as it should be, in example using strong certificate verifying, checking
encryption within the connection, strong authentication methods, denying weak ciphers and so on, you
should be as secure as with tls_on_connect.

Unfortunately the handling of the TLS/SSL implementations in clients are really bad and not
transparent.

[David Brodbeck]

-----Original Message-----
I happen to know that a certain hotshot M&A guy at
Acquisicorp has his
laptop set up to send "EHLO hot.grits". It's a bogus EHLO
string, but
it is (fairly) unique. My eavesdropping box can record IP/EHLO pairs
for all incomming connections on port 587, before the
STARTTLS command.
By searching for hot.grits, and doing reverse lookups on the IP
addresses, I can figure out what possible target companies
Mr. Hotshot
M&A guy is scouting for hostile takeover this week, and Buy Low, Sell
High! It's a victimless crime!

Sounds pretty far fetched. And with TLS-on-connect you could still get
similar information by looking at where the packets are coming from. ("Gee,
this client is coming from an IP block owned by Hot Grits, Inc.!")

Besides, Mr. IT Guy would probably be better off with a keylogger. Next
you'll have to worry about keyboard-to-CPU TLS. ;)

[Marc Sherman]

Post by David Brodbeck
Sounds pretty far fetched. And with TLS-on-connect you could still get
similar information by looking at where the packets are coming from. ("Gee,
this client is coming from an IP block owned by Hot Grits, Inc.!")

Hey, I never said it was a _lot_ of info, just that it was non-zero. :)

- Marc

[John W. Baxter]

Post by Marc Sherman
After writing the answer to Guy De Leeuw's question about TLS, I got to
thinking; why is STARTTLS after connection on ports 25/587 preferred to
tls_on_connect_ports on port 465?

The main reason tls_on_connect is still around is Microsoft, whose clients
believe that STARTTLS has meaning only on port 25, while when told to use
secure connections to other ports do tls on connect.

If I'm wrong, please tell me how to set them up...I'd be delighted to stop
worrying about whether we're going to have to turn port 465 back on (at
least it's easier now than it was before).

--John