为什么在net.tcp协议上启用SSL（传输安全）比HTTP协议更难？

Question

实现使用WCF over HTTP的传输级安全的Web服务非常简单：启用我的WCF服务的SSL 实现使用WCF over net.tcp的传输级安全的Web服务很困难：使用netTcpBinding和证书传输安全的WCF，通常需要在服务器端和客户端都进行类似以下的操作：

... 而且net.tcp解决方案通常涉及到这样的操作：

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

在HTTP情况下，无需在客户端或服务器上提及证书。在NET.TCP情况下，大多数文献中都需要在客户端和服务器上存储、定位和指定证书。

是什么使您在HTTP模式下无需担心证书的事情？为什么在使用net.tcp时这种魔法不可用？

- Greg Smalter

---

您不能使用消息级别安全性的具体原因是什么？ - Oliver Weichhold

没有特定的原因不能使用消息级别的安全性。虽然我不知道为什么那样更容易实现。 - Greg Smalter

Answer 1

因为使用WCF通过HTTPS时，IIS会处理证书的协商（就像普通的SSL一样）。由于没有内置TCP的IIS服务器，因此您必须自己处理。对于HTTPS，您仍然需要使用证书和WCF，但配置是在IIS上完成的。

编辑：对于客户端，您仍然需要另一个软件来处理。当通过SSL浏览网站时，浏览器会为您处理所有内容。由于TCP中没有标准的协商模式，所以客户端必须自己处理。

- vcsjones

---

这是我对服务器端的假设，但它只解释了服务器端。它并没有解释为什么客户端方面更难。为什么我读到的所有示例都涉及将证书存储在客户端存储中并调用SetCertificate（例如这里）？ - Greg Smalter

这个问题几乎说得通了，除了两个地方。首先，浏览器确实为您处理所有这些，但即使您不使用浏览器（只是一个带有WCF客户端代码的Windows窗体应用程序），它仍然会为您处理。所以，微软必须在为我们处理它。他们只是选择在net.tcp情况下不为我们处理它？最后，如果您接受所有这些，那么看起来TCP的额外工作就是实现自己的证书处理。相反，我们看到的是人们在客户端安装全新的证书，甚至在HTTP情况下也没有出现过。 - Greg Smalter

@Greg：微软并不会为你负责。HTTPS协议的本质是支持协商的，这是标准的一部分，所有人都同意其工作方式。然而TCP协议没有这样的规定，它是更低级的协议。微软是否可以为您处理呢？当然可以。但这将使互操作性更加困难。最好让客户端自行处理。SSL有一个临时密钥规范，因此客户端不需要永久安装密钥。 - vcsjones

Answer 2

我也曾经为此苦苦挣扎，现在终于感觉自己像个白痴。这很好，因为这意味着我真正理解了以前只是胡乱尝试的东西。

在实现服务时，您的目标是使用 SSL 保护通信。您还需要能够在 Visual Studio 中生成 reference.cs 文件。您遇到的问题是将元数据交换放在 SSL 绑定下时。代码生成工具不允许您配置必要的 netTcpBinding 配置部分，用于调用获取元数据时生成 reference.cs 文件。

您应该在 netTcpBinding 下创建两个单独的绑定配置，一个用于您的服务：

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

一个包含配置信息，另一个则不包含：

<security mode="None" />

而不是使用 <bindingConfig>。确保所有其他设置匹配，并且您的服务端点指向 SSL 绑定配置，而元数据端点指向无 SSL 绑定。然后，您将能够读取元数据并再次更新服务引用。

需要注意的一点是，在任何生产发布中，应该将元数据绑定移除。这样可以确保您不会暴露任何未经 SSL 加密的内容。

- steve