61 lines
2.5 KiB
Plaintext
61 lines
2.5 KiB
Plaintext
MBOX-Line: From slusarz at curecanti.org Tue Mar 18 14:25:49 2014
|
|
To: imap-protocol@u.washington.edu
|
|
From: Michael M Slusarz <slusarz@curecanti.org>
|
|
Date: Fri Jun 8 12:34:52 2018
|
|
Subject: [Imap-protocol] STARTTLS after PREAUTH
|
|
In-Reply-To: <059bac1f-35eb-4f87-bd5e-e986dfb46b83@flaska.net>
|
|
References: <20140318141305.Horde.iyy0UP8Ostx9TojRZiFyjw1@bigworm.curecanti.org>
|
|
<059bac1f-35eb-4f87-bd5e-e986dfb46b83@flaska.net>
|
|
Message-ID: <20140318152549.Horde.0C2tXb4vwx_29xt0ZbwdEQ4@bigworm.curecanti.org>
|
|
|
|
Quoting Jan Kundr?t <jkt@flaska.net>:
|
|
|
|
> On Tuesday, 18 March 2014 21:13:05 CEST, Michael M Slusarz wrote:
|
|
>> 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.
|
|
|
|
Except as defined in base spec, STARTTLS is defined as "you are
|
|
allowed to protect privacy ONLY if you protect authentication". In
|
|
the absence of a need to protect authentication, you can't protect
|
|
privacy.
|
|
|
|
>> 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.
|
|
|
|
Not a part of the base IMAP spec, which is what I was talking about.
|
|
|
|
> 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'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?
|
|
|
|
Simple real-world example would be a machine on an internal network
|
|
that is guaranteed to belong to a certain user.
|
|
|
|
I don't really care one way or another - mainly wanted to verify to
|
|
myself that I wasn't missing a valid use-case.
|
|
|
|
michael
|
|
|
|
|