SSL handshake speed

[jamesbiv]

Hi GoogleChrome!

I'm only assuming at this point since I haven't really put too much time into this as perhaps this steps outside of Lighthouses' scope. However, I've noticed that the audits don't mention too much about SSL handshake speed.

After reviewing various methods which are out there to improve the handshake speed such as; Enterprise SSL use; strict host resolution; the use of SSL stapling and caching; and so on.

What I am finding is that my test results come in good overall but since I test under real 2G environments the handshake is the biggest part of the process which slows everything up. I was wondering what are peoples thoughts on this?

Regards

James

[patrickhulce]

Thanks for filing @offyourleash! This is a great idea for new audits and something we want to more accurately reflect in our performance simulations as well.

The primary trouble is that the SSL handshake details are frequently opaque to Lighthouse in many of our environments since it's handled at a much lower level. There are some extra manual checks we could try for each server, compare the ping time to SSL timing if we have it, etc, but those would also be very time consuming to do for all origins.

If you have ideas of how to easily detect suboptimal SSL server settings, your contributions would be very much appreciated :)

[jamesbiv]

Hi Patrick.

I just tested OCSP on 2G and it did seem to make a notable change. There are drawbacks to OCSP such as the fact that it sends a request to the CA, which impacts privacy. But the way to test for OSCP and other types of SSL configuration constraints can be done via OpenSSL.

echo QUIT | openssl s_client -connect www.siteaddress.com:443 -status

From there its a matter of regexing the constraints.

[patrickhulce]

Thanks for the info! Unfortunately it's things like this that we can't really afford to do :/ We would have to be able to detect the presence of these features based on our existing network record information without opening a new connection to each origin.

[justinribeiro]

Wondering if it's worth working with what we do have to possibly gen some useful TLS / connection "best practices"? For instance, we could have some understanding of things like HSTS and CSP based on the response headers, we could look at connection reuse and transport type, all of which contribute to some extent to TLS handshake performance (though not exhaustive).

The problem is that bigger gains are almost always going to be on things we just can't see (as you've noted @patrickhulce), everything from termination distance to record size. That, and offering recommendations on TLS is tough as a whole; saying "you should use HSTS" isn't to be taken lightly on the implementer side given potential repercussions if misconfigured.

Would be nice-to-have something, but I worry if the lack of completeness would hamper such an effort. :man_shrugging:

[patrickhulce]

Yeah great points @justinribeiro! I'd also be hesitant to just start throwing HSTS on folks.

My current thinking for our best bet is get more accurate estimated server RTT, use that to estimate how many RTs the SSL handshake took, and if it seems too big, point folks to a collected SSL doc of best practices ala isTLSfastyet.

[jamesbiv]

@patrickhulce - I have noticed this. It's far from perfect as proxies and other things may influence it but have a look at https://www.w3.org/TR/resource-timing/#dom-performanceresourcetiming

On getting, the connectEnd attribute must return as follows ... ... The returned time must include the time interval to establish the transport connection, as well as other time intervals such as SSL handshake and SOCKS authentication.

