4 ms·

TIL there are companies which have they own implementation and "priorities" for common internet protocols. How can a certain implmentation "fit in" better with

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 ?

pvg 8y ago
This is covered in the linked article - they were really interested in higher performance, among other things - both in implementation (zero copy, etc) and features (0-RTT).
colmmacc 8y ago
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 8y ago
  I'm curious about the rationale for supporting different cryptography implementations. Is it mostly for Apple devices?
  - colmmacc 8y ago
    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 8y ago
      That's what I figured - the whole s2n tangent's been pretty interesting, thanks!

pvg 8y ago

This is covered in the linked article - they were really interested in higher performance, among other things - both in implementation (zero copy, etc) and features (0-RTT).

colmmacc 8y ago

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 8y ago
I'm curious about the rationale for supporting different cryptography implementations. Is it mostly for Apple devices?
- colmmacc 8y ago
  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 8y ago
    That's what I figured - the whole s2n tangent's been pretty interesting, thanks!