Enable SSL_MODE_ENABLE_FALSE_START if jdkCompatibilityMode is false

[normanmaurer]

Motivation:

To reduce latency and RTTs we should use TLS False Start when jdkCompatibilityMode is not required and its supported

Modifications:

Use SSL_MODE_ENABLE_FALSE_START when jdkCompatibilityMode is false

Result:

Less RTTs and so lower latency when TLS False Start is supported

[normanmaurer]

This depends on netty/netty-tcnative#558

[carl-mastrangelo]

LGTM

[Fakerr]

Curious here. Since this PR depends on another, would you be interested by a github app that prevents a PR from being merged until its dependency is itself merged ? cc @normanmaurer

[ejona86]

Actually. False Start isn't safe unless you are using a modern cipher suite, as otherwise a MitM could downgrade to a weaker cipher for an attack. Does that mean we want it to be more opt-in?

[normanmaurer]

@ejona86 as far as I am aware BoringSSL will only enable it if safe... Conscrypt enables it by default it seems.

[davidben]

tl;dr: Yeah, you can freely enable it, provided your code is okay with the funny I/O patterns it causes.

False Start bypasses TLS 1.2's downgrade protection so it indeed should only be used with the most preferred cipher suites. BoringSSL requires ECDHE + AEAD internally, which are the strongest parameters for TLS 1.2. Then there's TLS 1.3, but that's why TLS 1.3 injects a ServerHello.random signal into TLS 1.2. BoringSSL sends and enforces that signal by default. We do have an option to disable this check (it was needed early on due to non-compliant enterprise proxies, but we're in the process of phasing that out), but even when disabled, we still gate False Start on that signal.

We additionally, by default, require ALPN with False Start. This isn't needed for security, just an old compatibility hack. Since the cipher suite requirements have since increased, it's possible we can remove it now. But servers ought to move to TLS 1.3 anyway.

[normanmaurer]

@davidben thanks for verify... we may also disable the ALPN requirement I guess... Does this sound ok to you ?

[davidben]

No problems security-wise. SSL_CTX_set_false_start_allowed_without_alpn will disable the ALPN requirement. Compatibility-wise, I don't have any direct data on whether you'd expect breakage or not. (We haven't disabled it in Chrome. At this point TLS 1.3 exists anyway, so it's been decreasingly worth bothering.) I believe Firefox no longer requires this, so it's probably fine?

[normanmaurer]

@davidben thanks for the input...

[ejona86]

Oh, right. Boringssl requires better ciphers. It is good to be boring.

[normanmaurer]

I will pull this one in once we had a netty-tcnative release which includes the needed change

[normanmaurer]

Let me merge this as we have support for it now in netty-tcnative :)