[strictnein]

Random question: for the preconnect, is there some Javascript API now that allows for the monitoring of the TLS handshake?

As specified in the article, the handshake is:

   TLS handshake (only for HTTPS sites). Perform two roundtrips 
   (a message goes client → server → client → server → client) to initiate a secure TLS session

Is there any part of that which could be used to send a custom message to the client? A short bit of text or a number or something. Don't really have a practical use for this, just more of an esoteric one.

[tyingq]

You can't do it from a browser, but the "tls client hello" could certainly hold a custom message of sorts. Either in the "random bytes" it's supposed to send, or stuffed in as a fake cipher preference in the supplied list.

Good breakdown of the handshake here: http://www.moserware.com/2009/06/first-few-milliseconds-of-h... (skip down to the client hello)

[Crosseye_Jack]

It’s silly o’clock here (unable to sleep) and the following is just going off the top of my head, apologises if I mess it up.

Don’t believe so as during the first round trip in http1 (wasn’t this “fixed” in http2? Silly o’clock, can’t remember, anyways) the client and the server are just working out which cyphers to use.

If you are trying to pull data from the same domain, you have already set up a connection you can reuse saving the need to repeat the need for the first round trip on your next connection to the server. So you are only really losing that first round trip on the first connection. So even if you were pinging another domain regularly as long as you are using a server configured to keep the connection alive for long enough you are not really going to save much any time then just doing it the standard way.

I guess (never tried) you could create your own raw socket connection with say webasm but Browsers do here hardest to keep you away from the raw socket level and I believe they also do even in webasm. (just thinking out loud...)

Then smuggle in your value based on the the cyphers you are requesting the client to pick from. But at which point you might as well just be using plain old un-encrypted socket connections.

EDIT: If you are just trying to send metadata along with a xhr response then you can just send custom headers along with the response and read them with getAllResponseHeaders(), just remember to set the Access-Control-Expose-Headers header too include the custom headers you want to expose to JS.

If you are trying to push data from the client to the server I guess you could do it via DNS. Make a request to http(s)://uuid.part1.thisisamessage.example.com and http(s)://uuid.part2.sentoverdns.example.com and on your dns server record the requests, resemble the parts and you have your data. You could bitbang data back to the client by having the dns reply with a server or not. It would be slow as hell (as your making a dns request and opening up a connection for each bit) but it could be done but unless you are trying to be sneaky (and it’s not that sneaky at all) it’s not worth the hassle over just opening up a “full fat” connection and reusing that connection. (Again just unable to sleep thinking out loud...)

[wiml]

Sure, both the ClientHello and ServerHello (which are the first two messages during setup) can contain arbitrary extension fields; these are already used for things like SNI, ALPN, "early data" (optimistic 0-RTT data), and so on. You could define an extension in the private-use range for your esoteric use.

I don't think there's any way to see this from Javscript, though. At least, not web-browser Javascript.