24,924
社区成员
发帖
与我相关
我的任务
分享wireshark抓包分析https握手过程 serverhello中的session ID 变化时机
服务器：windows 2008 r2，tomcat 7
测试页面：jsp
过程：打开wireshark开始抓包，过滤ssl，谷歌浏览器输入https网址，wireshark中能观察到https链接建立的握手过程，浏览器发送client hello 后，在服务器返回的server hello中，如下：
之后刷新网页，服务器返回的server hello，如下：
少了发送证书后面的一些信息，其中server hello中的session ID的值相同。
百度了一下，当客户端想要恢复以前的会话时流程如下，不是进行完整的秘钥协商过程的。
Client Server
ClientHello -------->
ServerHello
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
之后我间隔10分钟、20分钟、30分钟刷新网页，发现30分钟之后，服务器又会发送证书等信息了，此时server hello中的session ID的值与之前不同。
疑问：刷新https网页是否进行完整的秘钥协商过程是由谁决定的（服务器、客户端）？这个时限又是由谁决定的？如何配置？
求大神解惑。
测试页面：jsp
过程：打开wireshark开始抓包，过滤ssl，谷歌浏览器输入https网址，wireshark中能观察到https链接建立的握手过程，浏览器发送client hello 后，在服务器返回的server hello中，如下：
之后刷新网页，服务器返回的server hello，如下：
少了发送证书后面的一些信息，其中server hello中的session ID的值相同。
百度了一下，当客户端想要恢复以前的会话时流程如下，不是进行完整的秘钥协商过程的。
Client Server
ClientHello -------->
ServerHello
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
之后我间隔10分钟、20分钟、30分钟刷新网页，发现30分钟之后，服务器又会发送证书等信息了，此时server hello中的session ID的值与之前不同。
疑问：刷新https网页是否进行完整的秘钥协商过程是由谁决定的（服务器、客户端）？这个时限又是由谁决定的？如何配置？
求大神解惑。
...全文
请发表友善的回复…
发表回复
duanbai 2016-04-14
- 打赏
- 举报
关键字：
1、session resume
2、session cache
3、tomcat sessionTimeout
刷新https网页是否进行完整的秘钥协商过程是由服务器决定。
这个时限由服务器决定。
如何配置：sessionTimeout
Theory of operation
To establish a SSL connection, four messages need to be exchanged between client and server. With a latency of 50 ms, we have a 200 ms overhead to establish the connection (plus TCP handshake). Moreover, to share a common secret, both the client and the server needs to achieve some public-key cryptographic operations which are costly, computation-wise.
To avoid a full SSL handshake each time a client request a resource, it is possible for the client to request an abbreviated handshake, saving a complete round-trip (100 ms) and avoiding the costliest part of the full SSL handshake.
Two mechanisms can be used to accomplish an abbreviated handshake:
When the server sends the “Server Hello” message, it can include a session identifier. The client should store it and present it in the “Client Hello” message of the next session. If the server finds the corresponding session in its cache and accepts to resume the session, it will send back the same session identifier and will continue with the abbreviated SSL handshake. Otherwise, it will issue a new session identifier and switch to a full handshake. This mechanism is detailed in RFC 5246. It is the most common mechanism because it exists since earlier versions of SSL.
In the last exchange of a full SSL handshake, the server can include a “New Session Ticket” message (not represented in the handshake described in the picture) which will contain the complete session state (including the master secret negotiated between the client and the server and the cipher suite used). Therefore, this state is encrypted and integrity-protected by a key known only by the server. This opaque datum is known as a session ticket. The details lie in RFC 5077 which supersedes RFC 4507.
The ticket mechanism is a TLS extension. The client can advertise its support by sending an empty “Session Ticket” extension in the “Client Hello” message. The server will answer with an empty “Session Ticket” extension in its “Server Hello” message if it supports it. If one of them does not support this extension, they can fallback to the session identifier mechanism built into SSL.
RFC 5077 identifies situations where tickets are desirable over session identifiers. The main improvement is to avoid to maintain a server-side session cache since the whole session state is remembered by the client, not the server. A session cache can be costly in term of memory and difficult to share between multiple hosts when requests are load-balanced across servers.
1、session resume
2、session cache
3、tomcat sessionTimeout
刷新https网页是否进行完整的秘钥协商过程是由服务器决定。
这个时限由服务器决定。
如何配置：sessionTimeout
Theory of operation
To establish a SSL connection, four messages need to be exchanged between client and server. With a latency of 50 ms, we have a 200 ms overhead to establish the connection (plus TCP handshake). Moreover, to share a common secret, both the client and the server needs to achieve some public-key cryptographic operations which are costly, computation-wise.
To avoid a full SSL handshake each time a client request a resource, it is possible for the client to request an abbreviated handshake, saving a complete round-trip (100 ms) and avoiding the costliest part of the full SSL handshake.
Two mechanisms can be used to accomplish an abbreviated handshake:
When the server sends the “Server Hello” message, it can include a session identifier. The client should store it and present it in the “Client Hello” message of the next session. If the server finds the corresponding session in its cache and accepts to resume the session, it will send back the same session identifier and will continue with the abbreviated SSL handshake. Otherwise, it will issue a new session identifier and switch to a full handshake. This mechanism is detailed in RFC 5246. It is the most common mechanism because it exists since earlier versions of SSL.
In the last exchange of a full SSL handshake, the server can include a “New Session Ticket” message (not represented in the handshake described in the picture) which will contain the complete session state (including the master secret negotiated between the client and the server and the cipher suite used). Therefore, this state is encrypted and integrity-protected by a key known only by the server. This opaque datum is known as a session ticket. The details lie in RFC 5077 which supersedes RFC 4507.
The ticket mechanism is a TLS extension. The client can advertise its support by sending an empty “Session Ticket” extension in the “Client Hello” message. The server will answer with an empty “Session Ticket” extension in its “Server Hello” message if it supports it. If one of them does not support this extension, they can fallback to the session identifier mechanism built into SSL.
RFC 5077 identifies situations where tickets are desirable over session identifiers. The main improvement is to avoid to maintain a server-side session cache since the whole session state is remembered by the client, not the server. A session cache can be costly in term of memory and difficult to share between multiple hosts when requests are load-balanced across servers.
