2

Opportunistic TLS refers to extensions in plain text communication protocols, which offer a way to upgrade a plain text connection to an encrypted (TLS or SSL) connection instead of using a separate port for encrypted communication... Source: Wikipedia

Opportunistic TLS can for example be used by IMAP and POP3 with the "STARTTLS" command1 or by FTP with the "AUTH TLS" command2.

Such commands raise the following questions:

  1. Is the use of opportunistic TLS just for backwards compatibility (with a known/used port)?
  2. Is an opportunistic TLS implementation anyhow different from the use of native/normally implemented TLS/SSL?
  3. Can the same "level of security" as properly configured TLS be achieved through the use of opportunistic TLS?

Shortly: What is the purpose of opportunistic TLS?

1 RFC2595

2 RFC4217

Community
  • 1
Bob Ortiz
  • 6,234
  • 8
  • 43
  • 90
  • Hmm, I'd argue that STARTTLS doesn't _necessarily_ mean opportunistic TLS. It's possible for a server (or client) to require the use of STARTTLS, and refuse actual service if that condition is not met. That is in fact how my IMAP server is configured; you may connect over port 143 starting with plain IMAP, but you're only allowed to authenticate after upgrading to TLS. – marcelm Feb 19 '20 at 10:21

3 Answers3

4

In order:

  1. Is the use of opportunistic TLS just for backwards compatibility (with a known/used port)?

Yes. When you have an existing service it is helpful to allow it to use TLS if the other end knows how, without requiring it to use TLS, to ensure you continue to be able to communicate with endpoints that do not know how.

  1. Is an opportunistic TLS implementation anyhow different from the use of native/normally implemented TLS/SSL?

From the perspective of the actual code, it certainly does not need to be. For instance, many mail servers use OpenSSL for their opportunistic TLS implementations, just as an application might use OpenSSL for HTTPS traffic.

  1. Can the same "level of security" as properly configured TLS be achieved through the use of opportunistic TLS?

No. Because it is designed for backwards compatibility, and uses the same ports as unencrypted traffic, a request to use opportunistic TLS can be stripped by an active man-in-the-middle, resulting in an unencrypted connection and transmission. While HTTPS has some superficially similar issues such as SSL Strip, when using a protocol such as HTTPS it can be configured so that connections that aren't correctly protected by TLS simply fail. You cannot do the same with opportunistic TLS which must always assume that the other end of the connection may in fact legitimately not want to use, or understand how to use TLS, and must downgrade to plain-text transmission gracefully.

Xander
  • 35,525
  • 27
  • 113
  • 141
  • On pt.3 a remark is in order: if the server is not properly configured for STARTTLS - you're totally right. But if it is properly configured - the very same security level is achievable as the TLS from the very beginning case – Alexey Vesnin Mar 02 '17 at 01:58
  • @AlexeyVesnin It is theoretically possible, but in the most common cases like SMTP, I'd argue that it's not practically possible, at least in the vast majority of cases. Perhaps I can add more nuance to the answer. – Xander Mar 02 '17 at 02:11
  • In most of the cases, sadly, you're right. Especially for SMTP - as far as I know, only qmail can enforce STARTTLS or close connection otherwise. This STARTTLS-or-close is often unimplemented – Alexey Vesnin Mar 02 '17 at 14:41
  • @AlexeyVesnin Postfix can be configured to require TLS, currently primarily via its [smtp_tls_security_level](http://www.postfix.org/postconf.5.html#smtp_tls_security_level) (for outgoing SMTP connections) and [smtpd_tls_security_level](http://www.postfix.org/postconf.5.html#smtpd_tls_security_level) (for incoming SMTP connections) configuration parameters. Doing so for publicly-facing mail hosts is specifically recommended against in the documentation, because it breaks delivery for any remote MTA that for whatever reason is not able to do STARTTLS. – user Sep 23 '19 at 07:11
1

Well, the main idea is to "not reinvent the wheel": the standard protocol already have it's port number specifically standardized. Do you need a higher security level? - you're welcome! Enable STARTTLS and be as secure as you wish, because it is not restricted in security enhancement it brings. Do not feel so comfortable staying fully backwards compatible? - you can enforce the STARTTLS as the very beginning of the dialog or drop the connection otherwise in a well-known AND backwards compatible manner. It is usually done in SMTP on port 25.

Of course it is definitely NOT undermining the out-of-the-box secured protocol implementation for any known one, like SMTPS for SMTP. but it keeps network more interoperable even for an obsolete clients

Alexey Vesnin
  • 1,565
  • 1
  • 8
  • 11
1

Can the same "level of security" as properly configured TLS be achieved through the use of opportunistic TLS?

It can be, if used correctly. When using FTP, for example, your client can inform you whether TLS is used and with which certificate. This places a burden on the client to check the security of the connection, similar when browsing HTTPS sites.

In e-mail protocols like SMTP, this doesn't really work. There is often not a user present and it is unclear which certificate should be used, because e-mail is such a distributed system. Most SMTP clients don't verify certificates, making a man-in-the-middle attack possible.

Sjoerd
  • 28,707
  • 12
  • 74
  • 102