Why is it so much harder to enable SSL (Transport security) over net.tcp than HTTP?

6
votes

Implementing a web service that uses Transport-level security with WCF over HTTP is pretty easy: Enable SSL for my WCF service

Implementing a web service that uses Transport-level security with WCF over net.tcp is pretty hard: WCF with netTcpBinding and Certificate transport security

... and the net.tcp solution usually involves something like this on both the server side and the client side:

 <serviceCertificate
       findValue="MyServiceCertificate"
       storeLocation="LocalMachine"
       storeName="My"
       x509FindType="FindBySubjectName" />

In the HTTP case, you don't need to even mention a certificate on either the client or the server. In the NET.TCP case, you have to store, locate, and specify a certificate on both the client and the server in most of the sources I've read.

What is the thing doing the magic that makes you not have to worry about the certificates in HTTP mode? And, why is this magic not available to you when using net.tcp?

2
.netwcfsslnettcpbinding
Is there any specific reason why you can't use message level security? – Oliver Weichhold
There is no specific reason we can't use message-level security. I'm unaware of why that would be easier to implement, though. – Greg Smalter

2 Answers

6
votes

Because when using WCF over HTTPS; IIS manages the negotiation with the certificates (Just like plain SSL). Since there is no IIS server with that built in for TCP, you have to do it yourself. You are still doing stuff with certificates + WCF for HTTPS, but the configuration is done at IIS.

EDIT:

For client side, you still have another piece of software. When browsing a website over SSL, the browser is handling all of that for you. SSL over HTTP has a standard negotiation pattern because it's part of the HTTPS protocol. For TCP, that isn't part of the protocol so the client has to take care of that itself.

0
votes

I've struggled like hell with this too and now finally feel like an idiot. Which is nice because it means I actually understand something that I was just hacking around before.

When implementing your service, your goal is to secure the communications with SSL. You need to be able to generate your reference.cs file in visual studio too. The problem you have is when you put your meta data exchange under the SSL binding too. The code generation tools don't allow you to configure the necessary netTcpBinding config sections for the calls that are made to get the meta data when it is used to generate reference.cs file.

You should create two separate binding configurations under netTcpBinding, one for your service with the:

<security mode="TransportWithMessageCredential">
    <message clientCredentialType="Certificate"/>
</security>

config inside and another with:

<security mode="None" />

instead. Make sure all the other settings match and the endpoint for your service points at the ssl bindingConfig while the metadata end point is pointing at the no SSL binding. You will then be able to read metadata and update the service reference again.

One thing to note is, you should take the meta data binding out for any prod releases. This ensures that you aren't exposing anything that isn't over SSL.