[Top] [All Lists]


2008-10-27 14:53:01

Tony Finch wrote:
The point of the certificate is to authenticate the name that the user
typed in. If you don't authenticate the right thing then you will fail to
detect attacks, for example, if an attack on the DNS produces a bogus name
-> IP addres translation and the attacker has a valid certificate for
that IP address.

I don't know why some certificate bear the IP _instead_ of the FQDN; could do both.

The same problem applies to the MX mail domain -> hostname mapping, where
TLS is insecure because authenticates the target not the source.

Do you mean the server requiring the client to STARTTLS?

If not, I think most server software can easily be modified so as to accept client certificates, if it doesn't accept them already. They are usually not _required_ to avoid handshake failures (e.g. the MDA software in turn asking the users which certificate they want to upload.)

Alternatively, after some sort of forwarding agreement has been established between two servers, in a TLS session it is possible to use rfc 4954 to say something like
   MAIL FROM:<original-envelope(_at_)example> AUTH=distinguished-relay

The distinguished name of the relay should help the spam filter in either case. After authentication, it makes little difference if it comes from the certificate or from a command parameter.

<Prev in Thread] Current Thread [Next in Thread>