28 Oct
2011
28 Oct
'11
3:02 p.m.
Hi,
This is absolutely not the case and is a very dangerous simplification
of what is actually happening.
In a connection that is encrypted from the start the client is expecting
to see a correctly signed certificate. If you get the wrong certificate
or something that is not correctly signed then you find out and the
connection fails.
In a connection that starts unencrypted and switches to an encrypted
mode later there is usually some kind of capabilities detection phase
where the client and server negotiate the kinds of things they will do
without encryption and the kinds of encryption that they support.
This is a much easier situation to hijack with a man-in-the-middle
attack. The attacker impersonates the server and replies with
capabilities that allow plain text authorization without encryption and
does not advertise support for encryption at all.
Lots of clients will then authenticate against the man-in-the-middle and
reveal their credentials. Lots of (mail) clients have to be carefully
configured to ensure that they always insist on TLS on
unencrypted-by-default ports and that they never use a plain text
equivalent password protocol.
There is far less margin for user error or misconfiguration on
encrypted-only ports.
Why do people
bother with starttls, bound to be open to all sorts of man
in the middle attacks, this is why nobody ever bothered using it for
escalating HTTP connections.
I don't think that's true.
The starttls command could indeed be mitm-attacked, but to exactly the same
extent so could the initial TCP negotiation to SSMTP port 465. Think of
STARTTLS as being equivalent to the TCP SYN packet and you can see it makes no
difference at all how the initial unencrypted contact is made. The SSL/TLS negotiation includes a certificate phase
for exactly this reason.
You can only check a certificate if you know for sure that you're
expecting one. You only know for sure that you're expecting one if
you're using an encrypted-by-default port.
There's no more wrong with STARTTLS protocols than
there is with running a
service on a different port to mark it as encrypted.
See above.
The only potential problem is allowing clients that
aren't encrypted: you can
either say "that's their problem", or require that the server deny all
client
commands _except_ STARTTLS on an unencrypted connection. To be honest, I have
no idea why we have this constant dual-allocation of ports for single
services. It's a waste of well-known port numbers; http/https included.
Well maybe now you do. ;-) It's a much, much deeper issue than you realise.
PS: That comment is meant in a light-hearted way: it's amazing the
amount of people who I correspond with on a daily basis who don't
actually know what the smiley is for any more. :-)
This is a very easy mistake to make and it's a misunderstanding that I
myself had for some time.
Having the server deny everything but STARTTLS is all well and good if
the client knows to expect it, but it's far from the default behaviour
and it's often quite fiddly to actually configure in most user agents.
Whilst your server may deny everything but STARTTLS, a man-in-the-middle
doesn't have to and may be able to take advantage of your client's naiveté.
It's only been relatively recently that the majority of people have
really understood the importance or relevance of encrypting *everything*
as opposed to just the password protocol (see Google vs China, for example).
Supporting 100% encrypted connections as opposed to mostly unencrypted
connections is an ongoing area of research for service providers as
server resources become significantly more difficult to manage: CPU,
memory footprint, TLS caches, load balancing multiple connections from
the same client, etc.
Regards,
@ndy
--
andyjpb(a)ashurst.eu.org
http://www.ashurst.eu.org/
0x7EBA75FF