So by typing performance.getEntriesByType("resource") you receive that info in the console for all objects associated to that page (I'm assuming).

I haven't spent anytime with it too see if i can pull meaningful numbers from it. However, one way i was going to test it was enable and disable SSL and benchmark HTTP vs HTTPS also disable and enable KeepAlive and see what happens.

Regards

James

[staabm]

I am stumbling over this again.

I think it would be great to at least provide some tips on how ssl performance could be improved when detected if slow. As an MVP I think it would even be ok when tipps are suggested which are already implemented... its better then not making people aware of their problems.

Ssl handshake plays a major part of TTFB performance and therefore should be a top priority

[paulirish]

This seems cool. We think there might be some data in chrome://net-export/ that probably gives some signals about the TLS handshake and round trips.

We'd love if someone wants to try out a prototype of parsing the netlog and determining these issues.

[bolu-tife]

Hi @paulirish , I'd like to have a take on this issue. Are the requirements still up-to-date?

[bolu-tife]

@paulirish I looked into the chrome://net-export/ output and the NetLog JSON does expose useful signals for parsing TLS-related metrics.

I was able to extract some information

• TLS Handshake Time: This can be estimated by subtracting the timestamps of SSL_CONNECT (type 60) events — phase: 2 minus phase: 1.

  Example:

  { "type": 60, "phase": 1, "time": 140022940 }
  { "type": 60, "phase": 2, "time": 140022967 }
  

  → Handshake time = 27

• TCP Connection Time: From the TCP_CONNECT timestamp difference.

• We can count the ssl handshake messages sent and received ,TLS version, certificate details, and other useful timing data.

The file records the following types and events for

      "SSL_ALERT_RECEIVED": 70,
      "SSL_ALERT_SENT": 71,
      "SSL_CERTIFICATES_RECEIVED": 84,
      "SSL_CLIENT_CERT_PROVIDED": 65,
      "SSL_CLIENT_CERT_REQUESTED": 63,
      "SSL_CONFIRM_HANDSHAKE": 72,
      "SSL_CONNECT": 60,
      "SSL_CONNECT_JOB_CONNECT": 99,
      "SSL_CONNECT_JOB_RESTART_WITH_ECH_CONFIG_LIST": 102,
      "SSL_CONNECT_JOB_SSL_CONNECT": 105,
      "SSL_ECH_CONFIG_LIST": 61,
      "SSL_ENCRYPTED_CLIENT_HELLO": 75,
      "SSL_HANDSHAKE_EARLY_DATA_REASON": 76,
      "SSL_HANDSHAKE_ERROR": 66,
      "SSL_HANDSHAKE_MESSAGE_RECEIVED": 73,
      "SSL_HANDSHAKE_MESSAGE_SENT": 74,
      "SSL_PRIVATE_KEY_OP": 64,
      "SSL_READ_ERROR": 67,
      "SSL_SERVER_HANDSHAKE": 62,
      "SSL_SOCKET_BYTES_RECEIVED": 80,
      "SSL_SOCKET_BYTES_SENT": 78,
      "SSL_VERIFICATION_MERGED": 69,
      "SSL_WRITE_ERROR": 68,
      "TLS_STREAM_ATTEMPT_WAIT_FOR_SSL_CONFIG": 121,
      "TRANSPORT_SECURITY_STATE_SHOULD_UPGRADE_TO_SSL": 586,
      "URL_REQUEST_DELEGATE_SSL_CERTIFICATE_ERROR": 132,
      "SSL_CONNECT_JOB": 5,
      "DNS_TRANSACTION_TCP_ATTEMPT": 452,
      "HTTP_STREAM_POOL_ATTEMPT_MANAGER_TCP_BASED_ATTEMPT_DELAY_PASSED": 209,
      "HTTP_STREAM_POOL_ATTEMPT_MANAGER_TCP_BASED_ATTEMPT_END": 203,
      "HTTP_STREAM_POOL_ATTEMPT_MANAGER_TCP_BASED_ATTEMPT_START": 202,
     "TCP_ACCEPT": 49,
      "TCP_BASED_ATTEMPT_BOUND_TO_POOL": 117,
      "TCP_CLIENT_SOCKET_POOL_REQUESTED_SOCKET": 110,
      "TCP_CLIENT_SOCKET_POOL_REQUESTED_SOCKETS": 111,
      "TCP_CONNECT": 47,
      "TCP_CONNECT_ATTEMPT": 48,
      "TCP_STREAM_ATTEMPT_ALIVE": 118,
      "TCP_STREAM_ATTEMPT_CONNECT": 119,
      "TCP_STREAM_ATTEMPT": 7,

sample event

 {
    "phase": 1,
    "source": {
      "id": 39339,
      "start_time": "140022925",
      "type": 9
    },
    "time": "140022940",
    "type": 60
  },
  {
    "params": {
      "cipher_suite": 4865,
      "encrypted_client_hello": false,
      "is_resumed": false,
      "key_exchange_group": 4588,
      "next_proto": "h2",
      "peer_signature_algorithm": 2052,
      "version": "TLS 1.3"
    },
    "phase": 2,
    "source": {
      "id": 39339,
      "start_time": "140022925",
      "type": 9
    },
    "time": "140022967",
    "type": 60
  },

[bolu-tife]

This seems cool. We think there might be some data in chrome://net-export/ that probably gives some signals about the TLS handshake and round trips.

We'd love if someone wants to try out a prototype of parsing the netlog and determining these issues.

Hi Team, @paulirish @connorjclark Are the requirements of this issue still up-to-date? I looked into the netlog file and shared some findings here https://github.com/GoogleChrome/lighthouse/issues/6182#issuecomment-3134271751

[bolu-tife]

This seems cool. We think there might be some data in chrome://net-export/ that probably gives some signals about the TLS handshake and round trips. We'd love if someone wants to try out a prototype of parsing the netlog and determining these issues.

Hi Team, @paulirish @connorjclark Are the requirements of this issue still up-to-date? I looked into the netlog file and shared some findings here #6182 (comment)

Is there also an artifact that collects data from netlog or one that returns similar data?