On Wed, 23 Jan 2002, Patrice Fournier wrote:
> > SMTP<< 250 <3C4DDC960002DD28> Mail accepted
> > tls_close(): shutting down SSL
>
> Mail is sent and accepted and Exim is shutting down SSL!?... I suppose
> this shutdown is only on the client side (I can't look at the code right
> now)
My understanding is that this shuts down encryption on the session,
leaving the connection in an unencrypted state. When Exim is running as
a server, it reverts back to a clear-text session. This is the comment
in the code:
/* SSL_ERROR_ZERO_RETURN appears to mean that the SSL session has been
closed down, not that the socket itself has been closed down. Revert to
non-SSL handling. */
> > Exim version 3.31-VA-mm2 debug level 1 uid=8 gid=8
> > Berkeley DB: Sleepycat Software: Berkeley DB 2.7.7: (08/20/99)
> > delivering message 16TUla-00065p-00
> > SMTP>> STARTTLS
>
> resend a STARTTLS command... oops, this is against the RFC!
Hmm. See below...
> > SMTP<<
> > LOG: 0 MAIN
> > Malformed SMTP response from mail.epost.de [64.39.38.43] after
> > STARTTLS: \025\003\001
>
> Of course, the server is already in encrypted mode and doesn't understand
> a thing about what it just got, neither does Exim understands the server's
> encrypted response...
The server should have noticed the SSL_ERROR_ZERO_RETURN as a result of
the tls_close() and done something sensible with it... Why has it
ignored the client's attempt to shut down encryption?
> Here is the relevent part of the RFC:
>
> Both the client and the server MUST know if there is a TLS session
> active. A client MUST NOT attempt to start a TLS session if a TLS
> session is already active. A server MUST NOT return the TLS extension
> in response to an EHLO command received after a TLS handshake has
> completed.
You could argue that the server should have known that the TLS session
was no longer active, because the client had closed it. Oh, isn't it fun
trying to interpret the exact meaning of RFCs... :-)
As far as I can see, the RFC says nothing about ending TLS sessions.
The underlying problem here is the way Exim is designed. The sending of
several messages over one connection is seen as "exceptional" rather
than "commonplace", so it is implemented in a crude way. A whole new
delivery process is started for the next message. It is impossible to
pass over all the state that is associated with a TLS session, which is
why Exim closes it down before passing the socket to a new delivery
process.
If this isn't going to work, Exim cannot implement "several queued
messages over one connection" when TLS is involved.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
