On Tue, 02 Nov 2010 at 18:11:18 -0400, zhong ming wu wrote: > Moreover assuming DNS is safe (big assumption in the past & some will > say now) should client not do DNS look up and then use server cert to > verify authenticity of it
DNS can't be assumed to be safe; anything we're told via a SRV lookup is suspect. The thing we're trying to verify is: * the user told us to connect as [email protected], therefore they wanted to talk to the example.com server * we got a connection to a server claiming to serve example.com * is it really authorized to act on behalf of example.com? If there's a SRV record telling us we should actually connect to jabber.services.example.net (or whatever), accepting a certificate for jabber.services.example.net would be unsafe, because that's not what the user asked for. > TLS implementation of HTTP/SMTP/IMAP/POP do not work like XMPP in this regard HTTPS doesn't do SRV lookups, but when you use a CNAME it behaves just like XMPP. If I connect to https://www.google.com/ I get this: s...@reptile% dig www.google.com ... ;; QUESTION SECTION: ;www.google.com. IN A ... ;; ANSWER SECTION: www.google.com. 348 IN CNAME www.l.google.com. www.l.google.com. 156 IN A 209.85.227.103 ... (and more geolocated addresses for www.l.google.com) and when I connect to 209.85.227.103 (or whatever), it presents a certificate for www.google.com (not for www.l.google.com or 209.85.227.103). S
