4 ms·

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

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-a-tls-13-story-10192 https://www.blackhat.com/us-18/briefings/schedule/#playback-... ... and seeing it relates to any of our own research in the same area!

mariusmg 8y ago
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!
sandGorgon 8y ago
i might be inexperienced at this, but i genuinely think that "fit in" is probably not the best criteria when you are building/contributing to a security library. I wish everyone could find a way to work together. OpenSSL was safe because everyone worked on it and contributed to it.
- pvg 8y ago
  The trouble is, OpenSSL ended up not being safe and the lack of ownership contributed to distributing a catastrophic flaw to just about every endpoint on the internet. If you wrote that in fiction as a maliciously-intended incident, people would probably complain it's too naive and unrealistic.

mariusmg 8y ago

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!

sandGorgon 8y ago

i might be inexperienced at this, but i genuinely think that "fit in" is probably not the best criteria when you are building/contributing to a security library. I wish everyone could find a way to work together. OpenSSL was safe because everyone worked on it and contributed to it.

pvg 8y ago
The trouble is, OpenSSL ended up not being safe and the lack of ownership contributed to distributing a catastrophic flaw to just about every endpoint on the internet. If you wrote that in fiction as a maliciously-intended incident, people would probably complain it's too naive and unrealistic.