关闭连接后Java TLS会话重用 [英] Java TLS Session Reuse after closed connection

问题描述

我有一个Java TLS客户端，它可以向服务器发送一系列请求，每个请求后都带有对服务器的响应.

I have a Java TLS client that can send a series of requests to a server, each followed by a response to the server.

但是，有许多不同的服务器.一些是多消息"服务器，在第一个请求之后保持连接打开，以便可以通过第一个连接发送后续请求.其他的是单个消息"服务器，它们在每个消息之后关闭连接，因此后续消息需要一个新的连接.客户端没有先验的方式可以知道要与之通信的服务器类型，也不能修复服务器.

However, there are many different servers. Some are "multi-message" servers that keep a connection open after the first request, so that subsequent requests can be sent over the first connection. Others are "single-message" servers that close the connection after each message and so a new connection is required for subsequent messages. There is no a priori way for the client to know what type of server it is talking to, nor to fix the servers.

非常希望单消息服务能够在没有完整握手的情况下恢复会话.

It is very desirable for single-message serves to be able to resume a session without the full handshake.

我原来的客户端代码只是试图通过相同的连接发送后续请求.如果失败，它将打开与服务器的新连接.因此，它可以同时处理单消息服务器和多消息服务器.

My original client code just tried to send subsequent requests down the same connection. If that failed it just opened a new connection to the server. It could thus handle both single and multi-message servers.

但是，将第二条消息发送到单个消息服务器时失败似乎终止了会话的恢复.

However, the failure when sending the second message to single-message severs seems to kill the session resumption.

我的变通方法是注意到消息是否失败，然后假定它正在与单消息服务器通信，在这种情况下，客户端在收到每个响应后会显式关闭套接字.这样一来，后续的连接即可恢复会话.

My dirty work around is to notice if a message fails and then assume that it is talking to a single-message server, in which case the client then explicitly closes the socket after each response has been received. This enables subsequent connections to resume sessions.

但是必须有更好的方法.毫不奇怪，测试isInputShutdown或isConnected并没有帮助，因为存在计时问题.单消息服务器的连接失败实际上发生在请求写入后的响应读取期间，这大概是由于缓冲造成的.

But there has to be a better way. Testing for isInputShutdown or isConnected does not help, unsurprisingly, as there are timing issues. The connection failure for single-message server actually happens during the read of the response, after the write of the request, presumably due to buffering.

有什么想法值得赞赏吗?

Any ideas much appreciated?

推荐答案

对于纯文本，您的初始解决方案是正确的:发送第二条消息时，您将得到 IOException:对等方重置连接，然后只需重新连接即可恢复.

Your initial solution is correct in the case of plaintext: you will get an IOException: connection reset by peer when sending the second message, and you can just recover accordingly by reconnecting.

但是在TLS情况下它将无法正常工作，因为由于致命的TLS IOException:连接被同级重置，而是被重置为 SocketException > unexpected_message 警报. RFC 2246#7.2 状态:

However in the TLS case it won't work, as you will not get IOException: connection reset by peer but a SocketException, due to a fatal TLS unexpected_message alert. RFC 2246 #7.2 states:

具有致命结果级别的警报消息立即终止连接.在这种情况下，其他与该会话相对应的连接可能会继续，但是会话标识符必须无效，以防止会话失败用来建立新的连接.

Alert messages with a level of fatal result in the immediate termination of the connection. In this case, other connections corresponding to the session may continue, but the session identifier must be invalidated, preventing the failed session from being used to establish new connections.

[我的重点]，因为失败的会话现在被认为是不安全的，并且

[my emphasis], because the failed session is now deemed insecure, and

unexpected_message

unexpected_message

收到不适当的消息.此警报始终是致命的绝对不能在正常人与人之间的交流中观察到实施.

An inappropriate message was received. This alert is always fatal and should never be observed in communication between proper implementations.

您的第二个解决方案似乎对我来说合适.

Your second solution seems appropriate to me.

NB:

• isInputShutdown()永远不能为真，因为您无法在SSLSocket上调用 shutdownInput().
连接套接字后，
• isConnected()永远不会为假.
• 两者都告诉您套接字的状态，而不是连接的状态，因此即使尝试使用它们也是徒劳的.它与时间问题"无关.

• isInputShutdown() can never be true, as you can't call shutdownInput() on an SSLSocket.
• isConnected() will never be false once the socket has been connected.
• Both tell you about the state of your socket, not of the connection, so even trying them was futile. And it has nothing to do with 'timing issues'.

这篇关于关闭连接后Java TLS会话重用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！