【发布时间】：2019-10-24 19:25:05
【问题描述】：
我正在使用 OpenSSL 1.1.1b 附带的 Ubuntu 19.04。系统信息如下。我在 KEYUPDATE 期间传输大型文档时遇到 SSL_key_update:wrong ssl version。
我正在启动我的服务器：
openssl s_server -accept 443 -cert /app/keys/cert.pem -key /app/keys/private.key
我正在使用 AES128 使用以下命令连接到服务器：
openssl s_client -connect localhost:443 -cipher AES128-GCM-SHA256 -tls1_2
有时它会起作用，尤其是当我发送的数据少于 100KB 时。但是，对于较大的传输，它通常会停止：
KEYUPDATE
140048546800768:error:1420310A:SSL routines:SSL_key_update:wrong ssl version:../ssl/ssl_lib.c:2090:
Others have seen this too 但他们似乎无法断定是配置的哪个方面导致了问题。
有趣的是，如果我在同一台 1.1.1b 服务器上运行较旧的 openssl 1.1.0h-fips s_client，则在使用相同的 -cipher AES128-GCM-SHA256 -tls1_2 选项时它工作得很好。事实上它说：
Protocol : TLSv1.2
Cipher : AES128-GCM-SHA256
与 1.1.1b 客户端一样...只是 1.1.1b 客户端似乎无法正常工作。
有什么问题，我该如何解决？
这是系统信息：
cli5# openssl version -a
OpenSSL 1.1.1b 26 Feb 2019
built on: Wed Apr 17 16:50:04 2019 UTC
platform: debian-amd64
options: bn(64,64) rc4(16x,int) des(int) blowfish(ptr)
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -fdebug-prefix-map=/build/openssl-FmdPCA/openssl-1.1.1b=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2
OPENSSLDIR: "/usr/lib/ssl"
ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1"
Seeding source: os-specific
cli5# cat /proc/version
Linux version 5.0.0-17-generic (buildd@lcy01-amd64-015) (gcc version 8.3.0 (Ubuntu 8.3.0-6ubuntu1)) #18-Ubuntu SMP Tue Jun 4 15:34:08 UTC 2019
cli5#
【问题讨论】：
-
您是否正在键入以 K 或 k 开头的行，或者即使您发布的命令没有显示，也正在重定向或传送此类数据？ OpenSSL 1.1.1 实现了 TLS1.3，因此
s_client有一个新功能可以在输入行以 K 或 k 开头并且连接使用 TLS1.3 时进行密钥更新，这您的连接不是因此错误。这与在连接上选择了哪个密码套件无关，对于任何其他协商的密码套件，您都会收到相同的错误（尽管对于 1.3，唯一存在的密码套件是 AES-GCM、AES-CCM 和 ChaCha-Poly 的变体） . -
@dave_thompson_085 这很有趣。实际上，键入 K 或 k 会更直接地导致错误。但是，我正在管道的数据不包含以“K”或“k”开头的行，并且无论如何它都在尝试执行 KEYUPDATE。
-
@dave_thompson_085。嗯，这很有趣。我正在发送一个 18MB 的文件，其中包含许多行，没有以“K”或“k”开头。但是，如果我在它停止的特定位置删除“k”或“K”（并且“K”或“k”不在行首），那么它似乎可以工作。我想知道为什么那些“K”/“k”很特别...可以关闭“K”/“k”功能以确认这是问题吗？
-
@dave_thompson_085。似乎“p”和“P”也会导致类似的问题。如果我从数据中删除所有“k”、“K”、“p”和“P”，那么我可以双向发送大文件。
-
好的，我检查了代码，它实际上是buffer的开始而不是line。对于用户输入（更容易测试）buffer=line，但对于管道输入通常不是，对于重定向从不。我认为重要的是 8K (8192) 的倍数，但没有去测试。 P 和 p 应该不是特殊的； Q R 或许 B 应该 -- 但也适用于旧版本（回到 0.9.8）； 1.1.1 中只有 K k 应该不同。