【问题标题】:System.ComponentModel.Win32Exception: The client and server cannot communicate, because they do not possess a common algorithmSystem.ComponentModel.Win32Exception:客户端和服务器无法通信,因为它们没有共同的算法
【发布时间】:2017-10-07 14:33:32
【问题描述】:

上个月,我更新了一个客户网站以确保安全。本周(05/10 @ 大约上午 10 点)没有任何问题,但我开始收到详细说明以下内容的异常:

System.ComponentModel.Win32Exception: The client and server cannot communicate, because they do not possess a common algorithm

我的 AWS MySQL RDS 的连接字符串从一开始就包含 SSLMode=Required。

我花了很长时间试图找出造成这种情况的根本原因,最后将数据库上的 SSLMode 设置为 none。

我得出的唯一结论是网站上的SSL证书之间存在冲突,并强制我的MySQL连接SSLMode需要。

我已将网站更新为 .net 4.6.* 无济于事....

欢迎提出任何想法或建议......

我正在使用:MySQL 连接器、AWS MySQL 5.6、.net 4.6

内部异常:

 System.Data.Entity.Core.ProviderIncompatibleException: An error occurred accessing the database. This usually means that the connection to the database failed. Check that the connection string is correct and that the appropriate DbContext constructor is being used to specify it or find it in the application's config file. See http://go.microsoft.com/fwlink/?LinkId=386386 for information on DbContext and connections. See the inner exception for details of the failure. ---> System.Data.Entity.Core.ProviderIncompatibleException: The provider did not return a ProviderManifestToken string. ---> System.Security.Authentication.AuthenticationException: A call to SSPI failed, see inner exception. ---> System.ComponentModel.Win32Exception: The client and server cannot communicate, because they do not possess a common algorithm
   --- End of inner exception stack trace ---
   at System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, Exception exception)
   at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)

【问题讨论】:

    标签: mysql .net ssl amazon-rds mysql-connector


    【解决方案1】:

    请注意,我对 MySQL 连接器或 AWS 没有任何线索。说了这么多,我猜测一下:

    从错误消息中,我们最终可以得出结论,客户端和服务器无法就密码套件达成一致。如果您还没有听说过该主题:

    SSL 是一种协议,它可以使用大量不同的密钥交换、加密和 MAC 算法。 (密钥交换、加密、MAC)算法(方法)的某个元组称为密码套件。当建立 SSL 连接时,服务器和客户端需要就特定的密码套件达成一致,该密码套件将用于交换密钥、加密和验证连接。

    这背后的基本原理是,无需更改 SSL 规范本身即可轻松引入和使用新的、更安全的密码,并且无需更改 SSL 规范本身即可轻松删除旧的、不安全的、损坏的密码。

    这意味着服务器的所有者可以说:“我向我的客户提供 SSL,但仅限于密码套件 X、Y 和 Z”。如果客户端尝试连接,但仅支持密码套件 A、B 和 C,则连接将失败。

    现在,密码套件有时会被弃用,因为它被认为是不安全的。在这种情况下,该密码套件通常会被操作系统收到的安全更新静默禁用,这就是您可能遇到的情况:

    当服务器更新后,一个或多个 SSL 密码套件可能已被禁用,无论是通过更新 MySQL 还是通过更新 O/S 本身或为应用程序提供加密服务的库。这可能会导致您(客户端)和服务器不再拥有通用密码套件。

    也有可能有人故意禁用了服务器上的某些密码套件(即手动,即不是安装更新的“附带损害”)。

    此外,情况可能相反:如果您在您的机器(客户端)上安装了更新或禁用了某些密码套件,您的客户端和服务器可能无法再连接.

    要确定如何调试它,我们需要更多地了解您的配置。不过,一个通用提示:

    在 SSL 握手期间,客户端向服务器发送一个 hello,反之亦然。这个问候中的客户端和服务器提供了他们支持的密码套件列表。由于客户端和服务器 hello 未加密,因此您可以使用 Wireshark 等工具轻松嗅探它们。然后您可以比较客户端和服务器支持的密码套件列表,并检查是否至少有一个通用密码套件。

    如果没有,您可能已经找到问题所在。在这种情况下,您必须在客户端或服务器端更改配置,以便客户端和服务器再次拥有至少一个通用密码套件。如果您需要帮助,请回来,但请先分析上述情况。

    【讨论】:

    • 好答案。众所周知,在 TLS 协商中,客户端首先进行协商。这与服务器首先对话的 MySQL 客户端/服务器协议不一致。因此,当在 MySQL 中使用 TLS 时,像往常一样有一个初始的 MySQL 握手,但客户端在其“功能”数据包中设置了一个位标志,表示客户端将开始 TLS 协商,而不是提供身份验证数据。因此,在网络上,它的开始与普通 TLS 不同。此细节排除了使用 openssl s_client 等有用工具进行的测试。我假设 wireshark 处理了这个怪癖,但不知道。
    • 这为我指明了正确的方向。密码套件在 AWS 端没有改变,所以我需要与负责我的服务器的人一起找出问题的根源。这几乎可以肯定是答案,所以一旦我深入了解它就会弹出并相应地标记它。非常详细,非常感谢。
    • @Michael-sqlbot 感谢您的解释和 +1。我不知道,因为我总是在与客户端相同的机器上使用 MySQL 进行典型设置,并且只在 localhost 上监听;因此,我从未使用过 MySQL 的 SSL。不过要说一句:我强烈假设(即使考虑到 MySQL 奇怪的 SSL 实现)在某些时候会有一个未加密的客户端和服务器 hello。所以你可以只捕获数据包,即使没有正确剖析它们,这些问候也会在原始数据中。由于这发生在连接开始时,因此应该很容易找到它们。
    • @JonSelby 谢谢。我想了很久是否应该回答,因为我对 AWS 和 MySQL 连接器一无所知,也不想自欺欺人。此外,错误消息的措辞完全不同寻常。使用 SSL 之类的人不会说“拥有通用算法”(通常的措辞是“不支持密码套件”等)。我不知道 MS 开发人员在实施该错误消息之前抽了什么东西,但这几乎让我无法回答,因为我认为这与通常的密码套件问题没有任何关系。
    • @Binarus 对 Microsoft 的评论感知错误消息?当出现问题时,将使他们的框架更容易处理。阿门 stackoverflow....
    猜你喜欢
    • 2018-03-25
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-10-15
    • 2016-11-09
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多