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

Question

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?

Asymptotic

Is there any specific reason why you can't use message level security? – Holp

There is no specific reason we can't use message-level security. I'm unaware of why that would be easier to implement, though. – Asymptotic

Answer 1

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.

Maneuver

This was my hypothesis on the server side, but it only explains the server side. It doesn't explain why things are harder on the client side. Why do all the examples I read involve storing a certificate in the client store and calling SetCertificate (like here)? – Asymptotic

It's almost making sense, except for two points. First, it's true that the browser handles all of this for you, but even if you aren't using a browser (just a Windows Forms app with WCF client code), it still takes care of it for you. So, Microsoft must be handling it for us. They just chose not to handle it for us in the net.tcp case? Finally, if you accept all this, then it seems the extra work for TCP would to be implement your own certificate handling. Instead, what we see is people having a brand new certificate installed on the client that doesn't even appear in the HTTP case. – Asymptotic

@Greg: Microsoft isn't exactly taking care of it for you. The very nature of the HTTPS protocol is to support negotiation. It's part of the standard, everyone's agreed on how it works. TCP however, has no such specification, it's a lower level protocol. Could microsoft have handled it for you? Sure. But that would make interoperability more difficult. Best to just let the client handle it on its own. SSL has a specification for temporary keys; so the client doesn't need one installed permanently. – Maneuver

Answer 2

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.

Zoraidazorana