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

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

[ch3lo]

nice, so I think this issue should be marked as resolved right?

[moorereason]

No, we're waiting on Go 1.8 release to get this enhancement.

[janisz]

Ping. Go was released.

[cristaloleg]

Can be closed?