[en] Encryption/https

Topics: Technical Support
Aug 26, 2011 at 6:50 AM

How does the encryption work or how do I enable it (SSL/TLS/...)?

I can see that you can setup the ProtectionLevel for a given protocol to use, but if I look in the source code:
http://zyan.codeplex.com/SourceControl/changeset/view/12372#147450
.. encryption will only be enabled if Windows security is enabled.

In my custom application, I cannot enable Windows security, but what does Windows security actually mean in this context? NTLM or what?

Usually when using WCF, we use a certificate in IIS and set it up to use that for https connections, and perhaps only allow access on https. But how do I accomplish the same thing here?

Hope you can help!

Thanks!

Coordinator
Aug 26, 2011 at 7:32 AM
Edited Aug 26, 2011 at 7:38 AM

> I can see that you can setup the ProtectionLevel for a given protocol to use, but if I look in the source code:
> http://zyan.codeplex.com/SourceControl/changeset/view/12372#147450
> .. encryption will only be enabled if Windows security is enabled.

You looked at the wrong ProtocolSetup class. Zyan ships with many different ProtocolSetups. Please have a look a the documentation: http://zyan.codeplex.com/wikipage?title=Network%20protocols%20setup&referringTitle=English%20Documentation

What you need is the TcpCustomClientProtocolSetup/TcpCustomServerProtocolSetup or, if bi-directional communication through firewalls is a requirement, the TcpDuplexClientProtocolSetup/TcpDuplexServerProtocolSetup.
Both include encryption out-of-the-box without any binding to Windows. But this is no SSL/TLS implementation and don´t uses X509 certificates. It´s is a custom protocol. You can configure which encryption algorithms should be used. Server and Client processing a handshake workflow to exchange RSA keys and all the stuff needed to establish a secure connection. The sent messages are encrypted, like message based security in WCF.

The goal was to provide easy to use encryption, without the need to buy any certificates or getting troubled by different certificate store solutions in different operation systems (Remember Zyan runs also on Linux and Mac with Mono).

You can check the source code of the encryption implementation in the ChannelSinks\Encryption folder insdie the Zyan Visual Studio solution.
The encryption system is implemened as .NET Remoting channel sink. It will also work with standard .NET Remoting applications without Zyan.

Aug 26, 2011 at 7:57 AM

I don't think I fully understand your answer.

First off, I currently use the TcpBinaryServerProtocolSetup, which means I suspect I was looking in the right place.
However, if you mean that I am using the wrong protocol, please give me reason for doing so.

If I look at the documentation you linked to, the TcpDuplexClientProtocolSetup/TcpDuplexServerProtocolSetup protocol lists as custom encryption. Are you saying that I should use that protocol, if I want to use my own X509 certificate? The documentation does not list that the TcpDuplexClientProtocolSetup/TcpDuplexServerProtocolSetup protocol includes default encryption - only the TcpBinaryServerProtocolSetup/TcpBinaryClientProtocolSetup indicates that.
My protocol at server side:

var protocol = new global::Zyan.Communication.Protocols.Tcp.TcpBinaryServerProtocolSetup(endpoint.Port)
{
  ProtectionLevel = System.Net.Security.ProtectionLevel.EncryptAndSign
};

 

Would that create an encrypted connection, and if so, how does that work?

You have to consider that even though I read your documentation, my knowledge on the internals of Zyan is very limited.

Coordinator
Aug 26, 2011 at 7:33 PM
Edited Aug 27, 2011 at 8:18 AM

> First off, I currently use the TcpBinaryServerProtocolSetup, which means I suspect I was looking in the right place.
> However, if you mean that I am using the wrong protocol, please give me reason for doing so.

TcpBinaryClientProtocolSetup/TcpBinaryServerProtocolSetup supports only encryption based on NTLM or Kerberos (Windows Domain is required).
You told, that you don´t want to use Windows based security. This is why I think TcpBinaryServerProtocolSetup is the wrong way.

> If I look at the documentation you linked to, the TcpDuplexClientProtocolSetup/TcpDuplexServerProtocolSetup protocol lists as custom encryption.
> Are you saying that I should use that protocol, if I want to use my own X509 certificate? The documentation does not list that the
> TcpDuplexClientProtocolSetup/TcpDuplexServerProtocolSetup protocol includes default encryption - only the TcpBinaryServerProtocolSetup/TcpBinaryClientProtocolSetup indicates that.

The list inside the documentation says "Standard Windows" not default. Zyan has currently no encryption implementaion hat supports X509 certificates.
There is also no support for SSL/TLS, yet. But SSL and certificates are not needed to establish a encrypted connection when using Zyan.

You have the following options:

  • Use Windows integrated security via NTLM or Kerberos (seems to be no real option for you)
  • Use Zyan built-in custom security (independend implementation, but with no support for certificates)
  • Implement your own encryption sink for Zyan (fantasy is your limit here)
  • Don´t encrypt anything
