58 lines
3.3 KiB
Plaintext
58 lines
3.3 KiB
Plaintext
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
|
|
|
|
|