Azure 服务总线 - 队列连接错误答案

【问题标题】：Azure Service bus - queue connectivity errorAzure 服务总线 - 队列连接错误
【发布时间】：2017-02-14 15:50:45
【问题描述】：

我正在尝试使用以下代码连接并向 azure 服务总线队列发送消息

var connectionString = "<Your connection string>";

var queueName = "<Your queue name>";

var client = QueueClient.CreateFromConnectionString(connectionString, queueName);
var message = new BrokeredMessage("This is a test message!");
client.Send(message);

这是他们网站上作为示例的相同代码。

但是在连接时，它会给出一个 SSPI 错误，内部异常为“客户端和服务器不具备通用算法”。

另外，我在我的系统中禁用了 TLS 1.0 和 SSL 3.0。是不是因为这个。

有人可以帮我理解这里出了什么问题吗？

【问题讨论】：

您的应用程序在哪里运行（什么主机）？你有防火墙吗？默认连接模式是 TCP，因此端口可能被阻塞。更多关于连接模式的信息：msdn.microsoft.com/en-us/library/… 还有另一个线程有类似的问题：stackoverflow.com/questions/35469739/…
@Sean Feldman 我的应用程序在 azure Web 应用程序上运行，但这个问题是当我在我的 IIS 主机上本地尝试它时......在我的机器上......我在部署它后没有尝试过。我也尝试过更改服务总线环境，但没有成功。

标签： azure message-queue

【解决方案1】：

客户端和服务器没有共同的算法

这不是 TCP 层的问题。这在 TLS 握手中更高，这意味着。双方（客户端和服务器）无法就通用密码套件达成一致，握手失败。

通过 SSLLab 的浏览器测试运行您的客户端主机（即使它不是浏览器）： https://www.ssllabs.com/ssltest/viewMyClient.html

然后通过服务器测试页面运行Service Bus端点：
https://www.ssllabs.com/ssltest/

比较结果并在您的客户端中启用至少一个与服务总线端点上的 TLS 堆栈接受的密码套件相匹配的密码套件。

你也应该简单地尝试做：

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

..由于您已禁用 TLS 1.0，而我不再确定您的 .NET now defaults to 是什么，因此明确设置协议版本是自然的方法。

TLS 1.2 已发布back in 2008。您可以确定 Azure 在全球范围内支持所有服务 - check your own Service Bus namespace here! （935x/TCP 也是如此）。

仅支持 TLS 1.2 是不够的，您的主机必须至少有一个与服务器共用的密码套件——使用它来检查您的主机：

https://github.com/snobu/get-schannel-ciphers（/Release/下的.exe）

【讨论】：

我已经在我的应用程序启动中明确设置了安全协议版本。所以我可以确认并确保我的应用程序使用 TLS 1.1 或 TLS 1.2 进行出站请求。我猜 Azure 服务总线在 TLS 1.0 上运行，目前还不能处理 TLS 1.1 及更高版本
TLS 1.2 于 2008 年发布 (tools.ietf.org/html/rfc5246)。您可以确定 Azure 支持全球所有服务 - 请参阅 ssllabs.com/ssltest/…（9354/TCP 的情况相同）。仅支持 TLS 1.2 是不够的，您的主机必须至少有一个与服务器共用的密码套件——使用它来检查您的主机：github.com/snobu/get-schannel-ciphers（/Release/ 下的 .exe）
我知道我在拖一个较旧的帖子，但这是我能找到的唯一一个与我正在处理的内容相近的东西。我尝试在 PCI 要求意味着禁用 TLS 1.0 的计算机上使用 Azure 服务总线时遇到同样的问题。有趣的是，启用 TLS 1.0 后一切正常。简单地禁用 TLS 1.0 会破坏应用程序。我不会假装了解密码套件的所有内容，但看起来 TLS 1.0 确实是个问题，因为它在运行时一切正常。
启动 Wireshark 并检查您的应用程序尝试与另一端协商的内容（客户端 Hello 数据包）。 16 03 01 是 TLS 1.0，03 02 TLS 1.1 03 03 TLS 1.2 - blog.bfitz.us/?p=1508

【解决方案2】：

我们在禁用 TLS 1.0 和 1.1 时遇到了完全相同的问题（我们使用了 https://docs.nwebsec.com/projects/AzureStartupTasks/en/latest/ 并且还添加了

    ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

在 Application_Start 下的 Global.asax 中）。

我们通过 Microsoft 支持打开了一张票，发现 Azure 服务总线需要升级到 .Net Framework 4.6.2 才能支持 TLS 1.1 和 TLS 1.2。以下是详细信息：

Service Bus 依赖底层 SSLStream 类来实现 NetEventRealyBinding 的安全通信。

在 .Net Framework 4.5.2 中包含的 WCF 中，SSLStream 仅支持 SSL 3.0 和 TLS 1.0。

.Net Framework 4.6.2 中的 WCF 版本支持 SSLStream 的 TLS 1.1 和 TLS 1.2。

服务总线服务需要更新才能使用 .Net Framework 4.6.2。目前，服务总线使用 OSFamily 4 https://docs.microsoft.com/en-us/azure/cloud-services/cloud-services-guestos-update-matrix#family-4-releases，它具有 .Net Framework 4.5.2。目前升级到 .Net Framework 的计划定于 2017 年年中。

我会在收到来自 Microsoft 的更多消息后更新此答案。

2017 年 3 月 21 日更新：

Microsoft 发送了这个解决方法，它解决了问题并允许我们的代码使用 TLS 1.2。

在您当前用于设置 TLS 1.2 的 PowerShell 脚本中，添加以下行。在 .Net Framework 4.5.2 上，这将强制 SslStreams 使用 Tls 1.0/1.1/1.2。但由于您的机器仅允许 TLS 1.2，因此将使用它。
```
UpdateRegistryKey "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" "SchUseStrongCrypto" 1 "DWORD"          
```
在你的代码启动时添加以下行，然后重新构建和重新测试
```
ServiceBusEnvironment.SystemConnectivity.Mode = ConnectivityMode.Https;
```

【讨论】：