☰

OpenSSL 中的 ECDHE 密钥交换出错（Outlook 与 Cyrus imapd） - 如何解决？

tag-icon • tag-icon openssl ssl cyrus-imapd
OpenSSL 中的 ECDHE 密钥交换出错（Outlook 与 Cyrus imapd） - 如何解决？

我正在尝试使用端口 993 上的 SSL 连接，并使用 ECDHE 进行密钥协商，将 Outlook 2019 连接到 Cyrus imapd 服务器。无论我做什么，尽管 imap 服务器设置正确，但这都不起作用。

为了调试这个问题，我ssldump -a -A -H -i enp0s3在服务器上发出并在 Outlook 尝试连接时观察其输出（为简洁起见，我在第一次 C -> S 握手中保留了密码套件列表的大部分）：

New TCP connection #1: odo.lab.example.de(58717) <-> morn.lab.example.de(993)
1 1  0.0019 (0.0019)  C>S V3.3(178)  Handshake
      ClientHello
        Version 3.3
        random[32]=
          65 b1 2e 3c bb 7c 4d 04 03 0e 34 49 62 48 e5 d9
          22 c6 c9 c7 22 d4 e5 a0 76 44 64 9b a3 9d d5 bf
        cipher suites
        TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
        ...
        compression methods
                  NULL
        extensions
          server_name
              host_name: imap.lab.example.de
          supported_groups
          ec_point_formats
          signature_algorithms
          session_ticket
          extended_master_secret
          renegotiation_info
1 2  0.1245 (0.1225)  S>C V3.3(69)  Handshake
      ServerHello
        Version 3.3
        random[32]=
          3c ef 0c 80 c8 c2 35 85 90 20 8e 6f f4 e0 93 fe
          78 60 32 23 11 ec 56 df 3f f3 c6 e2 14 2f e5 2b
        session_id[0]=

        cipherSuite         TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
        compressionMethod                   NULL
        extensions
          renegotiation_info
          server_name
          ec_point_formats
          session_ticket
          extended_master_secret
1 3  0.1245 (0.0000)  S>C V3.3(1291)  Handshake
      Certificate
1 4  0.1245 (0.0000)  S>C V3.3(333)  Handshake
      ServerKeyExchange
        params
Not enough data. Found 327 bytes (expecting 32767)
1 5    0.1245   (0.0000)    S>C   V3.3(4)    Handshake
        ServerHelloDone
  1      0.1254   (0.0009)    C>S    TCP FIN
  1      0.1257   (0.0002)    S>C    TCP FIN

正如我们所看到的，客户端和服务器就所需的密码达成一致 ( TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384)。接下来，服务器似乎将其证书发送给客户端（这是一个自签名证书，但这不是问题，因为我已将该证书添加到 Windows 中的受信任根 CA）。

但接下来，密钥交换似乎存在一个问题：Not enough data. Found 327 bytes (expecting 32767)对于我的一生，尽管已经投入了近一天的时间，但我无法弄清楚它意味着什么以及如何解决它。

最初，我认为这可能与证书文件中缺少 DH 参数有关。但是，(EC)DHE 不需要此类参数，因为临时版本的目的只是动态计算它们并定期替换它们。

我是否需要向 IMAP 服务器使用的密钥或证书添加其他信息？如果我必须创建新的，那不会有问题。

我已将openssl标签分配给此问题，因为 Cyrus imapd 使用 OpenSSL 进行 SSL / TLS 加密。服务器上的OpenSSL版本是1.1.1w。

我还确保 Outlook（Windows 端）使用 TLS 1.2。这反映在上面显示的控制台输出中（Version 3.3表示 TLS 1.2）。

答案1

@Steffen Ullrich 和 dave_thompson_085 的评论都是正确的。

该消息Not enough data. Found 327 bytes (expecting 32767)来自 ssldump，而不是来自服务器或客户端。太遗憾了，我们用来分析 SSL 连接的程序包含了这样的错误，让我们走上了错误的道路。

由于多种原因，这个问题很难分析。

首先，schannel 日志记录在 Windows 中通常不处于活动状态，即使在我打开它之后，我也无法在事件查看器中看到任何有关 schannel 的条目。但几个小时后，很多这样的消息突然出现（我发誓我在此期间没有更改任何内容）。

其次，有无数来自各种称为“home”的软件组件（Windows 组件和其他应用程序和服务）的消息。当我滚动浏览大约 1000 个 schannel 条目后，我注意到一个条目带有 TLS 警报 43，事件 ID 36888。该警报意味着unsupported_certificate（请参​​阅这里第 30 页）。

第三，这种措辞让我认为我需要在服务器证书中添加一个特殊的密钥使用字段（最终是一个扩展），并让我在这方面浪费了很多时间。

但最后发现 Outlook（或 schannel）根本不喜欢服务器证书已过期。不过，对于 Thunderbird 来说这不是问题。 Windows 无法判断问题到底是什么，而是发出无用且误导性的错误消息，这超出了我的视野。

概括：

密钥协议没有问题。相反，ssldump在我使用的版本中包含一个误导我的错误。问题在于服务器证书已过期，并且 Outlook 和 Windows 没有发出合理的错误消息。

相关内容