Hello Timo,
On Sun, Feb 07, 2016 at 04:34:22PM +0100, Timo wrote:
> icedove reveals the private client ip when using the ehlo comamnt with
> starttls
>
> 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.
this isn't completely correct. A literal address is also possible.
----%<--- From RFC2821 [1]
3.6 Domains
Only resolvable, fully-qualified, domain names (FQDNs) are permitted
when domain names are used in SMTP. In other words, names that can
be resolved to MX RRs or A RRs (as discussed in section 5) are
permitted, as are CNAME RRs whose targets can be resolved, in turn,
to MX or A RRs. Local nicknames or unqualified names MUST NOT be
used. There are two exceptions to the rule requiring FQDNs:
- The domain name given in the EHLO command MUST BE either a primary
host name (a domain name that resolves to an A RR) or, if the host
has no name, an address literal as described in section 4.1.1.1.
- The reserved mailbox name "postmaster" may be used in a RCPT
command without domain qualification (see section 4.1.1.3) and
MUST be accepted if so used.
--->%---
> 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.
That's what hostnames (and FQDNs) are for. The EHLO command is for
identifying the client on the server, so any identification string is
needed, but the RFC is say what is valid.
> 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.
I don't see the point, even if you use a private IP range and there is a
working rDNS on the network I will get this information. And if I'm
outside your private net I will probably get the DNS entry of your
router that is doing NATing.
And as you use a VPN nobody outside will ever see your traffic or can
participate on the VPN network. All other people also can't connect
because private IP's are on non routable address ranges.
If you have leaked such infomations on one of the VPN entry points than
you probably have a othe securiry problem. The email traffic is crypted
hopefully by TLS.
> The ehlo command does not need a specific string to be accepted by the
> server.
Please read the RFC, it must. And if the FQDN can't be resolved the IP
is the appropriate information.
> "ehlo random_string" is accepted just als well.
>From the technical point you can send what ever you want, the server
will mostly accept this.
> 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 privac
There is nothing to do here for Icedove/Thunderbird. The EHLO behaviour
is excately what the RFC is describing. There is a long bug report [2]
on Bugzilla that is describing the circumstances well.
[1] http://www.ietf.org/rfc/rfc2821.txt
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=279525
Regards
Carsten
