SSL/TLS Handshake Latency

[vanbroup]

It would be really good to have the SSL/TLS handshake latency.

[davecheney]

@vanbroup what is missing at the moment? Please be specific.

[vanbroup]

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:

[juanpaulo]

@vanbroup how is it different from the current one (TLS Handshake)?

[vanbroup]

@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.

[davecheney]

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 notifications@github.com 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.

[davecheney]

I was mainly interested in the handshake part and the screenshot in the
readme doesn't include the change from pull request #25
#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 <
notifications@github.com> 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
#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
#113 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAcA9MQhq9tyU2ExVKPNVqFuXyUx-osks5q3am0gaJpZM4KP5Xq
.

[moorereason]

@davecheney, I think his point was that the screenshot should be of a TLS request.

[davecheney]

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.

[juanpaulo]

@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.

[davecheney]

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 <
notifications@github.com> wrote:

@davecheney https://github.com/davecheney I hope #115
#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
#113 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAcAxJfWyu-DFQBlO_ZURmMpzOTinkHks5q3sXBgaJpZM4KP5Xq
.