stunnel 无法使用 TLSv1.2 连接到服务器

stunnel 无法使用 TLSv1.2 连接到服务器

我正在尝试从我的 Centos7 服务器连接到客户,

客户运行的是Stunnel服务器,而我是客户端。

我无法建立握手,并在 /var/log/messages 中收到以下错误消息,表示握手失败

Jan 27 12:49:24 qbtch2 stunnel: LOG6[25]: SNI: sending servername: 123.111.172.34
Jan 27 12:49:24 qbtch2 stunnel: LOG6[25]: Peer certificate not required
Jan 27 12:49:24 qbtch2 stunnel: LOG3[25]: SSL_connect: s23_clnt.c:769: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
Jan 27 12:49:24 qbtch2 stunnel: LOG5[25]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket

我的 openssl 版本

root@qbtch2 /e/stunnel# rpm -qa | grep openssl
openssl-libs-1.0.2k-12.el7.i686
openssl098e-0.9.8e-29.el7.centos.3.x86_64
openssl-1.0.2k-12.el7.x86_64
openssl-devel-1.0.2k-12.el7.x86_64
openssl-libs-1.0.2k-12.el7.x86_64

我的 Stunnel 版本,

root@qbtch2 /e/stunnel# rpm -qa | grep stunnel
stunnel-5.54-1.el7.x86_64

我的 stunnel 配置如下所示,我使用客户的密钥和证书进行连接(客户端模式)

root@qbtch2 /e/stunnel# cat stunnel.conf 
debug = 7
foreground = no
chroot = /var/run/stunnel
setuid = nobody
setgid = nobody
pid = /stunnel.pid
ciphers = PSK
PSKsecrets = /etc/stunnel/psk.txt
socket = l:SO_KEEPALIVE=1
socket = r:SO_KEEPALIVE=1

[ ABC ]
client = yes
accept = 127.0.0.1:8228
connect = 123.111.172.34:8228
cert = /etc/stunnel/certs/customerABC/uat/cert.pem
key = /etc/stunnel/certs/customerABC/uat/key.pem
CAfile = /etc/stunnel/certs/customerABC/uat/CACerts.pem
verifyChain = yes
checkHost = 123.111.172.34
sslVersion = TLSv1.2
options = NO_SSLv2
options = NO_SSLv3


我可以使用 openssl s_connect 连接到客户并进行握手,

root@qbtch2 /e/stunnel# openssl s_client -connect 123.111.172.34:8228 -cert certs/customerABC/uat/cert.pem -key certs/customerABC/uat/key.pem -tls1_2

我得到了这个作为回报,

