[Imap-protocol] Pipelined commands before completion of STARTTLS
guenther+imap at sendmail.com
Tue Mar 8 13:58:18 PST 2011
On Tue, 8 Mar 2011, Ken Murchison wrote:
> Pursuant to http://www.kb.cert.org/vuls/id/555316
> I was wondering what the proper server behavior should be if a client
> sends commands between STARTTLS and the server response. RFC 3501
> states that this is a client MUST NOT but doesn't discuss how the server
> should handle it.
> I can see two possibilities (maybe there are others):
> 1. Send a BAD response if a command is pipelined after STARTTLS.
> Should BAD be sent in response to STARTTLS or the following command?
> 2. Ignore the pipelined cleartext commands.
3. immediately close the connection
4. Treat data after the CRLF as data for the TLS handshake (i.e., to shave
an RTT off in the success case). I seem to recall a proposal for an
SMTP extension to indicate that the server would guarantee that
STARTTLS would succeed and that it could handle having the client's
handshake message pipelined with the STARTTLS request. (QTLS was it?)
The standard places no requirements on the server's behavior if the client
violates that MUST NOT. Common sense says "don't be insecure", but since
it's a non-obvious problem it probably should be called out if/when the
standard is revised.
However, I don't think the standard should _require_ behavior (1), (2), or
(3), as behavior (4) should be permitted going forward.
> - Should this be done regardless of whether TLS is negotiated successfully?
> - Can/Should the connection be immediately terminated?
> - Should the behavior be any different for POP3, NNTP, SMTP/LMTP?
I would say:
- don't care, as long as it doesn't use insecure data
- behavior (3) seems legal to me (client violated a MUST NOT, so even
nasal daemons may be summoned), so "can", but I don't think that's
the best way to handle it
- I see no particular reason for the protocols to differ, but neither
do I think a common behavior is required
guenther at sendmail.com
More information about the Imap-protocol