not sure what you mean by that. with TLS the server is authenticated
via the server certificate. a hijacker doesn't have access to the
session key and can't set its own session key without causing the server
signature verification to fail.
TLS seems to work fine through proxies; what prevents the MitM
from setting up a proxy? (If OPES bears fruit, hijackers may
feast)
it depends on what you mean by proxy. if the client has an explicit
proxy and is talking to that proxy in cleartext, it can ask the proxy
to start a TLS session, but it won't be encrypted end-to-end. however
in that case the client has explicitly specified a proxy to use, and an
attacker would have to intercept traffic to that proxy (which is
doable).
otoh, if someone has set up an interception proxy by whatever means,
the traffic between client and server is encrypted. the proxy can
relay the bits without changing them but it can't tamper with the
traffic without causing an error.
Also bear in mind that there are different levels of TLS
authentication: server, client, and both. HTTP typically
authenticates the server to the client; SMTP AUTH typically
authenticates the client to the server. In the former (HTTP)
case, if the server wishes to authenticate the user, some
additional method (e.g. login/password) is used. For SMTP
AUTH, well the client just can't tell for sure if it's talking
to the real McCoy.
TLS always authenticates the server to the client; client-to-server
authentication using TLS (and client certs) is optional. TLS client-to-
server authentication is sufficient to thwart man in middle attacks.
Whether SMTP AUTH is vulnerable to a MitM attack depends on
the particular auth method used - Kerberos and some of the
GSSAPI methods should be okay, LOGIN, PLAIN, and challenge
response methods are not. OTOH if you do SMTP AUTH over
TLS you're safer.
of course, there are clients that don't check server certificates,
There's a problem with certificates (also other schemes); they rely
on some sort of trust relationship. For certificates in particular,
there's a self-signed certificate at the end of the chain (or the
moral equivalent).
right, and that party has to defend its certificates by repuation
and by publishing them widely.
Why should I trust a certificate from some company in South Africa
that I've never dealt with? Worse, what about this other certificate --
isn't that the company that screwed up DNS for everybody with bogus
wildcards -- "I trust [them] as far as I can comfortably spit out
a rat"?
yup.
In practice -- because mere mortals don't know enough about every
individual and organization that might present a certificate or
other token -- it tends to become just another "click on yes"
annoyance. Maybe once in awhile (say, isn't that the company
that screwed up DNS...) it's "click on no", but then things don't
work so it's quickly back to "click on yes".
This is a particularly problematic issue for mail as distinct
from http. The fundamental premise of email is that anybody can
send to anybody else -- how is a user supposed to keep track of
chains of certificates for billions of potential correspondents
and figure out whether or not to accept one from a stranger (who
might be a potential customer/employer/benefactor, or might be a
spammer)?
How would this work for the typical Internet user -- whose mail
is received by an ISP into a POP mailbox, which is then downloaded
by the user -- when mail is received by the ISP, the user may be
off-line (and unable to respond to certificates); POP has no
per-message certificate exchange mechanism?
all valid issues, but I don't have time to discuss them right now.
(any chance you'll be at IETF Paris?)
there are multiple ways to solve the problem. one is that if a user
provides a certificate to the MSA that says "I have permission to use
this set of addresses in SMTP MAIL FROM" then the MSA permits such use.
Do self-signed certificates count? What about ones signed by
entities know to have caused damage to the email infrastructure?
Who decides? On what basis? How would this work with your
scenario of having to use a strange MSA? What if no MSA is
available (some ISPs support only an MTA for sending; in other
cases it may be necessary to connect directly to a recipient's
MX MTA to work around DNS or other network problems)? Who
decides when an SMTP receiver is an MSA or MTA? How can the
client tell the difference?
good questions, all things that would need to be addressed in a
formal proposal before it could be approved. I bet you can come
up with reasonable answers for most of them yourself.
another way (which only works for individual addresses) is that you get
the MON to send a single message to a MAIL FROM address, the message
contains a cookie, you reply to the message, now the MON knows you can
read mail sent to that address and so are presumably able to use it.
A widely-respected (if anything, not respected widely enough) rule
is "never respond to spam". How is a typical user (ESR's Aunt Tillie,
for example) supposed to be able to distinguish such an unsolicited
message from that sent by a spammer who is simply trying to confirm
mailboxes in preparation for a new "Two Hundred Million Verified Email
Addresses" CD-ROM?
because in the case of establishing yourself to an MSA that you have a
right to use a MAIL FROM address, you initiated the action that caused
the verification message to be sent, and you're expecting that message
to arrive at your inbox.
of course, the MSA has to guard itself against this technique being used
as a way to send yet more annoying mail. e.g. by rate limiting,
by insisting that the initial request come from a web site that is
resistant to manipulation by robots.
another is that the MSA makes the mail traceable in some way other than
MAIL FROM to a user who can be held accountable for his actions - then
if the user sends out mail that abuses MAIL FROM then he gets billed for it.
Billed by whom?
e.g. the MSA requires a credit card # (with all of the usual verification for
credit card purchases), and if the MSA gets abused then it bills that credit
card for services related to cleaning up the damage (perhaps the fees
are shared with other parties who were harmed).
the devil is in the details, of course, but we do things like this routinely
in other areas. credit card fraud exists, but that doesn't stop us from
using credit cards.
Keith