root@qbtch2 /e/stunnel# openssl s_client -connect 112.13.172.34:8228 -cert certs/CustomerABC/uat/cert.pem -key certs/CustomerABC/uat/key.pem 
CONNECTED(00000003)
depth=2 C = US, ST = NEW YORK, L = NEW YORK, O = CustomerABC LP, OU = R&D, CN = System Security Root CA, emailAddress = [email protected]
verify error:num=19:self signed certificate in certificate chain
---
Certificate chain
 0 s:/C=US/ST=New York/O=CustomerABC L.P./OU=Test/CN=Testbeta.CustomerABC.com
   i:/C=US/ST=NEW YORK/L=NEW YORK/O=CustomerABC LP/OU=Test/CN=Test Connectivity
 1 s:/C=US/ST=NEW YORK/L=NEW YORK/O=CustomerABC LP/OU=Test/CN=Test Connectivity
   i:/C=US/ST=NEW YORK/L=NEW YORK/O=CustomerABC LP/OU=R&D/CN=System Security Root CA/[email protected]
 2 s:/C=US/ST=NEW YORK/L=NEW YORK/O=CustomerABC LP/OU=R&D/CN=System Security Root CA/[email protected]
   i:/C=US/ST=NEW YORK/L=NEW YORK/O=CustomerABC LP/OU=R&D/CN=System Security Root CA/[email protected]
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFpzCCA4+gAwIBAgIQc9qYG4Sl83koJYfu5YBKXjANBgkqhkiG9w0BAQsFADBz
MQswCQYDVQQGEwJVUzERMA8GA1UECBMITkVXIFlPUksxETAPBgNVBAcTCE5FVyBZ
T1JLMRUwEwYDVQQKEwxCbG9vbWJlcmcgTFAxDDAKBgNVBAsTA0ZJWDEZMBcGA1UE
AxMQRklYIENvbm5lY3Rpdml0eTAeFw0xOTA1MTUxNjQyNDJaFw0yMDAyMDkxNjQy
NDJaMGcxCzAJBgNVBAYTAlVTMREwDwYDVQQIDAhOZXcgWW9yazEXMBUGA1UECgwO
Qmxvb21iZXJnIEwuUC4xDDAKBgNVBAsMA0ZJWDEeMBwGA1UEAwwVZml4YmV0YS5i
bG9vbWJlcmcuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA26dq
JLQ9P8lHDRQYi4XoNcM8DXijx/A0L7mNFxLwoFxrl2Y67tjrZRVINcbZdrMP/m/R
2o5vR8USHKRT7HWEwJwdQ3MN829IMngXhhiNK/zps3Xnyw4luvXs53E1YgqgH/du
INXe8TPOzQxCU79jPIxtIYkXHMJ5KdhODxxHV2bZke8r9RzgFNO2fCGm/67dZFYR
X90+b+p4UlOe5QQp1/0hGdBbQhG3lZn+rPMgSIK8rPU0yAMUI9bqqEMNshFof1PQ
o7V8X2ewXLSM6E4NG3+ZCzlr1iUCAuX7C8n28DBV4weFWlhXJvT3Zfkxexfm3YWd
94Z9C4MWoq/sB5GKKwIDAQABo4IBQTCCAT0wCQYDVR0TBAIwADALBgNVHQ8EBAMC
BaAwHQYDVR0lBBYwFAYIKwYBB75UHAwEGCCsGAQUFBwMCMIIBAgYDVR0RBIH6MIH3
ghVmaXhiZXRhLmJsb29tYmVyZy5jb22CGWZpeGJldGEtYWltLmJsb29tYmVyZy5j
b22CGmZpeGJldGEtdG9tcy5ibG9vbWJlcmcuY29tghpmaXhiZXRhLWRhc2guYmxv
b21iZXJnLmNvbYIcZml4YmV0YS1zc2VvbXMuYmxvb21iZXJnLmNvbYIYZml4YmV0
YS10Yi5ibG9vbWJlcmcuY29tg9pmaXhiZXRhLWZpY2MuYmxvb21iZXJnLmNvbYIa
Zml4YmV0YS1lbXN4LmJsb29tYmVyZy5jb22CG2ZpeGJldGEtZXRvbXMuYmxvb21i
ZXJnLmNvbTANBgkqhkiG9w0BAQsFAAOCAgEAPm78N260OC3cmgSSQrcq2m3rd3NM
IGSrUaMDI7YxmBgtJsS0rwKIBaWwYuS0f6SrDWP5ILGHf7q2QwxVS01sSA/ilu9c
7+U3Srv8OQlNyP0+gwv+D1rabcfUulNsVSJy0B3gL8VfkBNqWECucNRbgv77/CR
6fSevWW2gsnGpRFQ1m9cr9h0hN/ssbaBTYD9MNlgoapQBgEXie/GoHqYxW0Pk+I6
0Jbj0dCacmpbeFYtFe2lWavnDUIpUozYQsi64XHg6m8uWokQPPmA/BOBfGh3sUgw
B5kkblXTgTt/lXpqG8GXBHAbxeJhtsNymvcJH1HOrL9FghOEJ9DUPCDqh821VWGC
WOScaJ18SbbxhBomG3BOrXvViOPUIG1oCJ22ch6J+u5TGA2OHtUSqxBnkaKETVxn
JYDUqNqoFoVeuxR/YYNTdo2LPer5Wb2YZ9OD/Hp9zERI85miW+w+Us7gF62JYnI/
ZfC2WdHcqBqZjfy+HXGGA5PMDX8SqacRXmpZsHmPHjUlWO/HLmY2icHs90IVOI3L
zntyG7J6Z6iN4TcZdEtXW/G73oX38T7IuYAPX7YDVvsTmNPMAz8r56L9ItQ4RzMs
5Y3jNN3iud+gudsc8ldSzWbW3Tdivc1xI9nLPxGzw3tAM+f5hXxKAzFc36J13L//
BZDdv9LU66xDLjQ=
-----END CERTIFICATE-----
subject=/C=US/ST=New York/O=CustomerABC L.P./OU=Test/CN=Testbeta.CustomerABC.com
issuer=/C=US/ST=NEW YORK/L=NEW YORK/O=CustomerABC LP/OU=Test/CN=Test Connectivity
---
Acceptable client certificate CA names
/C=US/ST=NEW YORK/L=NEW YORK/O=CustomerABC LP/OU=R&D/CN=System Security Root CA/[email protected]
/C=US/ST=NEW YORK/L=NEW YORK/O=CustomerABC LP/OU=Test/CN=Test Connectivity
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 5634 bytes and written 2041 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: B34275808CDxxx3A5ED9AB49F14023B17E32A1A33B5A5B5D2DE96A419491A93201CF247A94BA2119801437CDA3D00B4122
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1580150434
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---

