TLS

JSON Reference

TLS-Server

The server role of a TLS encrypted connection. This is typically used on the remote host side of a tunnel configuration. This duct-type is one of the rare few where the duct-point-configuration is captured in JSON as an object rather than a simple string.

There is an object parameter with two properties:

  • CertificatePath - a string value that represents a relative file path to a PFX certificate file that includes the private key. The PFX file should be stored in the same directory as the application, and must be encrypted with a password

  • CertificatePassword - the password to decrypt the certificate file's private asymmetric key.

Example

"TLS-Server": {
"CertificatePath": "myCertificate.pfx",
"CertificatePassword": "myPassword1234"
},

Properties

  • Activation Phase = Top Down

  • Type = Encapsulation

  • Stream Interaction = Ongoing

  • JSON Value Type = object

  • Initiator = No

TLS-Client

The client role of the TLS encrypted connection. The server's certificate is validated according to configuration in the "Trusted-Certificates" section of the JSON configuration file.

No value is required, so use an empty string

Example

"TLS-Client": "",

Properties

  • Activation Phase = Bottom Up

  • Type = Encapsulating

  • Stream Interaction = Ongoing

  • JSON Value Type = inline string (empty)

  • Initiator = No

You can pair a Dull TLS-Client duct-point with a HTTPS web server. That is, the TLS server side need not be operating from Dull on another host. Usually, you might think of both duct-points to be implemented with Dull, but that's not mandatory.

TLS-ReverseClient

The same as Client, but with reversed activation. This might be used when a remote host connects with meet point but with added TLS protection, so the topic name cannot be seen plain text.

Example

"TLS-ReverseClient": "",

Properties

  • Activation Phase = Top Down

  • Type = Encapsulating

  • Stream Interaction = Ongoing

  • JSON Value Type = empty-string

  • Initiator = No

The importance of TLS

Although you can use AES encryption with a shared password, that duct type is not considered secure enough for production use on its own. TLS offers a range of important protocol protections that are needed for overall security.

Compared to a basic AES encryption stream, TLS includes:

  • A standard protocol - that interoperates with other systems

  • Message Integrity - refers to message integrity check using a message authentication code to prevent undetected loss or alteration of the data during transmission

  • Maturity - an open standard that stands the test of time

  • Streaming Ciphers - can be used, which don't need padding, and have better performance than block ciphers. As of TLS 1.2 - ChaCha20 is a modern and popularly used streaming cipher. Support was added for GSM and CCM modes of AES.

  • Protection against CBC attacks (TLS 1.1)

see https://en.wikipedia.org/wiki/Transport_Layer_Security for more information.

You should always use TLS as the first layer of encryption; AES encryption can also be layered on top. AES encryption should not be used as the first layer of encryption.

The weaknesses of TLS

While it's considered quite secure, and almost all tunnelling software uses it, there are known weaknesses of TLS. There are older TLS versions, factors of human laziness and the impact of quantum computing. We'll explore those issues here, and see how protocol layering in Dull can mitigate these concerns.

Currently, Dull uses TLS 1.0 which is considered old. This is due to stability, however we plan to make the TLS version configurable. Additional AES encryption can be used to add an extra layer of defence. Of course, you can add as many layers of encryption as you like.

It's not always practical to manage Public Key Infrastructure (PKI), the additional effort for creating and managing the TLS certificates can result in incorrect decisions or incomplete implementation. Laziness can impact decision makers, or those who are tasked with implementing TLS encryption.

The asymmetric key exchange ciphers currently used in TLS are all vulnerable to attack by quantum computers with Shor's algorithm. Quantum computers are expected to need the power of millions of qubits before this is considered a significant thread, and it's quite sensible to assume that such a quantum computer doesn't exist yet. However, for some use-cases this might be considered an unacceptable risk, especially given that current TLS encrypted communication might stored and decrypted decades later.

There are good solutions to this quantum computation weakness. There are good candidates for post-quantum asymmetric cryptography that we expect to be included in future TLS standards, the leading candidates are based on "lattice" mathematics, rather than prime factorisation of very large numbers. We suggest our customers seek TLS standards where both mature pre-quantum algorithms are used along with less-mature post-quantum algorithms.

Also, symmetric ciphers remain strong in a post-quantum world, so use with an AES duct can provide added certainty, while the shared password remains secret.

Implementation details

Uses the System.Net.Security.SslStream component of .Net Framework. Getting encryption right is hard, so it's important to use the most mature and maintained libraries. Using the built-in .Net library in turn uses the best hardened encryption code.

The TLS server role is currently statically programmed to use System.Security.Authentication.SslProtocols.Default which means TLS 1.0. This is not ideal, and the TLS version will be made configurable in the future defaulting to the highest version available.

On Windows, this component uses the SSPI Win32 API. For more platform information, see https://docs.microsoft.com/en-us/dotnet/api/system.net.security.sslstream?view=netframework-4.5.2

On Mono, it appears that this component uses BoringSSL, a fork of OpenSSL used by Google Chrome. see https://opensource.google.com/projects/boringssl