Re: TLS and STARTTLS

Simon Horman <[email protected]> Wed, 30 Mar 2011 12:13:31 +0900
Newsgroups gmane.mail.perdition.user
Message-ID <[email protected]>
On Tue, Mar 29, 2011 at 09:47:00PM -0400, Micah Anderson wrote:
> 
> Hi,
> 
> Perdition has the option "ssl_mode" which can be used to set both
> listening and outgoing connections. Its made up of options that are
> prefixed either by 'ssl' or 'tls'.
> 
> From my experimentation, it seems as if the 'tls' options aren't
> actually TLS, but rather the STARTTLS extension for IMAP and POP.
> 
> So what is the difference? The difference is that an actual TLS
> connection would be one whereby the client and server negotiate a
> stateful connection by using a handshaking procedure where they agree on
> various parameters that will be used to establish the connection's
> security. This is all done during the bring up of the connection, and
> the client wont send a login/password until the connection has been
> properly setup.
> 
> STARTTLS, by contrast, proceeds by the client making a clear-text
> connection to the server, noting that the server has the STARTTLS
> capability (to use the IMAP terminology), requests that a STARTTLS
> negotiation process begins and then you promote up to an actual TLS
> connection. After you've promoted, then your connection is encrypted.
> 
> Why is the distinction important? With STARTTLS the potential for
> credential leak exists during the clear-text window. Perdition offers
> the tls_listen_force/tls_outgoing_force/tls_all_force settings to
> 'ssl_mode', but all this does in IMAP4/IMAP4S is have the LOGINDISABLED
> set, which doesn't stop a client from attempting to login, it just
> refuses their login after they've sent it over the clear-text
> connection. As the RFC (2595) referenced in the man page states:
> 
>     Servers advertising this capability will fail to interoperate with
>     many existing compliant IMAP clients and will be unable to prevent
>     those clients from disclosing the user's password.
> 
> I think that the option 'ssl_mode' is a confusing name. TLS and SSL are
> different things (although many people still call TLS connections
> SSL). Additionally the use of the name 'tls' in the potential options is
> confusing, when the actual behavior is STARTTLS.
> 
> It seems to me that the existing 'tls' options should be renamed
> 'starttls_*' and an actual TLS option be added.
> 
> I also notice that the man page says, "TLS is defined in RFC 2595". This
> isn't really correct, again its STARTTLS that is defined in RFC
> 2595. This RFC, although titled this way in 1999, is known as the
> canonical reference defining STARTTLS for IMAP and POP3 (there are
> others for things like SMTP). TLS, on the other hand, is actually
> detailed in RFC 5246.


Hi Micah,

the confusing naming reflects a misunderstanding on my part
at the time that I implemented the options - quite some time ago now.
I apologise for that.

I am happy to try and make things less confusing, the documentation
is an easy target for that, but I am a little reluctant
to make changes to the code that are not backwards compatible.

So a new set of configuration options is fine by me so long
as they don't conflict with the old ones which I would prefer
to leave as-is. Would that work for you?

______________________________________________
Perdition-users mailing list
[email protected]
http://lists.vergenet.net/listinfo/perdition-users