When SSL False Start is enabled, we should send the Finished message and application data in the same TCP packet, to enable us to detect False Start incompatible servers reliably.

We should be doing this anyway, regardless of False Start. And, after having a brief look at it, it looks pretty straightforward to implement. But, why would this will make detection of False Start incompatible servers reliable/deterministic? I can see that it will (probably) almost always eliminate the race condition that made detection of incompatible servers more difficult, but there are multiple races within the TCP and/or TLS stacks of each endpoint that we won't be able to reliably detect or control. And, we'd still have to deal with cases where one server for a domain is compatible with False Start but for some reason another one isn't (probably because the administrator skipped over a server when deploying patches). Consequently, I don't see this as being particularly helpful for False Start. I would be happy to be convinced otherwise, though.

(In reply to comment #1) > We should be doing this anyway, regardless of False Start. And, after having a > brief look at it, it looks pretty straightforward to implement. For non-False Start connections it only makes sense for resumption connections (for a client). Although I agree, it's always good to pack packets. > But, why would this will make detection of False Start incompatible servers > reliable/deterministic? In practice, all False Start incompatible sites appear to be the result of using a single vendor's load balancer equipment. The behaviour of this equipment is that everything in the read buffer after the Finished message is ignored. So, if the application data is an a different packet then sometimes the connection will work (because the application data wasn't in the same read buffer). If the application data is in the same packet as the Finished then it will always be in the same read buffer as the Finished (in the case of this stack). The result is still non-deterministic because the server will either ignore all the application data (and hang) or some application data (which spilled into a subsequent packet) will be read separately causing a protocol error (because the start of the read is the middle of a record). None the less, it's much better that the server always fails. (We are in contact with the vendor and they are working on a fix.)

> For non-False Start connections it only makes sense for resumption > connections (for a client). Correct, and NSS already has code to do this.

I didn't investigate this long, but AFAICT we just need factor out the relevant logic from ssl3_HandleFinished into a function that is callable from both ssl3_SendClientSecondRound and ssl3_HandleFinished. Note that we should only do this when !ss->ssl3.hs.authCertificatePending. In the ss->ssl3.hs.authCertificatePending == true case, we're waiting for the certificate to be validated which is probably going to take a while. So, we're probably better off sending the handshake messages we have now so the server can start sending its final let of the handshake ASAP, so that we can establish a session that we will be able to use to resume immediately upcoming connections. Note: Gecko usually (but not always) drives handshakes by PR_Write()ing data and I think Chromium drives its handshakes using SSL_ForceHandshake. I believe this optimization will be most efficient using the PR_Write case. However, we should verify that things happen according to our expectations. Also, I think that this optimization will work better in the case where the auth certificate hook returns SECSuccess immediately instead of being asynchronous. (In Gecko, this will happen after bug 754365 and follow-up bugs are fixed.)