Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Sun, 17 Jul 2011 19:26:59 +0000 (UTC)
From: "Bruno Harbulot (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: 
 <1257361397.21443.1310930819887.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1846560673.15701.1305566387369.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (EMAIL-105) Clarify names for SSL and TLS
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/EMAIL-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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: https://issues.apache.org/jira/browse/EMAIL-105
>             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)|http://tools.ietf.org/html/rfc3207 ], 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: http://www.atlassian.com/software/jira