MBOX-Line: From brong at fastmail.fm  Tue Mar 18 20:46:44 2014
To: imap-protocol@u.washington.edu
From: Bron Gondwana <brong@fastmail.fm>
Date: Fri Jun  8 12:34:52 2018
Subject: [Imap-protocol] STARTTLS after PREAUTH
In-Reply-To: <53290DE4.2020909@verizon.net>
References: <20140318141305.Horde.iyy0UP8Ostx9TojRZiFyjw1@bigworm.curecanti.org>
	<059bac1f-35eb-4f87-bd5e-e986dfb46b83@flaska.net>
	<20140318152549.Horde.0C2tXb4vwx_29xt0ZbwdEQ4@bigworm.curecanti.org>
	<1395187453.9897.96141249.7BE88CD8@webmail.messagingengine.com>
	<53290DE4.2020909@verizon.net>
Message-ID: <1395200804.27059.96196209.4345452F@webmail.messagingengine.com>

On Wed, Mar 19, 2014, at 02:24 PM, Joshua Cranmer wrote:
> On 3/18/2014 7:04 PM, Bron Gondwana wrote:
> > On Wed, Mar 19, 2014, at 08:25 AM, Michael M Slusarz wrote:
> >> Quoting Jan Kundr?t <jkt@flaska.net>:
> >>> Also, nothing prevents a server from going directly to PREAUTH if
> >>> the whole connection is using SSL/TLS ("port 993") with client
> >>> certificates.
> >> STARTTLS deprecated the use of port 993, which isn't an official IMAP
> >> port FWIW.  It hasn't really happened, but still is good to avoid and
> >> end users appreciate it when they don't have to have any knowledge of
> >> port number.
> >>
> >> I wish this did work with the STARTTLS command (i.e. PREAUTH response
> >> after STARTTLS in the above situation).  Unfortunately that isn't part
> >> of the spec either.
> > I can't understand how STARTTLS ever got floated as an idea.  It's totally insane.
> >
> > Your hypothetical MITM just strips the "LOGINDISABLED" capability response, and anything saying that the server supports TLS, and the client goes ahead and sends the credentials in cleartext.  At that point the MITM does the TLS negotiation with the server and it can read everything without the server knowing.
> 
> Except for clients that refuse to support LOGIN and non-STARTTLS. 
> Thunderbird (IIRC, I haven't poked at this code in years) refuses to 
> downgrade authentication from what is specified (so if the setting 
> requires CRAM-MD5, it will refuse to use AUTH PLAIN or LOGIN to specify 
> credentials), and also screams mightily if you said you're going to do 
> STARTTLS but don't. We also have a nasty warning if you refuse to do 
> both SSL and STARTTLS when configuring the account, although we will 
> allow it. This does open the possibility of being able to MITM the 
> connection startup, but I'll also point out that ssh has the same 
> intrinsic weakness to permanent MITM as it is used in practice and this 
> isn't generally seen as evidence that it's MITM-able.

I was almost impressed until I saw this:

GET /mail/config-v1.1.xml?emailaddress=brong%40fastmail.fm HTTP/1.1
Host: autoconfig.fastmail.fm
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 Lightning/2.6.4
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive

HTTP/1.1 200 OK
Server: nginx/1.4.4
Date: Wed, 19 Mar 2014 03:37:11 GMT
Content-Type: text/xml
Transfer-Encoding: chunked
Connection: keep-alive
X-UA-Compatible: IE=Edge
X-Frontend: frontend2

57b
<?xml version="1.0" encoding="UTF-8"?>

<clientConfig version="1.1">
  <emailProvider id="MessagingEngine">
    <domain>fastmail.fm</domain>
    <displayName>FastMail</displayName>
    <displayShortName>FastMail</displayShortName>
    <incomingServer type="imap">
      <hostname>mail.messagingengine.com</hostname>
      <port>993</port>
      <socketType>SSL</socketType>
      <authentication>password-cleartext</authentication>
      <username>%EMAILADDRESS%</username>
    </incomingServer>
    <incomingServer type="pop3">
      <hostname>mail.messagingengine.com</hostname>
      <port>995</port>
      <socketType>SSL</socketType>
      <authentication>password-cleartext</authentication>
      <username>%EMAILADDRESS%</username>
    </incomingServer>
    <outgoingServer type="smtp">
      <hostname>mail.messagingengine.com</hostname>
      <port>465</port>
      <socketType>SSL</socketType>
      <authentication>password-cleartext</authentication>
      <username>%EMAILADDRESS%</username>
    </outgoingServer>
    <instruction url="http://www.fastmail.fm/help/remote_email_access_server_names_and_ports.html">
      <descr lang="en">Server Names and Ports</descr>
    </instruction>
    <instruction url="http://www.fastmail.fm/docs/imap/thunderbird3.htm">
      <descr lang="en">Using FastMail with Mozilla Thunderbird 3.x</descr>
    </instruction>

  </emailProvider>
</clientConfig>

It made a secure connection to broker.thunderbird.net, but then fell back to an insecure connection to pick up the configuration.

As you can see, we're using a domain at FastMail which isn't 'fastmail.fm' for our IMAP endpoint (we host thousands of domains, we don't want to have thousands of IPs and SSL certs)

It would be trivial to respond to this query with the details of an SSL MITM host and then all bets are off.

GET /mail/config-v1.1.xml?emailaddress=brongondwana%40gmail.com HTTP/1.1
Host: autoconfig.gmail.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 Lightning/2.6.4
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive

HTTP/1.0 303 See Other
Location: http://guidetest.a.id.opendns.com/?url=autoconfig%2Egmail%2Ecom%2Fmail%2Fconfig%2Dv1%2E1%2Exml%3Femailaddress%3Dbrongondwana%2540gmail%2Ecom
Content-Length: 0
Date: Wed, 19 Mar 2014 03:44:04 GMT
Server: OpenDNS Guide

And then it fell back to the Mozilla ISP database, but there's no reason I couldn't have MITMed that and stolen the gmail creds too.  Thunderbird is pretty trivially fooled at setup time.

Bron.

-- 
  Bron Gondwana
  brong@fastmail.fm

