
Deploying TLS 1.3 at scale with Fizz, a performant open source TLS library - runesoerensen
https://code.fb.com/networking-traffic/deploying-tls-1-3-at-scale-with-fizz-a-performant-open-source-tls-library/
======
sandGorgon
AWS s2n will only add TLS 1.3 once it is finalized . Most likely this is why
Facebook implemented its own.

[https://github.com/awslabs/s2n/issues/388](https://github.com/awslabs/s2n/issues/388)

~~~
colmmacc
AWS s2n lead here! I don't think that's the case ... after all it'd be less
work to maintain a branch than to build a whole new implementation. My
understanding from meeting the FB TLS folks over the years is that they have
their own implementation, with their own coding guidelines, and priorities
that "fit in" and suit Facebook. It's great to see more implementations too!
I'm excited to finally pore over the code. Companies like Facebook, and
Amazon, should all have deep ownership here. You'd be amazed how thick into
the weeds we have to get to solve customer problems and it's invaluable to
have a team of expert implementors on staff.

As for TLS1.3, we've been merging TLS1.3 dependencies into s2n already (like
HKDF) and proving them formally, and we contributed to the TLS1.3 process with
some design/security reviews and more. We're big TLS1.3 fans, and it's coming!
As a low-level infrastructure provider with security and availability as our
top priorities, after talking to our more TLS-savvy customers, we did choose
to be a little more conservative, not running experimental branches in
production and so on.

I'm also looking forward to this ...
[https://www.blackhat.com/us-18/briefings/schedule/#playback-...](https://www.blackhat.com/us-18/briefings/schedule/#playback-
a-tls-13-story-10192) ... and seeing it relates to any of our own research in
the same area!

~~~
mariusmg
TIL there are companies which have they own implementation and "priorities"
for common internet protocols. How can a certain implmentation "fit in" better
with FB ? They don't make the OS, browser or even the web servers. What
exactly they have to gain by maintaing a separate implementation ?

~~~
colmmacc
I can't speak for Facebook, only for why we at Amazon have s2n. TLS/SSL is a
critical piece of internet infrastructure and it involves some reasonable
complexity: cryptography, networking, and state machines. When you have
billions of users and trillions of connections, the weight and importance of
solving security, performance, and compatibility issues is pretty high.

Some examples: s2n is about 2% more efficient than OpenSSL for what we do,
that might seem small, but even if I just measure what means for Amazon S3
cost savings, it's more than worth our development time! Another is extreme
compatibility, for example we go out of our way to fingerprint the hello
messages that come from certain Java versions, so that we can work around
performance issues for those clients.

When we do make backwards incompatible changes, like retiring insecure cipher-
suites we can do it in painstakingly tedious ways, like making it the least
preferred and instrumenting clients so that we can figure out exactly what's
left and why. This isn't always easy or obvious; retiring RC4 wasn't just
flipping a flag but also chasing down how to prevent playback from stuttering
on underpowered third-party Amazon Video clients that suddenly had to do the
extra work of AES as well as rendering MP4 in real time. That's just one
example to give you an idea.

TLS1.3 is itself a good example of where the priorities are different. TLS1.3
0-RTT has some real safety/security issues around replays. For us, we have to
take those issues very seriously because AWS vends protocols over HTTPS that
actually implement transactions, and sensitivity to replay has to be very
precise. Internally AWS is also a lightning fast network and response times
tend to be dominated by application latency, not network round trips. Facebook
on the other hand has a lot of mobile clients over distant, awful, networks,
and wants to improve that experience a lot. They also have full control over
the requests being issued.

~~~
pvg
I'm curious about the rationale for supporting different cryptography
implementations. Is it mostly for Apple devices?

~~~
colmmacc
It's more important for the low-powered clients where native implementations
tend to pay a lot of attention to conserving battery life, which is often the
biggest consideration.

~~~
pvg
That's what I figured - the whole s2n tangent's been pretty interesting,
thanks!

------
wolf550e
It depends both on openssl and on libsodium, I searched the GitHub repo [1]
and it uses 3 things from libsodium: constant time memory compare, random
number generator and x25519 key exchange.

Does anyone know or can guess why it uses curve25519 key exchange code from
libsodium and not from openssl? It uses ecc sign and verify and aead code from
openssl.

1 -
[https://github.com/facebookincubator/fizz/search?q=<sodium&u...](https://github.com/facebookincubator/fizz/search?q=<sodium&unscoped_q=<sodium)

------
dcuthbertson
Fizz buzz worth reading about.

