41 lines
1.6 KiB
Plaintext
41 lines
1.6 KiB
Plaintext
MBOX-Line: From jkt at flaska.net Tue Mar 18 13:46:29 2014
|
|
To: imap-protocol@u.washington.edu
|
|
From: =?iso-8859-1?Q?Jan_Kundr=E1t?= <jkt@flaska.net>
|
|
Date: Fri Jun 8 12:34:52 2018
|
|
Subject: [Imap-protocol] STARTTLS after PREAUTH
|
|
In-Reply-To: <20140318141305.Horde.iyy0UP8Ostx9TojRZiFyjw1@bigworm.curecanti.org>
|
|
References: <20140318141305.Horde.iyy0UP8Ostx9TojRZiFyjw1@bigworm.curecanti.org>
|
|
Message-ID: <059bac1f-35eb-4f87-bd5e-e986dfb46b83@flaska.net>
|
|
|
|
On Tuesday, 18 March 2014 21:13:05 CEST, Michael M Slusarz wrote:
|
|
> Am I correct in my reading that this means that you lose any
|
|
> ability to protect message data via TLS if PREAUTH is used? In
|
|
> other words: was STARTTLS solely designed to protect
|
|
> authentication credentials (security) and not message data
|
|
> (privacy)?
|
|
|
|
Not at all. Once issued, STARTTLS protects everything, i.e. both your
|
|
credentials and transfers of all messages.
|
|
|
|
> I guess the workaround for a situation where you *could*
|
|
> preauthenticate based on connection factors/details, but still
|
|
> need message privacy, is to require some sort of dummy
|
|
> authentication (after initializing TLS layer). Feels pretty
|
|
> hackish though.
|
|
|
|
That's what you could get with AUTH EXTERNAL. Also, nothing prevents a
|
|
server from going directly to PREAUTH if the whole connection is using
|
|
SSL/TLS ("port 993") with client certificates.
|
|
|
|
I'm a bit confused by your message. How do you want to authenticate your
|
|
user? Specifically, what's the use case where you can safely verify the
|
|
user's identity, but cannot guarantee confidentiality of the connection
|
|
stream?
|
|
|
|
Cheers,
|
|
Jan
|
|
|
|
--
|
|
Trojit?, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
|
|
|