1

SMTP allows unecrypted communication over port 25. For some servers (like Google's MX servers) I'm able to switch to a TLS connection using STARTTLS after making the initial unencrypted connection.

S:220 mx.google.com ESMTP l1si352658een.133
C:EHLO mail.example.com
S:250-mx.google.com at your service
S:250-SIZE 35882577
S:250-8BITMIME
S:250-STARTTLS
S:250-ENHANCEDSTATUSCODES
S:250 PIPELINING
C:STARTTLS
S:220 2.0.0 Ready to start TLS
[socket switches to TLS here]
C:EHLO mail.example.com
...

However, I would also like to support straight SSL connections and I'm wondering whether most mail servers prefer starting with SSL or starting with TCP and then moving to TLS after a connection is made.

Xeoncross
  • 55,620
  • 80
  • 262
  • 364

2 Answers2

4

Unless you have prior arrangements with the administrator of a sever, don't try to connect using SSL. Port (465) was used for SSMTP or SMTPS (SMTP over SSL). Connections to this port were expected to start the connecton with SSL. Use of this port and protocol has been abandoned now that StartTLS is available.

There are two ports which may support SMTP with StartTLS. Neither are expected to support SSL without StartTLS, and will likely drop the connection if you try. Both the SMTP (25) and Submission (587) may support StartTLS. If it is supported, it wlll be listed in the response to an EHLO message. You can then initiate the StartTLS process. See RFC 3207 for more details.

It appears from your comments, that your real concern is how to verify the certificate. That is a different but related question. It also assumes that mail servers are not using self-signed certificates. In my case, I use a self-signed certificate. This works well for me as StartTLS is rarely, if ever, used for SMTP (port 25) connections. I have reasonable control over the clients connecting for message Submission (port 587 or port 25) that must authenticate before sending messages. In my experience, StartTLS is mainly used to secure the connection for clients that must authenticate before sending email.

BillThor
  • 7,306
  • 1
  • 26
  • 19
1

The support for SSL/TLS on connect (SMTPS) or SSL/TLS after STARTTLS really varies from one server to another, depending on the software and how they've been configured.

The main advantage of SSL/TLS on connect is that it doesn't require any changes in the application protocol. In fact, you could wrap the connection using something like stunnel on each side.

The main advantage of SSL/TLS after STARTTLS is that it can be done on the same port. Another advantage could be to be able to host multiple host names (replacing the need for Server Name Indication at the TLS level), but I'm not sure this has ever been used for SMTP servers.

STMPS (SSL/TLS on connect) doesn't have an official specification and uses a port number for which it is not registered (465). It's also deprecated, in theory. Yet, a number of servers can support it (e.g. Exim) and will be able to support both if they are able to do so: it will be up to the hosting service to choose what to configure.

If you're writing a client and already have support for STARTTLS, it should be fairly cheap to support SSL/TLS upon connect too. It's certainly a good idea to support both, since it will be usable by a wider number of users (if I remember correctly, Gmail used to support only SMTPS at some point, and it can also be useful in case of a firewall that would block one of the ports only).

Both can offer similar levels of security, as long as SSL/TLS is used, one way or another (and that proper certificate verification, including host name, is performed).

There is generally some confusion regarding the difference between SSL and TLS. For some reason, it seems that a number of e-mail software implementations failed to realise that the most important word in "STARTTLS" is "START", not TLS (in terms of connection mode and protocol choice). This confusion has unfortunately propagated to some software configuration options (even in popular mail clients) and thus in ISP documentations. Expect your users to be confused.

Whichever mode you want to support, make sure it doesn't have a "Use TLS, if available" option, which would fall back to a plain exchange if SSL/TLS wasn't available: this opens the connections to MITM attacks.

Community
  • 1
  • 1
Bruno
  • 119,590
  • 31
  • 270
  • 376
  • Nice summary, I'm currently trying to use PHP to [verify a certificate](http://stackoverflow.com/questions/13402866/how-do-i-verify-a-tls-smtp-certificate-is-valid-in-php), but unlike SSL, I'm not sure how to verify the cert *after switching* to TLS in STARTTLS. I can't seem to get SSL to work with Google's or Hotmail's MX servers (port 25, 465, or 587), but Google supports STARTTLS so I guess they have changed from SMTPS. – Xeoncross Nov 16 '12 at 16:32
  • "*[...] but unlike SSL [...]*": here, you're making the same incorrect distinction between SSL and TLS. The certificate verification process will be the same for SSL or TLS, but it may indeed differ whether you use STARTTLS or use SSL/TLS on connect. Regarding PHP, its default certificate verification behaviour is generally quite poor (remember to verify cert AND host name, btw). Perhaps the curl bindings might support SMTP(S). – Bruno Nov 16 '12 at 16:40
  • *"The certificate verification process will be the same for SSL or TLS, but it may indeed differ whether you use STARTTLS or use SSL/TLS on connect."* That's what I said. Verifying a certificate on connection of SSL is fairly easy in PHP, "*but unlike SSL, I'm not sure how to verify the cert after switching [from tcp] to TLS in STARTTLS.*" – Xeoncross Nov 16 '12 at 17:05
  • My point is about what you're calling "SSL" and "TLS". You're opposing SSL to TLS ("*unlike SSL*") implying that "SSL" is only for SMTPS whereas "TLS" is only for SMTP+STARTTLS. Nowadays, you're actually likely to be able to use TLS for both. – Bruno Nov 16 '12 at 17:15
  • Well, It's not that I'm opposing, just having trouble with terminology trying to relate *straight* SSL/TLS connections to unencrypted connections that are *switched* to TLS halfway through. I'm not sure how to verify a certificate when making that switch. – Xeoncross Nov 16 '12 at 17:37