> Would that create an encrypted connection, and if so, how does that work?
 
You have to set the UseWindowsSecurity property to true.
Then it will encrypt, but not using any X509 certificate. Your current Windows User Security Token will be used to create an encrypted connection.
If your inside an Active Drectory domain, Kerberos protocol will be used. Otherwise the system falls back to NTLM.
This types of encrypted connection are very good for LAN and VPN applications. You have Single Sign On automaticly, but server and clients
needs to be all part of the same (or a trusted) Windows domain.
But if your application communicates straight over the Internet, you propably will not have the clients in your Windows domain.
Then the Windows based encryption will not work, because the shared infrastructure (Domain Controler with centralized User Database) are not present.
Then TcpDuplexServerProtocolSetup is a good alternative. Duplex means that you can use callbacks ands events even if the client is behind a firewall.
But back to the encryption topic. TcpDuplexServerProtocolSetup encypts your connection automaticly, if you want. All you have to do ist set Encryption = true.
example
// The third parameter activates encryption
// Replace the NullAuthenticationProvider if you need user authentication
var protocol = new TcpDuplexServerProtocolSetup(endpoint.Port, new NullAuthenticationProvider(), true);

If you tell me, what kind of application you´re writing, I´ll help you to find the best configuration. What are your reqirements?

When the predefined ProtocolSetups don´t fit your requirements, you can create your own ProtocolSetups (like Custom Bindings in WCF)
Aug 31, 2011 at 5:11 PM

Hello Rainbird

Thanks for your response, and sorry for my late response.

We are developing a client-server solution, where we have a lot of clients. We are placing the clients all over the country, and we have to encrypt the connection to our servers.

I don't have any protocol preference, other than performance would be nice, so I think TcpDuplexServerProtocol is just fine for us?

Best regards

Coordinator
Aug 31, 2011 at 9:45 PM
Edited Sep 2, 2011 at 6:16 AM

Hello cln,

Yes, it will. TcpDuplexServerProtocol is developed for both Internet and LAN communication. You can use it even for hosting in the Microsoft Azure Cloud.

The currently built-in Zyan encryption feature (sometimes called "custom encyrption") which is usable trough TcpDuplexServerProtocol, pass trough the following steps to create a encrypted connection:

  • Client creates a asymmetric RSA key pair (private and public key)
  • Client send his public RSA key to server
  • Server creates a shared key (needed for fast symmetric encryption of data)
  • Server encrypts the shared key with the client´s public RSA key and sends the encrypted shared key back to the client
  • Client decrypts the shared key with it´s private RSA key (if this works, server and client have a shared secret to encrypt and decrypt messages with fast symmetric algorithms)
  • Together with the keys, client and server exchange a secure transaction id (this is a GUID needed for session correleation)
  • << Handshake is done now, we have a secured connection so far >>
  • Client encrypts message (when a remote call is processed) with the shared key using a symmetric algorithm (3DES by default) and sends encypted message to server
  • Server decrypts the message with the shared key using a symmetric algorithm (protocol setups of client ands server must be configured for using the same symmetric algorithm)
  • And so on ...

The encryption is implemented as channel sink. This means that it is independent from the transport channel. The same encryption sink is used by HttpCustomServerProtocolSetup.
Let´s think about writing new transport channels (remote calls via SMTP protocol for example). The encryption sink will work with them together. That is a great benefit of message based security.
If security features like encryption are handled at transport level (like SSL/TLS), they depend on the transport channel implementation.

TcpDuplexServerProtocolSetup and TcpDuplexClientProtocolSetup offers you two configuration properties related to encryption:

Algorithm

This string property allows you to set the symmetric encyrption algorithm to be used.
Default value is "3DES". Allowed values are (see links in brackets for further information about theese alogrithms):

Which one fits best for you, depends on your specific scenario. Here you can find some performance comparison of encyprion algorithms: http://www.cse.wustl.edu/~jain/cse567-06/ftp/encryption_perf/index.html

Oeap

This property activated OEAP padding, if set to true. This formats the encrypted data in a special way, that improves security (prevents partial decryption of a message). It is disabled (false) by default, because it takes additional processing time. You should set it to true, if security goes over performance in your special case.

Please ensure that your clients using the same configuration as your server. Otherwise you´ll get an exception and remote calls will not work.
I hope this information helps you to understand, how Zyan custom encryption works. This may important if you have to do troubleshooting (I hope you never have to).

 


I´m currently thinking about support for SSL/TLS based transport security in Zyan.
The Open Source security library from mentalis.org may a candidate to create a Zyan transport channel with SSL + X509 support.
But there is no code written, yet. It´s just a thought.

 

If this gets serious, I´ll post information here in the Zyan discussions.

If there is a SSL channel available in future, you can still change your protocol setup or support multiple configurations.

Feel free to ask, if you have any other questions about Zyan.