Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.3
    • Labels:
      None

      Description

      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.

      1. ssl-starttls.patch
        8 kB
        Bruno Harbulot

        Activity

        Bruno Harbulot created issue -
        Hide
        Bruno Harbulot added a comment -

        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).
        Show
        Bruno Harbulot added a comment - 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).
        Bruno Harbulot made changes -
        Field Original Value New Value
        Attachment ssl-starttls.patch [ 12486775 ]
        Siegfried Goeschl made changes -
        Assignee Siegfried Goeschl [ sgoeschl ]
        Hide
        Siegfried Goeschl added a comment -

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

        Show
        Siegfried Goeschl added a comment - Hi Bruno - thanks for the detailed explanation since I was not aware of the details
        Siegfried Goeschl made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        Siegfried Goeschl made changes -
        Status In Progress [ 3 ] Open [ 1 ]
        Hide
        Siegfried Goeschl added a comment -

        Thanks to Albrecht Görge and the first Vienna Hackergarden

        Show
        Siegfried Goeschl added a comment - Thanks to Albrecht Görge and the first Vienna Hackergarden
        Siegfried Goeschl made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 1.3 [ 12315052 ]
        Resolution Fixed [ 1 ]
        Thomas Neidhart made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            Siegfried Goeschl
            Reporter:
            Bruno Harbulot
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development