httpstat
httpstat copied to clipboard
SSL/TLS Handshake Latency
It would be really good to have the SSL/TLS handshake latency.
@vanbroup what is missing at the moment? Please be specific.
The SSL/TLS Handshake Latency is measured from the ClientHello message that comes after the TCP ACK until the Finished message which is sent immediately after a change cipher spec message to verify that the key exchange and authentication processes were successful.
RFC5246 Section 7.4.9 Finished states:
The Finished message is the first one protected with the just negotiated algorithms, keys, and secrets. Recipients of Finished messages MUST verify that the contents are correct. Once a side has sent its Finished message and received and validated the Finished message from its peer, it may begin to send and receive application data over the connection.
This allows a client to measure the delay caused by the SSL/TLS Handshake as also implemented by httpstat.py and highlighted in this example:
@vanbroup how is it different from the current one (TLS Handshake)?
@juanpaulo thanks, I just tested and it's indeed already there!
I was mainly interested in the handshake part and the screenshot in the readme doesn't include the change from pull request #25, also http/httptrace doesn't expose any TLS information (until go 1.8) so I did not even try to run it honestly speaking.
Maybe it's smart to update the screenshot in README.md to relect the implementation of the SSL/TLS Handshake Latency.
Since we moved to the httptrace framework we can only do things that it knows how to do.
There is a PR pending the release of go 1.8 that may help.
On 23 Oct. 2016, at 20:39, Paul van Brouwershaven [email protected] wrote:
The SSL/TLS Handshake Latency is measured from the ClientHello message that comes after the TCP ACK until the Finished message which is sent immediately after a change cipher spec message to verify that the key exchange and authentication processes were successful.
RFC5246 Section 7.4.9 Finished states:
The Finished message is the first one protected with the just negotiated algorithms, keys, and secrets. Recipients of Finished messages MUST verify that the contents are correct. Once a side has sent its Finished message and received and validated the Finished message from its peer, it may begin to send and receive application data over the connection.
This allows a client to measure the delay caused by the SSL/TLS Handshake as also implemented by httpstat.py and highlighted in this example:
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
I was mainly interested in the handshake part and the screenshot in the readme doesn't include the change from pull request #25 https://github.com/davecheney/httpstat/pull/25,
I'm pretty sure it does, that screenshot was taken with 1.0 version of httpstat.
If this is incorrect, it is a bug and should be fixed.
On Tue, Oct 25, 2016 at 6:03 PM, Paul van Brouwershaven < [email protected]> wrote:
@juanpaulo https://github.com/juanpaulo thanks, I just tested and it's indeed already there!
I was mainly interested in the handshake part and the screenshot in the readme doesn't include the change from pull request #25 https://github.com/davecheney/httpstat/pull/25, also http/httptrace doesn't expose any TLS information (until go 1.8) so I did not even try to run it honestly speaking.
Maybe it's smart to update the screenshot in README.md to relect the implementation of the SSL/TLS Handshake Latency.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/davecheney/httpstat/issues/113#issuecomment-255953751, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAcA9MQhq9tyU2ExVKPNVqFuXyUx-osks5q3am0gaJpZM4KP5Xq .
@davecheney, I think his point was that the screenshot should be of a TLS request.
Oh, that's my mistake. When I made the announcement I used the github page for this project.
If someone wants to update the screenshot with something more exciting, please send a PR.
@davecheney I hope #115 is exciting enough. Had to use a different URL since dave.cheney.net doesn't seem to have an SSL endpoint.
That'll do, I was just using my own site as a demo, anything that offers https will do.
On Wed, Oct 26, 2016 at 2:15 PM, Juan Paulo Gutierrez < [email protected]> wrote:
@davecheney https://github.com/davecheney I hope #115 https://github.com/davecheney/httpstat/pull/115 is exciting enough. Had to use a different one since dave.cheney.net doesn't seem to have an SSL endpoint.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/davecheney/httpstat/issues/113#issuecomment-256239027, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAcAxJfWyu-DFQBlO_ZURmMpzOTinkHks5q3sXBgaJpZM4KP5Xq .
nice, so I think this issue should be marked as resolved right?
No, we're waiting on Go 1.8 release to get this enhancement.
Ping. Go was released.
Can be closed?