MBOX-Line: From Pidgeot18 at verizon.net  Tue Mar 18 20:24:20 2014
To: imap-protocol@u.washington.edu
From: Joshua Cranmer <Pidgeot18@verizon.net>
Date: Fri Jun  8 12:34:52 2018
Subject: [Imap-protocol] STARTTLS after PREAUTH
In-Reply-To: <1395187453.9897.96141249.7BE88CD8@webmail.messagingengine.com>
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>
Message-ID: <53290DE4.2020909@verizon.net>

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.

Some authentication protocols also can't be MITM'd: client certificate, 
NTLM, and Kerberos (via GSSAPI) don't involve the username and password 
so the MITM server can't tell the server to move to the authenticated 
state and the client won't move. Granted, these authentication 
mechanisms are probably much less widspread than CRAM-MD5 or PLAIN or 
the ilk.
> The only way that STARTTLS has any value is if every client refuses to send credentials until TLS or equivalent protection is established - in which case STARTTLS is pointless, you might as well just go straight to encryption and avoid the round trip.
It's not entirely pointless. It means you don't have to specify if the 
connection is encrypted or unencrypted via magic out-of-band information 
(i.e., port number).

-- 
Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth


