I need to secure my .NET Remoting by SSL.
I'm using TCPChannel and I can't switch to HTTPChannel and use IIS to add the SSL.
Thus, what I figured out, I need to create my own Sink that will encrypt the streams going to/from Client/Server. For that, I found good article at MSDN: http://msdn.microsoft.com/en-us/magazine/cc300447.aspx. However, that article is developing the crypt, handshake, etc.
I do not want to "reinvent the wheel". I'm afraid of making mistakes when developing this logic on my own. I would rather like to use some SSL implementation (e.g. SslStream or OpenSSL) that will do that stuff for me.
Can I use SslStream or OpenSSL in .NET Remoting with the TCPChannel?
Would you suggest a simple usage?
Thank you for your help.
Consider switching over to WCF.
Alternatively, Remoting should be able to do the equivalent of using WCF with ClientCredentialType set to Windows, if you specify secure='true' in your remoting configuration on both client and server side. TcpChannel will start using SSL under the hood to encrypt the communication, using user credentials for key material. On client side, this also has the implied effect of setting tokenImpersonationLevel='identify' which means that the server will not impersonate the user account under which the client is executing, but it will know who connected to it (assuming the client and the server run in the same AD domain). For performance reasons, set useAuthenticatedConnectionSharing to true on the client side.
Related
I have a very specific question about the transport encryption used at Windows Communication Foundation. I wrote a client and a service application.The service is hosted as Windows Service and started with a special user, let us say Jeremy.
My client is on a seperate computer but in the same domain. Communication happens over a net.tcp binding with a transport encryption.
Problem 1: if i sniff with wireshark, the first packages are in clear text
Problem 2: in the App.config of the client is a auto-generated identity-tag in the form of "jeremy#mycompany.com". If i set it blank everything is send in clear text. If i delete it, the program won't work.
Is anybody able to describe what exactly happens during the handshake? I thought Kerberos is fetching a ticket at the service to authenticate the client. But why is it in clear text then?
I hope somebody is able to help.
Edit: The clientCredentialType is of course Windows with protectionLevel: encryptAndSign
Ok after a lot of research I found out that this happend due to a discrepancy of Kerberos an NTLM.
The cleartext I mentioned is the handshake between server and client. So if I use Kerberos the clear text are only some chars which calls the service. If Kerberos is then not available or if you change the identity tag Kerberos falls back to NTLM which is responsible vor a much longer handshake and so on a few more clear text passages. I now forced the client to use Kerberos with following line:
<endpointBehaviors>
<behavior>
<clientCredentials>
<windows allowNtlm="false"/>
</clientCredentials>
</behavior>
</endpointBehaviors>
At the windows security logs you can now see that authentication happens via Kerberos.
Here the links that helped me most to understand Kerberos and solve the problem:
https://blogs.msdn.microsoft.com/asiatech/2009/08/27/how-to-impersonate-or-delegate-a-client-in-wcf/
https://www.tecchannel.de/a/die-funktionsweise-von-kerberos,461645
https://msdn.microsoft.com/en-us/library/59hafwyt(v=vs.100).aspx
I'm able to get an unsecured FTP Client/Server system going, but when I try throwing in the SSL io handlers, setting up both apps to use sslvTLSv1, it shows Connected for the Client status then eventually times out (the only Server message I get is Socket Error # 10060).
After many trials and tribulations trying to resolve this issue, I've determined that there are serious problems with enabling a certificate-less security system; meaning that, if you want it secured (with the current Indy code), you need to use certificates. Perhaps there are some settings in the SSL component that need to be made, but there just isn't specific enough info (working examples of certificate-less SSL) to make this work. Hopefully this deadlock will be resolved in a future release of Indy ;)
I feel lost trying to figure out what my options are. Apache's programmers guide and administrators guide do not detail anything substantial. My O'Reilly Zookeeper book barely talks about security... did I miss something? I was hoping to find tutorials through google about authenticating client connections, authorizing actions, and encrypting messages sent between zookeepers and client.
I had a lot of trouble but I figured it out and the links at the bottom where a huge help to me.
This code (using Curator) was something hard to figure out:
List<ACL> myAclList = new ArrayList<ACL>();
aclList.add(new ACL(ZooDefs.Perms.ALL, ZooDefs.Ids.AUTH_IDS));
client.create(withACL(myAclList)).forPath(myPath);
If I setup the zookeeper configuration correctly, then it will enforce that only the AUTH_IDS will be allowed to access my ZNode.
Ofiicial documentation, My mailing list Q1, My mailing list Q2, JIRA that I found useful, but some items are out of date
Since zookeeper version 3.5.4-beta, you are able to enable using client certificates to secure communication to a remote zookeeper server:
Client
ZooKeeper client can use Netty by setting Java system property:
zookeeper.clientCnxnSocket="org.apache.zookeeper.ClientCnxnSocketNetty"
In order to do secure communication on client, set this Java system property:
zookeeper.client.secure=true
Note that with "secure" property set the client could and should only connect to server’s “secureClientPort” which will be described shortly.
Then set up keystore and truststore environment by setting the following Java system properties:
zookeeper.ssl.keyStore.location="/path/to/your/keystore"
zookeeper.ssl.keyStore.password="keystore_password"
zookeeper.ssl.trustStore.location="/path/to/your/truststore"
zookeeper.ssl.trustStore.password="truststore_password"
Server
ZooKeeper server can use Netty by setting this Java system property:
zookeeper.serverCnxnFactory="org.apache.zookeeper.server.NettyServerCnxnFactory"
ZooKeeper server also needs to provide a listening port to accept secure client connections. This port is different from and running in parallel with the known “clientPort”. It should be added in “zoo.cfg”:
secureClientPort=2281
All secure clients (mentioned above) should connect to this port.
Then set up keystore and truststore environment like what client does.
More info here:
https://cwiki.apache.org/confluence/display/ZOOKEEPER/ZooKeeper+SSL+User+Guide
I am creating a new CORBA client and registering this to the Persistent Naming Service which was started using Sun ORB or ORBD. I want to use secure IIOP communication for my application and I am able to set the security properties while starting my CORBA client as I am using jacorb API for client. For some reason I am using ORBD service(instead of any other ORB such as JacORB) and could not find a way to start the ORBD service in a secure way.
So I would like to know how to enforce a secure (encrypted) IIOP connection when I start ORBD service?
Does it expose some properties to be set to enforce security?
Thanks for any suggestions.
Due to a couple of issues with my host, I'm unable to use a SSL-certificate on my server (I'm not ready to change provider just yet), and can't therefore use HTTPS. This server will communicate with a couple of client-computers and will transfer data that's somewhat secret.
Would it be reasonable to simply use AES encryption (encryption on client before sending, decryption on server before processing) instead of HTTPS?
This depends on your deployment environment.
Replacing SSL/TLS (and HTTPS) with your own encryption protocol for use by a web browser is always a bad idea, since it relies on JavaScript code delivered insecurely (for details, see this question on Security.SE, for example).
If the client isn't a web browser, you have more options available. In particular, you can implement message-level security instead of transport-level security (which is what HTTPS uses).
There are a number of attempts to standardise message-level security with HTTP. For example:
HTTPsec had a public specification (still available on WebArchive), but a commercial implementation. I'm not sure whether this has been widely reviewed.
WS-Security, oriented towards the world of SOAP.
Perhaps more simply, if you want to re-use existing tools, you could use S/MIME or PGP (in the same way as you would for e-mails) to encrypt the HTTP message entities. Unlike HTTPS, this won't protect the URL or the HTTP headers, but this might be enough if you don't put any sensitive data there.
The further down you go with "raw encryption" yourself (using AES directly, for example), the more likely you'll have to implement other aspects of security manually (typically, verifying the remote party's identity and dealing with the problem of pre-sharing the keys).
If you have a small list of clients that don't change often, you could implement your own SSL-Tunnel using SSH. On the clients do a;
ssh -D 4444 nulluser#example.com -N
where nulluser has no shell or file access on example.com.
Then add a foxyproxy whitelist setting - so that for example.com the client browsers use the localhost:4040 proxy.
It's a hack, it's totally unscalable, but it would work as I say for a small, static number of clients, and it has the advantage of not reinventing any wheels while being totally secure.