因此握手是存在的,但是当我尝试启动 Stunnel 时却不存在。

有任何线索可以解决这个问题吗?

谢谢。

答案1

问题似乎是,我对其他 stunnel 连接有一个全局 PSK 设置,将 PSK 放入本地配置似乎可以解决这个问题,

也就是说,

root@qbtch2 /e/stunnel# cat stunnel.conf 
debug = 7
foreground = no
chroot = /var/run/stunnel
setuid = nobody
setgid = nobody
pid = /stunnel.pid
ciphers = PSK
PSKsecrets = /etc/stunnel/psk.txt
socket = l:SO_KEEPALIVE=1
socket = r:SO_KEEPALIVE=1

[ SOME PSK CONN ]
accept = 1234
connect = blah:1234

[ ABC ]
client = yes
accept = 127.0.0.1:8228
connect = 123.111.172.34:8228
cert = /etc/stunnel/certs/customerABC/uat/cert.pem
key = /etc/stunnel/certs/customerABC/uat/key.pem
CAfile = /etc/stunnel/certs/customerABC/uat/CACerts.pem
verifyChain = yes
checkHost = 123.111.172.34
sslVersion = TLSv1.2
options = NO_SSLv2
options = NO_SSLv3

对此,

root@qbtch2 /e/stunnel# cat stunnel.conf 
debug = 7
foreground = no
chroot = /var/run/stunnel
setuid = nobody
setgid = nobody
pid = /stunnel.pid

socket = l:SO_KEEPALIVE=1
socket = r:SO_KEEPALIVE=1

[ SOME PSK CONN ]
accept = 1234
connect = blah:1234
ciphers = PSK
PSKsecrets = /etc/stunnel/psk.txt

[ ABC ]
client = yes
accept = 127.0.0.1:8228
connect = 123.111.172.34:8228
cert = /etc/stunnel/certs/customerABC/uat/cert.pem
key = /etc/stunnel/certs/customerABC/uat/key.pem
CAfile = /etc/stunnel/certs/customerABC/uat/CACerts.pem
verifyChain = no
checkHost = 123.111.172.34
sslVersion = TLSv1.2
options = NO_SSLv2
options = NO_SSLv3

将 PSK 设置移至本地配置而不是全局配置可解决此问题。此外,我必须禁用“verifyChain”才能消除握手错误消息

相关内容