1236155 - Information leakage problem when using smtp + starttls

Status: RESOLVED WONTFIX

(MailNews Core :: Networking: SMTP, defect)

Description

[sabine_28195]

User Agent: Mozilla/5.0 (compatible)
Build ID: 20151221065651

Steps to reproduce:

Setup an account using starttls to secure the smtp connection.
Send an email while capturing the traffic using wireshark.
Look at the line with the ehlo command from the client to the server.


Actual results:

The client sends an ehlo request to the server to start the tls connection.
this request contains the ip address of the client.

e.g. 
ehlo [1.2.3.4]



Expected results:

According to the smtp protocol definition, the ehlo command sends the "client" FQDN to the remote server, assuming however a server to server connection.

Other Mail Clients use the hostname (not the FQDN) for the ehlo command, which also is some kind of information leakage, since individual hostnames can identify clients.

However leaking the private ip can be catastrophic, e.g. when using VPN connections for privacy reasons. Since the "ehlo [ip]" is unencrypted it is possible to identify the client after the traffic leaves the VPN. This is just one example.

The ehlo command does not need a specific string to be accepted by the server.
"ehlo random_string" is accepted just als well.
The best case solution should provide the most possible privacy for the user.

Comment 1

[:aceman]

Assuming we support RFC 2821, this seems to be the relevant section:

4.1.1.1  Extended HELLO (EHLO) or HELLO (HELO)

   These commands are used to identify the SMTP client to the SMTP
   server.  The argument field contains the fully-qualified domain name
   of the SMTP client if one is available.  In situations in which the
   SMTP client system does not have a meaningful domain name (e.g., when
   its address is dynamically allocated and no reverse mapping record is
   available), the client SHOULD send an address literal (see section
   4.1.3), optionally followed by information that will help to identify
   the client system.  y The SMTP server identifies itself to the SMTP
   client in the connection greeting reply and in the response to this
   command.

The relevant code is here:
http://mxr.mozilla.org/comm-central/source/mailnews/compose/src/nsSmtpProtocol.cpp#338

Comment 2

[sabine_28195]

Since there is no need to send any specific information and according to RFC 2821 sending the hostname is not necessary, the optimal solution would be to send a random string. That would also provide the most privacy.

This can be archived by replacing this section http://mxr.mozilla.org/comm-central/source/mailnews/compose/src/nsSmtpProtocol.cpp#359
with something that simply creates a random string to be used by ehlo.

Comment 3

[Kent James (:rkent)]

My reaction to this was going to be that we should add some mechanism that an extension could use that would hide this field, but I see in looking at the code that we already have such a mechanism, the helloArgument. See bug 244030 for when that was implemented - including discussions of different email server configurations why this may matter.

I don't agree with this statement: "Since there is no need to send any specific information and according to RFC 2821 sending the hostname is not necessary, the optimal solution would be to send a random string." if in fact that requires going against a "SHOULD" in the RFC, as well as potentially breaking some client configurations that are expecting to use that result as part of their mechanism to decide whether to accept a particular client as valid. SMTP servers have a legitimate interest in knowing who is trying to use them.

So I'm going to WONTFIX this. What I would potentially support is some sort of high-security, high privacy addon (that could even be potentially shipped by default but disabled) that would enable a number of high-security features, including this preference value, but educating the user that there may be some usability cost to such an addon.

Comment 4

[sabine_28195]

"if in fact that requires going against a "SHOULD" in the RFC, as well as potentially breaking some client configurations that are expecting to use that result as part of their mechanism to decide whether to accept a particular client as valid. SMTP servers have a legitimate interest in knowing who is trying to use them."

Most Clients already send the hostname of the Client System with the ehlo command. So it can pretty much be expected, that there is not software out there, that expects anything specifig that would break if Thunderbird behaved the way I specified. If that were the case mot email clients out there would breakt such software.

On the other hand I really suspect that this issue is underestimated in regard to the implications.
Sending the client IP in plaintext over the net will break most of the anonymization software out there. To many people this bug could have serious consequences. And as I mentioned before there is no need for transmitting the ip, other clients have proven this as well.