[jira] [Created] (EMAIL-105) Clarify names for SSL and TLS

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[jira] [Created] (EMAIL-105) Clarify names for SSL and TLS

Gilles (Jira)
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


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
Reply | Threaded
Open this post in threaded view
|

[jira] [Updated] (EMAIL-105) Clarify names for SSL and TLS

Gilles (Jira)

     [ 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

       
Reply | Threaded
Open this post in threaded view
|

[jira] [Commented] (EMAIL-105) Clarify names for SSL and TLS

Gilles (Jira)
In reply to this post by Gilles (Jira)

    [ https://issues.apache.org/jira/browse/EMAIL-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092540#comment-13092540 ]

Siegfried Goeschl commented on EMAIL-105:
-----------------------------------------

Hi Bruno - thanks for the detailed explanation since I was not aware of the details

> 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
>            Assignee: Siegfried Goeschl
>         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

       
Reply | Threaded
Open this post in threaded view
|

[jira] [Resolved] (EMAIL-105) Clarify names for SSL and TLS

Gilles (Jira)
In reply to this post by Gilles (Jira)

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

Siegfried Goeschl resolved EMAIL-105.
-------------------------------------

       Resolution: Fixed
    Fix Version/s: 1.3

Thanks to Albrecht Görge and the first Vienna Hackergarden

> 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
>            Assignee: Siegfried Goeschl
>             Fix For: 1.3
>
>         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