commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bruno Harbulot (JIRA)" <>
Subject [jira] [Updated] (EMAIL-105) Clarify names for SSL and TLS
Date Sun, 17 Jul 2011 19:26:59 GMT


Bruno Harbulot updated EMAIL-105:

    Attachment: ssl-starttls.patch

Here is a patch that attempts to fix a few points regarding SSL, TLS and STARTTLS.

- STARTTLS should be usable, even without an authenticator (EMAIL-106)
- The wording of the documentation of {{setTLS}} was talking about "when TLS is needed". This
can be confusing, especially with the additions to JavaMail 1.4.2 ("required"). It's the client
that tries to use STARTTLS (the server can be configured to refuse authentication when it's
not used).
- JavaMail 1.4.2 provides a few new parameters, in particular:
  -- {{mail.smtp.starttls.required}} in addition to {{mail.smtp.starttls.enable}}, to make
the client disconnect if the server doesn't support STARTTLS.
  -- some new parameters to configure the SSL socket factory (which can be used both for SSL/TLS
on connection or via STARTTLS)
  -- {{mail.smtp.ssl.checkserveridentity}} is false by default in JavaMail, but checking the
server identity is necessary to ensure the security of the SSL/TLS connection (whether on
connection or via STARTTLS).

> Clarify names for SSL and TLS
> -----------------------------
>                 Key: EMAIL-105
>                 URL:
>             Project: Commons Email
>          Issue Type: Improvement
>            Reporter: Bruno Harbulot
>         Attachments: ssl-starttls.patch
> The API offers two categories of settings for the configuration of SSL/TLS: {{setSSL}}
and {{setTLS}} (and respective associated methods).
> The names are quite misleading, as this doesn't really oppose SSL and TLS. A number of
e-mail applications make this mistake, but "TLS" is used here to mean "using STARTTLS" and
"SSL" is used here to mean "SSL or TLS, upon connection".
> The difference is that:
> - With "SSL" (as incorrectly named here), the SMTP client connects to the SMTP server
on a dedicated port and starts the SSL/TLS handshake upon connection. This is then followed
by "normal" SMTP traffic on this SSL/TLS layer.
> - With "TLS" (as incorrectly named here), the SMTP client connects to the SMTP server
on the same port as it would do for plain-text SMTP, exchanges a few SMTP commands, including
[STARTTLS (RFC 3207)| ], and then starts an SSL/TLS handshake
to upgrade to a secure channel.
> This is not so much a difference between SSL and TLS, but rather a difference regarding
when the connection is turned into a secure one.
> The difference between SSLv3 and TLS 1.0 is mostly a version difference, where SSLv3
is the predecessor of TLS 1.0.
> You can have an TLS 1.0+ upon connection, using the "SSL" setting, without using {{STARTTLS}}
(it's a version configuration up to the {{SSLEngine}} or {{SSLSocketFactory}}).
> Similarly, although it's not written in the specification, some servers seem to accept
an SSLv3 handshake (instead of its successor version: TLS 1.0) after {{STARTTLS}}.
> I'd suggest deprecating {{setSSL}} and {{setTLS}} and replacing them with {{setOnConnectSSL}}
and {{setStartTLS}} (or similar), respectively.

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message