wasm-demo/demo/ermis-f/imap-protocol/cur/1600095023.22641.mbox:2,S

40 lines
1.9 KiB
Plaintext

MBOX-Line: From brong at fastmail.fm Tue Mar 18 17:04:13 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: <20140318152549.Horde.0C2tXb4vwx_29xt0ZbwdEQ4@bigworm.curecanti.org>
References: <20140318141305.Horde.iyy0UP8Ostx9TojRZiFyjw1@bigworm.curecanti.org>
<059bac1f-35eb-4f87-bd5e-e986dfb46b83@flaska.net>
<20140318152549.Horde.0C2tXb4vwx_29xt0ZbwdEQ4@bigworm.curecanti.org>
Message-ID: <1395187453.9897.96141249.7BE88CD8@webmail.messagingengine.com>
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.
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.
Bron.
--
Bron Gondwana
brong@fastmail.fm