使用 WCF 使用 HTTPS Web 服务答案

【问题标题】：Consuming HTTPS web service using WCF使用 WCF 使用 HTTPS Web 服务
【发布时间】：2011-08-03 19:34:17
【问题描述】：

我正在尝试使用 WCF 使用客户端的 Web 服务。客户端的 Web 服务是通过 HTTPS 完成的，我可以通过以下 Binding 很好地使用它：

<bindings>
  <basicHttpBinding>
    <binding name="PurchaseOrderSoap" closeTimeout="00:01:00" openTimeout="00:01:00"
        receiveTimeout="00:10:00" sendTimeout="00:01:00" allowCookies="false"
        bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
        maxBufferSize="65536" maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
        messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
        useDefaultWebProxy="true">
      <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
          maxBytesPerRead="4096" maxNameTableCharCount="16384" />
      <security mode="Transport" />
    </binding>
  </basicHttpBinding>
</bindings>

但是，我们的安全团队告诉我，我需要使用 Message 或 TransportWithMessageCredential 安全性，因为 Fortify 360 抱怨 Transport 安全性太弱。

当我尝试Meesage 时出现此错误：

System.InvalidOperationException: BasicHttp binding requires that 
BasicHttpBinding.Security.Message.ClientCredentialType be equivalent to the 
BasicHttpMessageCredentialType.Certificate credential type for secure messages. Select 
Transport or TransportWithMessageCredential security for UserName credentials.

使用TransportWithMessageCredential 我得到以下错误：

System.InvalidOperationException: The username is not provided. Specify username in 
ClientCredentials.

我没有用户名/密码（我可以在浏览器中正常连接），所以我的问题是：

在使用现有的 HTTPS Web 服务时我可以使用Message 或TransportWithMessageCredentials（无需发布者进行任何更改）吗？如果是这样，我需要对我的配置进行哪些更改？

编辑澄清问题。

【问题讨论】：

您是否正在与客户协商要公开的内容？如果他们没有使用消息安全性，那么您在客户端对此无能为力。两端必须就安全策略达成一致。
@tomasr：这是一个很多人目前都在使用的网络服务，所以没有改变它当前行为的空间。我会相应地更改问题。

标签： web-services wcf configuration https fortify

【解决方案1】：

如果您无法让第三方供应商为其服务添加支持消息安全的端点，那么您将陷入困境。他们目前似乎只支持具有传输级别安全性的 basicHttpBinding。

传输安全性并不比消息级别的安全性“低”。消息级别的安全性意味着肥皂消息的内容是加密的。这使您可以以明文方式存储或转发消息，并且仍然可以确保没有人可以偷看消息。如果您所做的只是通过 Internet 在您的系统和供应商之间进行通信，那么传输和消息级别的安全性同样安全。

【讨论】：

根据 Fortify 360 的说法：Transport security specifies that confidentiality, integrity, and authentication are provided by transport-layer mechanisms (such as HTTPS). When using a transport like HTTPS, this mode has the advantage of being efficient in its performance and well understood because of its prevalence on the Internet. The disadvantage is that this kind of security is applied separately on each hop in the communication path, making the communication susceptible to a "man in the middle" attack. 所以问题在于缺乏身份验证。
理论上，可以将“中间人”攻击应用于任何基于 SSL (HTTPS) 的连接。基于消息的加密也容易受到成功包含证书的攻击，就像最近发生在 RSA 上一样。关键是所有加密方法都会有一些漏洞，即使尚未确定攻击策略。安全是关于最小化风险。 SSL 对于当今互联网上的所有公共电子商务来说都是完全可以接受的，因此它提供了合理的安全级别，尤其是考虑到您无法更改 3rd 方服务配置。
谢谢！有关中间人攻击的更多信息，以下是相关问题的答案：stackoverflow.com/questions/3591342

【解决方案2】：

basicHttpBinding 仅支持用户名和证书消息安全。因此，一种选择是，如果您的系统上没有验证用户凭据的机制，则使用证书。

<security mode="TransportWithMessageCredential">
    ...
    <message clientCredentialType="UserName"/>
</security>

另一种选择是使用不同的绑定，例如 wsHttpBinding，它默认启用了消息安全性，并且还支持 Windows 和 Issued Token 凭证类型。您实施哪一个在很大程度上取决于您的实施要求和环境。

【讨论】：

我没有任何凭据可以使用，并且看到客户端不受我的控制（并且由于其他用户而无法更改），我认为我不能使用您提供的代码.我可以在客户端使用证书而不进行任何更改吗？
@Jackson Pope：无法对您的客户进行任何更改将限制您的选择。我认为@Sixto 是对的。大多数情况下，传输安全性是可以接受的。如果通道受到威胁，它无论如何都会破坏消息，使其无用。

【解决方案3】：

您是否没有某种例外政策来记录为什么无法实施 Fortify 的最佳建议？

我认为您能做的最好的事情就是与您的 Web 服务供应商沟通并要求增强以支持 Fortify 的传输指南。

另外：我怀疑你说网络浏览器在没有凭据的情况下连接你。这可能意味着您要连接的系统比您的假设要复杂一些。不同的连接或不同的 url 可能由不同的服务器（SSO？）提供服务，或者可能受制于不同的安全策略（客户端证书等）

【讨论】：