TLS version of Email Library

I checked my domain with https://www.ssllabs.com/ssltest/

it says my domain is compatible with TLS1.2, so I suppose I am okay.  

Guess this wasn't a CI question - Thanks everyone for your help!

That's for HTTP though, which is handled by your web server (Apache, nginx, etc.) and not PHP.

The server that you're running certainly supports TLS 1.2 - I wouldn't question that unless you're running a decade old OS that was never updated. The question is whether PHP's exposed userland functions actually use it. And the answer is ... complicated.

For SMTP, the library opens a connection via fsockopen(). And if you configure smtp_crypto to be 'tls', the connection will be altered via stream_socket_enable_crypt() and STREAM_CRYPTO_METHOD_TLS_CLIENT: https://github.com/bcit-ci/CodeIgniter/b....php#L2048

And the problem is that this STREAM_CRYPTO_METHOD_TLS_CLIENT has changed its values between PHP versions ... a lot, and even in patch versions.

Here's what 3v4l.org shows:

Output for 5.6.0 - 5.6.6, hhvm-3.10.1 - 3.22.0, 7.2.0 - 7.2.1
   int(57)
Output for 5.6.7 - 5.6.30, 7.0.0 - 7.1.13
   int(9)
Output for 5.1.0 - 5.5.38
   int(3)

57 means that any of TLS 1.0, 1.1 and 1.2 could be used, depending on negotiation with the server.
9 means TLS 1.0 only.
3 means SSL 2.0 only - that's entirely broken and there aren't even other constants as options before PHP 5.6.

What has happened with PHP here is an example of bad programming in the past causing huge problems in the future ...

1. Someone did mistake TLS to be SSL, and even worse than that - hard-coded TLS to alias SSL 2.0, while TLS is based on SSL 3.0, so that's 2 problems here.
2. Years later, both mistakes were corrected in one go with the release of PHP 5.6.0.
3. Users complained that their software broke - the fix was reverted, or at least altered to a compromise. That is ... it wasn't reverted to SSL 2.0, but I guess restricting it to TLS 1.0 somehow fixed all the broken apps - I'm not intimately familiar with the protocol's inner workings, so I can't explain how/why that has worked.
4. PHP 7.2 (released a month ago) finally fixed the problem for good, even aliasing 'ssl://' to 'tls://' now, because nobody should be using SSL today.

---

So, there you have it ...

To be fair, you shouldn't have to know or deal with all of this, but unfortunately it's not an easy situation for CI to deal with either. We'll probably patch it, the question is with what exactly.