OpenSSL连接:警告内部错误 [英] OpenSSL connection: alert internal error

查看:1537
本文介绍了OpenSSL连接:警告内部错误的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我使用SNI在单个服务器上运行100个HTTPS服务. (实际上,我无法访问它们.这是一个分配.我所知道的是它们的域名N.xxx.yy,其中N的范围是00到99.)分配的目的是评估每个连接的安全性这些服务器中的每一个.因此,某些服务器包含过期的证书,具有错误CN的证书等.

I have 100 HTTPS services running on a single server using SNI. (Actually, I don't have access to them. It's an assignment. All I know are their domain names N.xxx.yy where N is in range from 00 to 99.) The goal of the assignment is to evaluate security of every single connection to each of these servers. So some of the servers contain expired certificates, certificates with wrong CN, etc.

我的问题是我无法摆脱某些服务器上的握手.我已经使用OpenSSL在C ++中编写了自己的应用程序,但是我也尝试了使用openssl s_client的方法.这是我连接到服务器的方式:

My problem is that I cannot get past the handshake on some of the servers. I have written my own application in C++ using OpenSSL, but I've also tried it with openssl s_client. This is how I connect to the server:

openssl s_client -host N.xxx.yy -port 443 -verify 1 -servername N.xxx.yy -CAfile assignment-ca.pem

这就是我得到的:

139625941858168:error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error:s3_pkt.c:1493:SSL alert number 80
139625941858168:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:

在Wireshark中,我看到客户端发送了ClientHello,服务器响应了ServerHello(选择TLSv1.2和ECDHE-RSA-AES256-GCM-SHA384),随后是Certificate,然后它向我发送了包含Internal Error (80)Alert消息.

In Wireshark, I see that client sent ClientHello, server responded with ServerHello (choosing TLSv1.2 and ECDHE-RSA-AES256-GCM-SHA384) followed by Certificate and then it sent me Alert message containing Internal Error (80).

尝试了不同的操作后,我发现如果我将s_client-tls1-tls1_1一起运行,则可以成功克服握手. -tls1_2不起作用.更奇怪的是,即使协商了TLSv1.2,通过Chrome/Firefox/任何其他浏览器的连接也会成功.从我看来,Chrome发送的密码列表与我或s_client不同,但是即使修改了密码列表以匹配Chrome中的密码列表(并确保服务器选择了ECDHE-RSA-AES128-GCM-SHA256),它也无法正常工作. Chrome正在发送这些TLS扩展程序,我没有,但其中大多数似乎是空的:

After trying different thing I have found out that if I run s_client with -tls1 or -tls1_1 I can successfully get past the handshake. -tls1_2 does not work. What is even stranger is that connection through Chrome/Firefox/any other browser succeeds even if TLSv1.2 is negotiated. From what I see, Chrome is sending a different cipher list than me or s_client but even after modifying the cipher list to match the one in Chrome (and making sure that server chooses ECDHE-RSA-AES128-GCM-SHA256), it does not work either. Chrome is sending these TLS extensions, which I don't but most of them seem empty:

Unknown 47802
renegotiation_info
Extended Master Secret
signed_certificate_timestamp
status_request
Application Layer Protocol Negotiation
channel_id
Unknown 6682

有人可以解释一下这里发生了什么吗?不幸的是,我无法在服务器端对其进行调试,所以这就是我所知道的.

Can anybody explain me what is happening here? Unfortunately, I have no way to debug it on the server side so this is all I know.

更新:

在处理伪造的ClientHello消息后,我设法将其跟踪到signature_algorithms扩展名.我的应用程序和s_client提供了SHA384 + {RSA,DSA,ECDSA},但是如果我删除了它们并仅保留SHA256 + {RSA,DSA,ECDSA},就像Chrome一样,它可以正常工作,并且我成功接收到Server Key Exchange消息.可能是服务器以某种方式不支持它,但是它没有提供有意义的错误消息,而是意外终止并给了我这个内部错误?

After playing around with forged ClientHello messages I managed to track it down to signature_algorithms extension. My app and s_client provide SHA384 + {RSA,DSA,ECDSA} but if I remove these and keep just SHA256 + {RSA,DSA,ECDSA}, as Chrome does, it works and I receive Server Key Exchange message successfully. Could it be that server somehow does not support it, but instead of providing meaningful error message, it just ends unexpectedly and gives me this internal error?

更新2:

在RFC5246中找到了为什么它可用于1.2之前的TLS版本的答案.以前的UPDATE中的问题仍然成立.

I found answer to why it works with TLS versions prior to 1.2 in RFC5246. Question from the previous UPDATE still holds.

Note: this extension is not meaningful for TLS versions prior to 1.2.
   Clients MUST NOT offer it if they are offering prior versions.
   However, even if clients do offer it, the rules specified in [TLSEXT]
   require servers to ignore extensions they do not understand.

推荐答案

自从您写了-tls1_2 does not work以来,我假设您和/或服务器使用的是较旧的openssl库.撰写本文时的当前版本是1.1.0e

Since you wrote that -tls1_2 does not work I assume either you and/or the server uses an older openssl library. The current version while writing this is 1.1.0e

自0.9.8以来,已经有很多修复程序,这些修复程序通常可以在较旧的系统上看到.

There were quite some fixes since 0.9.8, which could often be seen on older systems.

对于版本1.0.1 ,存在此修复程序,听起来像您的问题:

For Version 1.0.1 there was this fix, which sounds like your problem:

 `Some servers which support TLS 1.0 can choke if we initially indicate
 support for TLS 1.2 and later renegotiate using TLS 1.0 in the RSA
 encrypted premaster secret. As a workaround use the maximum permitted
 client version in client hello, this should keep such servers happy
 and still work with previous versions of OpenSSL.`

也许也是值得注意的:

Don't allow TLS 1.2 SHA-256 ciphersuites in TLS 1.0, 1.1 connections.

所以我建议更新您的openssl-Version,如果服务器失控,我会坚持使用已经找到的设置.

So I would suggest to update your openssl-Version and in case of the servers out of your control I would stick to the settings you already found.

这篇关于OpenSSL连接:警告内部错误的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