From: "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com>
Without authenticators such as shared secrets or public keys, it is
obvious that SSL or TLS does nothing against a classic
man-in-the-middle attack.
If you read the damn spec you will realise that it is obvious that
it supports that use. I fact I don't believe SSL supports any other
use whatsoever.
So your statement being vulnerable against a man in the middle
attack would be pure unadulterated B/S.
As is the rest of your message.
I don't understand which is the use that "it is obvious that it supports
that use." I hope that is not a claim that SSL/TLS can only be used
with PKI or other authentication systesm. SMTP-TLS and HTTPS (HTTP/TLS)
are frequently used in supported modes do not provide much authentication.
Reading the standards can be useful, particularly for those without
direct experience implementing, installing, or maintaining installations
of the protocols. (That evidently includes many of us here and for
more than just TLS, HTTPS, and SMTP-TLS). See for example page 4 of
RFC 2246 which says:
- The peer's identity can be authenticated using asymmetric, or
public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
authentication can be made optional, but is generally required
for at least one of the peers.
Without shared secrets or public keys to provide authentication,
SSL/TSL does not and cannot provide authentication. A man-in-the-middle
attack when there are no shared keys is as easy as inserting a system
into the path between the victims. That can be done with DNS spoofing
or various routing games including ARP tricks.
Consider the case of using TLS to connect to port 25, 80, or 587 on
www.rhyolite.com. Unless your SMTP or HTTP client has a trustworthy
copy of the self-signed certificate for www.rhyolite.com, you client
cannot know that it is talking directly to my SMTP or HTTP server.
A bad guy could have tricked your client into thinking that the IP
address for www.rhyolite.com is his IP address. When your client
connects to what it thinks is my system, it would really be talking to
the bad guy's system. The bad guy's system can make a second connection
to my system, and pass whatever your systems sends to mine and vice
versa. The bad guy can see all of our bits and modify them.
(I realize that I'm repeating this for the third time in the last 24
hours. That I've apparently not been clear to one person suggests
that I've not been clear to other people.)
If your client has a copy of the self-signed certificate for
www.rhyolite.com, you need to ask whether it is trustworthy. A bad
guy could have intercepted your HTTP or FTP connection to 192.188.61.3
when you fetched that certificate and replied with his version of my
certificate. (Anyone who really needs my certificates or other
keys contacts me out of band.)
Go read Bruce Schnier's Secrets and Lies. It took a long time before
he understood that security was a matter of risk control rather than
risk elimination.
Bruce Schnier has been repeating that and other good observations for
years. I don't think he or anyone who has thought about security
needed to be told that obvious fact or other obvious facts such as
the importance of looking at the system instead of only the algorithms
or at the whole path instead of only the middle. On the other hand,
many who swallowed security snake oil have been flabbergasted by the
observations in "Secrets and Lies."
Apply that observation to HTTPS or SMTP-TLS to 192.188.61.3, the
likelihood of a man in the middle for anyone using TLS to 192.188.61.3
is very low. It's just not worth the effort to insert a man in the
middle between my systems and strangers'. Also low but not quite as
low is the possibility of someone or some agency snooping on our packets.
Snooping in this case without an man in the middle is not practical,
despite any lack of shared, trustworthy certs.
Another application of Bruce Schnier's observations is that men in
the middle can be inserted in many places. Someone who has obtained
a trustworthy copy of the right authenticators, such as by courier
or commercial PKI is still vulnerable to a man in the middle. It's
easy to install software on a Windows box that will modify keyboard
"messages" (not network but WIN32 API things) and other data and
so redirect the victim, or just capture keystrokes. The bad guy
would be in the middle of the path between the user's fingers and
eyes and any other system, albeit not in the middle of the middle.
Vernon Schryver vjs(_at_)rhyolite(_dot_)com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg