Migrating from SSLv3 to TLSv1

和自甴很熟 提交于 2020-01-24 15:15:22

问题


With regards to POODLE, SSLv3 is now disabled on the Server.
The client software was developed in .NET 2.0 and provides TLSv1 as the only alternative. I have access and ability to make changes to both the client application and server configuration.

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls; is used to force all HttpWebRequest.GetResponse() calls to use TLSv1.

And SslStream.AuthenicateAsClient() is used with the argument SslProtocols.Tls to force TLSv1 to be used during Security Certificate retrieval.

The initial issue (described here) is related to receiving a TLS Alert about an Unrecognized name.

Wireshark shows the following during the handshake (AuthenicateAsClient):

TLSv1   182 Client Hello
TLSv1   742 Alert (Level: Warning, Description: Unrecognized Name), Server Hello, Certificate, Server Hello Done

The client throws the following exception on this call:

AuthenticateAsClient: System.IO.IOException: Unable to read data from the transport connection
---> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond

To correct this issue, the apache conf file was modified to include the proper ServerName value.


Now I no longer received the Unrecognized name warning, BUT I am seeing another problem:

Wireshark shows the following during the handshake (AuthenicateAsClient):

SSL 182 Client Hello
TCP 60  443→57062 [RST, ACK] Seq=1 Ack=129 Win=0 Len=0 <--- SHOWN IN RED

The client throws a different exception on this call:

System.IO.IOException: Unable to read data from the transport connection
---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host

Interestingly, Wireshark shows SSL in the Protocol column for the Client Hello -- which I suspect might have something to do with the forcibly closed exception -- BUT, expanding the Secure Sockets Layer section below the frames shown, displays that TLSv1 is used ... this is rather curious, but I can't make sense of it ... perhaps clue with regards to the RST, ACK response?

If I remove the ServerName value from the apache conf, then Wireshark shows TLSv1 for the Client Hello without any changes to the client. Perhaps I am not properly interpreting what Wireshark is displaying to me ...

But, I do see the Reset bit/flag set in that ACK message - which I believe .NET interprets and sends the client the exception - I do not understand why this is happening, hence this question being posted.


I've also attempted setting SSLStrictSNIVHostCheck off within the apache conf file instead of the ServerName change in hopes of disabling SNI altogether:

Wireshark and the client application showed the same errors pertaining to the Unrecognized name issue.

Then I tried setting SSLStrictSNIVHostCheck off AND setting the ServerName properly:

Wireshark and the client application showed the same response pertaining to the forcibly closed errors.


Is there some apache conf setting that can allow this communication without error? ... or if someone can point me in the direction of determining what is causing the RESET flag ...

Or is there some way within the C# client code to refrain from sending the SNI with the handshake (client hello)? ... which is why XP works; it doesn't send the SNI ext at that point.

... so far, the only working alternative that I've found for this is migrating the client to .NET 4.0 --- however, that is not currently feasible for this codebase.

来源:https://stackoverflow.com/questions/27257525/migrating-from-sslv3-to-tlsv1

标签
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!