409372 - Domain Name Mismatch when using IP address as SMTP server

Status: RESOLVED INCOMPLETE

(Core :: Security, defect)

Description

[Fernando Cassia]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.11) Gecko/20071128 SeaMonkey/1.1.7
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.11) Gecko/20071128 SeaMonkey/1.1.7

For security reasons (ie I don't trust my ISP's DNS) I choose to use IP addresses for all my SMTP servers in SeaMonkey mail.

So, instead of SMTP.GMAIL.com I put 209.85.133.111.

The problem arises when SeaMonkey does a SSL connection to 209.85.133.111 and decides that there's a "domain name mismatch" because 209.85.133.111 does not match SMTP.GMAIL.COM which is what the security certificate says.

Well, gee, excuse me for my stupidity, but can't Mozilla/SeaMonkey do a REVERSE  NS LOOKUP on 209.85.133.111 and find out that the IP address resolves to SMTP.GMAIL.COM which... OH BOY... matches the security certificate presented?.

In other words... the function should check that the HOST NAME and the CERTIFICATE match. If I provide an IP address, it's the browser's job to FIND OUT THE HOST NAME, and then compare that (not the IP address!) with the security certificate data.



Reproducible: Always

Steps to Reproduce:
1. Configure SeaMonkey Mail with a GMail account. Change the SMTP server from SMTP.GMAIL.COM to one of the IP addresses for the hostname. Select SSL.
2. Compose and send an e-mail.

Actual Results:  
"Domain Name Mismatch: you have attempted to establish a connection with "72.13.205.109". However, the security certificate presented belongs to "smtp.gmail.com".


Expected Results:  
It should resolve the IP address to a hostname first, and THEN compare the hostname (not the IP address) to the security certificate.

Comment 1

[Philip Chee]

Asking c.root-servers.net for 111.133.85.209.in-addr.arpa PTR record:  
       c.root-servers.net says to go to epazote.arin.net. (zone: 209.in-addr.arpa.)
Asking epazote.arin.net. for 111.133.85.209.in-addr.arpa PTR record:  
       epazote.arin.net [192.41.162.32] says to go to ns3.google.com. (zone: 133.85.209.in-addr.arpa.)
Asking ns3.google.com. for 111.133.85.209.in-addr.arpa PTR record:  Reports an-in-f111.google.com. [from 216.239.36.10]

Answer:
209.85.133.111 PTR record: an-in-f111.google.com. [TTL 86400s] [A=209.85.133.111]

Doing the same for 72.13.205.109 just goes into an endless loop.

Searching for smtp.gmail.com A record at f.root-servers.net [192.5.5.241]: Got referral to A.GTLD-SERVERS.NET. (zone: com.) [took 50 ms]
Searching for smtp.gmail.com A record at A.GTLD-SERVERS.NET. [192.5.6.30]: Got referral to ns4.google.com. (zone: gmail.com.) [took 32 ms]
Searching for smtp.gmail.com A record at ns4.google.com. [216.239.38.10]: Got CNAME of gmail-smtp.l.google.com. and referral to d.l.google.com. [took 39 ms]
Searching for gmail-smtp.l.google.com A record at m.root-servers.net [202.12.27.33]: Got referral to D.GTLD-SERVERS.NET. (zone: com.) [took 156 ms]
Searching for gmail-smtp.l.google.com A record at D.GTLD-SERVERS.NET. [192.31.80.30]: Got referral to ns4.google.com. (zone: google.com.) [took 29 ms]
Searching for gmail-smtp.l.google.com A record at ns4.google.com. [216.239.38.10]: Got referral to b.l.google.com. (zone: l.google.com.) [took 39 ms]
Searching for gmail-smtp.l.google.com A record at b.l.google.com. [64.233.179.9]: Reports gmail-smtp.l.google.com. [took 23 ms] Response:
Domain	Type	Class	TTL	Answer
gmail-smtp.l.google.com.	A	IN	300	66.249.93.109
gmail-smtp.l.google.com.	A	IN	300	66.249.93.111
NOTE: One or more CNAMEs were encountered. smtp.gmail.com is really gmail-smtp.l.google.com.

66.249.93.111 PTR record: ug-in-f111.google.com. [TTL 86400s] [A=66.249.93.111]
66.249.93.109 PTR record: ug-in-f109.google.com. [TTL 86400s] [A=66.249.93.109]

Doing a reverse NS lookup does not appear to result in smtp.gmail.com.

Comment 2

[Martin Sch]

Same happens for POP3 and IMAP servers. Thunderbird complains about a domain name mismatch between pop3.myprovider.com and 129.138.11.19

This is not correct. Would 129.138.11.19 be resolved and then checked against the cert, the message should not mention the ip address.

But I assume the ip address as a string is compared with the domain name.

Comment 3

[Serge Gautherie (:sgautherie)]

While I understand you user point of view,
the security point of view is the opposite:
afaik, it's up to the certificate to list the "domain(s)" it's valid for.

R.Invalid.

Reopen if you think otherwise.
(Which other "SSL" agent works as you describe ?
Is this behavior specified somewhere (official) ?)

Comment 4

[Martin Sch]

Well if I connect to 129.138.111.19 and this address belongs (resolves) to bigmailservice.com, and this server then sends a certificate for bigmailservice.com, then thunderbird complains about a wrong certificate.

This is definitly not correct. The certificate is correct and identifies bigmailservice.com and 129.138.111.19 also points to bigmailservice.com.

(all domain names in ip addresses are just random names - pls. do not proof)

Comment 5

[u279076]

Resolving unconfirmed bugs older than a year with no activity as INCOMPLETE.  Please reopen or file a new bug if you can still reproduce the bug.