Your message dated Wed, 10 Feb 2016 18:46:07 +0100
with message-id <[email protected]>
and subject line Re: Bug#814017: icedove: Information leakage problem when
using smtp + starttls
has caused the Debian Bug report #814017,
regarding icedove: Information leakage problem when using smtp + starttls
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
814017: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814017
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: icedove
Version: 38.5.0-1~deb8u1
Severity: important
Dear Maintainer,
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.
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.
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
-- System Information:
Debian Release: 8.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages icedove depends on:
ii debianutils 4.4+b1
ii fontconfig 2.11.0-6.3
ii libasound2 1.0.28-1
ii libatk1.0-0 2.14.0-1
ii libc6 2.19-18+deb8u2
ii libcairo2 1.14.0-2.1
ii libdbus-1-3 1.8.20-0+deb8u1
ii libdbus-glib-1-2 0.102-1
ii libevent-2.0-5 2.0.21-stable-2
ii libffi6 3.1-2+b2
ii libfontconfig1 2.11.0-6.3
ii libfreetype6 2.5.2-3+deb8u1
ii libgcc1 1:4.9.2-10
ii libgdk-pixbuf2.0-0 2.31.1-2+deb8u4
ii libglib2.0-0 2.42.1-1
ii libgtk2.0-0 2.24.25-3
ii libhunspell-1.3-0 1.3.3-3
ii libpango-1.0-0 1.36.8-3
ii libpangocairo-1.0-0 1.36.8-3
ii libpangoft2-1.0-0 1.36.8-3
ii libpixman-1-0 0.32.6-3
ii libsqlite3-0 3.8.7.1-1+deb8u1
ii libstartup-notification0 0.12-4
ii libstdc++6 4.9.2-10
ii libx11-6 2:1.6.2-3
ii libxcomposite1 1:0.4.4-1
ii libxdamage1 1:1.1.4-2+b1
ii libxext6 2:1.3.3-1
ii libxfixes3 1:5.0.1-2+b2
ii libxrender1 1:0.9.8-1+b1
ii libxt6 1:1.1.4-1+b1
ii psmisc 22.21-2
ii zlib1g 1:1.2.8.dfsg-2+b1
Versions of packages icedove recommends:
ii hunspell-en-us [hunspell-dictionary] 20070829-6
ii iceowl-extension 38.5.0-1~deb8u1
Versions of packages icedove suggests:
pn fonts-lyx <none>
ii libgssapi-krb5-2 1.12.1+dfsg-19+deb8u2
-- no debconf information
--- End Message ---
--- Begin Message ---
Hello Timo,
as discussed in private I don't see anything Debian should do on that
topic.
STARTLS should be used in a sensible environment, TLSv1.1 or greater has
to be used to get a secured connection before any interaction between
the client and server is starting.
So Iw ill close this report now.
Regards
Carsten
On Sun, Feb 07, 2016 at 06:09:40PM +0100, Carsten Schoenert wrote:
> 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
--- End Message ---
