Encryption Support

[StevenChisholm]

We are tossing around the following options. Please feel free to comment on any/all options or add some of your own.

For TCP:
None: No encryption is specified.

TLS 1.2. Server Certificate Only.
This will initiate a TLS 1.2 connection with the remote end in the traditional since where only a single certificate is used to create the encrypted channel.

TLS 1.2 Server and Client Certificate.
This will initiate a TLS 1.2 connection requiring both a client and a server certificate to negotiate the connection.

NTLM: Encrypts the channel using NTLM.
--I'm unfamiliar with this mechanic and if an encryption channel can be set up with without credentials. This might only be an option when authentication/encryption is combined.

Kerberos: Encrypts the channel using Kerberos.
--I'm unfamiliar with this mechanic and if an encryption channel can be set up with without credentials. This might only be an option when authentication/encryption is combined.

For UDP:
None: No Encryption Specified.
AES-256, CBC, PKCS7 + HMAC 256: Uses this combination of encryption to encrypt UDP packets.

[EEParker]

My suggestion would be TLS 1.2 with server+client certificate. The dual certificates might be useful when establishing connections in the opposite direction (server to client) due to environment trust high->low.

Is UDP #1 still on the table?

[ritchiecarroll]

@EEParker, UDP is still on the table - for security on UDP for now, an already secured/associated TCP channel is a prerequisite such that simple symmetric keys can be exchanged over secured TCP channel for UDP encryption.

[StevenChisholm]

We can support reverse connections with client side certificate only. Ex: Connection happens from higher level environment to the lower level environment. Once the connection is established, SSLStream doesn't care who established the connection, you just need one to act as a server and the other to act as a client.