Cloudflare speak TLS 1.3 0-RTT with Origin Backend?


#1

I have just started enabling Nginx with TLS 1.3 via BoringSSL on my Cloudflare origin backend servers.

But curious if

  1. Cloudflare have any plans for Edge servers to speak and communicate with origin backends via TLS 1.3 ? And
  2. If so, will we one day be able to speak TLS 1.3 0-RTT between Cloudflare Edge and origin backends ?
  3. If TLS 1.3 0-RTT between Edge and origin is planned, would it be enough for origin backends to implement Cloudflare Authenticated Origin Pulls and CF Full SLL, to protect against 0-RTT replay attacks on the origin backend servers ?

cheers

George


Tls 1.3 & 1.1.1.1
How to see distribution of requests by colocation server?
Tls 1.3 & 1.1.1.1
Why this website ranks so low with Google Page Insights?
Best Nginx config for Cloudflare optimization
#2

Hi George,

These are some great questions.

  1. We have supported TLS 1.3 to the origin since draft 22. However, there have been several revisions since then (including the subsequent RFC) and not all drafts are compatible nor do all current versions of crypto libraries support all drafts. If your origin supports draft 22, you’ll be able to use TLS 1.3 between Cloudflare and your origin today. Otherwise, now that BoringSSL has recently added support for the RFC version of TLS 1.3, it’s on our roadmap to update to this version as well.
  2. We don’t currently have 0-RTT enabled between Cloudflare and the origin for two reasons. First, to mitigate any potential for replay attacks and second, the benefits of 0-RTT are less impactful between servers communicating over a high-bandwidth connection. We may revisit this decision in the future.
  3. No, mutually-authenticated TLS connections won’t be enough to mitigate any replay attacks with 0-RTT. The server still needs to guarantee that a ClientHello message with 0-RTT data is only accepted exactly once and the client needs to limit how it retries initiating 0-RTT connections.

Best,
Max


#3

Hi @Max

  1. Good to know that if the origin and CF edge servers can speak the same TLS 1.3 version, that it will work :slight_smile: BoringSSL is removing all TLS 1.3 drafts for TLS 1.3 RFC only https://boringssl.googlesource.com/boringssl/+/6855e0a470791f6536bae04a54fbe2456d69f91c. So looking forward to Cloudflare’s update to TLS 1.3 RFC version for speaking with origin servers.
  2. As yes CF edge server’s would be much closer to origins (with maybe exception of free plan CF users and Sydney/Australia origins where CF doesn’t necessarily use CF Edge from Sydney but Singapore instead ? IIRC CF Sydney edge reserved for higher plan CF plans ?). But 0-RTT would still benefit slow 3G speed connections ? edit: nevermind that question, CF to origin will never have those speeds heh
  3. On nginx origin, would limiting early data 0-RTT to just GET requests be good workaround on nginx origin side ? I guess this would be something a write up at Cloudflare in more detail for what to do to secure origins using TLS 1.3 0-RTT when used with Cloudflare when TLS 1.3 becomes more prevalent on CF customer’s origin servers as well. Of course that is provided if/when CF would enable 0-RTT for communication with origins :slight_smile:

cheers


#4

@Max OpenSSL 1.1.1 final release is out now https://www.openssl.org/blog/blog/2018/09/11/release111/ so here’s to seeing Cloudflare talking TLS 1.3 with backends that can speak TLS 1.3 final version :slight_smile:

I am ready for it :slight_smile:

nginx -V
nginx version: nginx/1.15.3 (110918-135811)
built by gcc 8.2.1 20180907 (GCC)
built with OpenSSL 1.1.1 11 Sep 2018
TLS SNI support enabled


#6

Curious if there’s any update for TLS 1.3 final rfc version for CF to origin communications ?


#8

Hi George,

Some commercial server providers have used a pre-release version of OpenSSL 1.1.1with their production releases which contained a bug causing them to reject RFC TLS 1.3 connections. See https://github.com/openssl/openssl/issues/7315 for further details.

We’re working with affected customers and server providers to build or install versions that work correctly with RFC TLS 1.3 connections. Unfortunately, this means we’re unable to support RFC TLS 1.3 to the origin until these known issues are resolved. This process may take several months, depending on the urgency with these providers to update their software.

Thank you for your patience while we we work at making the internet a faster and safer place.

Best,
Max


#9

Thanks Max for heads up.

FYI, my Nginx builds can switch between BoringSSL and OpenSSL 1.1.1 so:

I have my Centmin Mod Nginx 1.15 built with either BoringSSL with backported TLS 1.3 draft 23, 28 and rfc final https://community.centminmod.com/threads/enabling-boringssl-tls-v1-3-with-centmin-mod-nginx-http-2-https-server.15527/

 Testing protocols via sockets except NPN+ALPN

 SSLv2      not offered (OK)
 SSLv3      not offered (OK)
 TLS 1      offered
 TLS 1.1    offered
 TLS 1.2    offered (OK)
 TLS 1.3    offered (OK): draft 28, draft 23, final
 NPN/SPDY   not offered
 ALPN/HTTP2 h2, http/1.1 (offered)

with

nginx -V
nginx version: nginx/1.15.6 (211018-013532)
built by gcc 8.2.1 20181019 (GCC) 
built with OpenSSL 1.1.0 (compatible; BoringSSL) (running with BoringSSL)
TLS SNI support enabled

or Centmin Mod Nginx 15 with OpenSSL 1.1.1 TLS 1.3 rfc final and optionally can backport TLS 1.3 draft 23, 26, 28 back into it

 Testing protocols via sockets except NPN+ALPN 

 SSLv2      not offered (OK)
 SSLv3      not offered (OK)
 TLS 1      offered
 TLS 1.1    offered
 TLS 1.2    offered (OK)
 TLS 1.3    offered (OK): draft 28, draft 26, draft 23, final
 NPN/SPDY   not offered
 ALPN/HTTP2 h2, http/1.1 (offered)

with

nginx -V
nginx version: nginx/1.15.6 (211018-023532)
built by gcc 8.2.1 20181019 (GCC) 
built with OpenSSL 1.1.1  11 Sep 2018
TLS SNI support enabled

If you need one more end user to test TLS 1.3 to CF origin connections when nearing the time for it to be ready :slight_smile: