3 ms·

We didn't use TLS at Netflix either, and instead used our own encryption protocol that ran on top of HTTP. We could do this because we controlled the clients t

We didn't use TLS at Netflix either, and instead used our own encryption protocol that ran on top of HTTP. We could do this because we controlled the clients too. The why was because of trust store issues. Every device has its own built in trust store, and especially on devices like TVs and DVD players, they couldn't be updated. After looking at all the devices we supported, there was no common certificate signer amongst all of them. This meant that we would either have to get multiple SSL certs signed by different parties (some of which weren't all that secure) and present the right one depending on your device type, or we could just roll our own over HTTP. So we chose the latter.

toast0 3y ago
Yeah, at WA we didn't have too much of a problem with trust store issues; although we did do extensive testing when we switched CAs. We did have to deal with the end of SHA1 certs though, I think we were able to get all of our clients to use sha2, but some of the platform browsers couldn't; and then we had to fiddle with our TLS server to send sha2 certs to some clients and sha1 certs to others. Of course, there's not really very useful client identification in the TLS Hello, so you have to kind of guess who needs what. If we had to use different CAs for different clients, it would have gotten a lot harder, because it's not like we could rely on clients filling out SNI either. So then you need to get more ips for each service. I do recall needing to do that a little, but we only needed a single 'legacy' group that was useful for everything that couldn't manage the modern certs.
Sohcahtoa82 3y ago
> Every device has its own built in trust store, and especially on devices like TVs and DVD players, they couldn't be updated. Was creating your own certificate authority and pinning it in the app not an option?
- toast0 3y ago
  Bringing your own trust store to system https libraries is not often supported. Especially when you get into kinds of embedded environments Netflix supports. You also might not have the capability to bring your own TLS library either. If it's a limited environment, you might only get reasonable performance if you use the system ciphers, and they may not be exposed as primitives, and x.509 parsing takes up a lot of code space in the likely event that you've got limitations there too.
- jedberg 3y ago
  In most environments you have to use the built in libraries for network connectivity, so you have to use their trust stores. Also space is very limited for the client, so you can't just put everything into it.
waiwai933 3y ago
Our solution for the same problem was to just have different subdomains for each cert signer (and make sure we ship the right base URL for each manufacturer's app), so we didn't need to do any clever device-sniffing at the SSL termination point. I think rolling our own encryption sounds much scarier, but equally we weren't running at Netflix scale.
eadmund 3y ago
This discussion is another great example of why HTTP without TLS can be just fine, even desirable.

toast0 3y ago

Yeah, at WA we didn't have too much of a problem with trust store issues; although we did do extensive testing when we switched CAs. We did have to deal with the end of SHA1 certs though, I think we were able to get all of our clients to use sha2, but some of the platform browsers couldn't; and then we had to fiddle with our TLS server to send sha2 certs to some clients and sha1 certs to others. Of course, there's not really very useful client identification in the TLS Hello, so you have to kind of guess who needs what. If we had to use different CAs for different clients, it would have gotten a lot harder, because it's not like we could rely on clients filling out SNI either. So then you need to get more ips for each service. I do recall needing to do that a little, but we only needed a single 'legacy' group that was useful for everything that couldn't manage the modern certs.

Sohcahtoa82 3y ago

> Every device has its own built in trust store, and especially on devices like TVs and DVD players, they couldn't be updated. Was creating your own certificate authority and pinning it in the app not an option?

toast0 3y ago
Bringing your own trust store to system https libraries is not often supported. Especially when you get into kinds of embedded environments Netflix supports. You also might not have the capability to bring your own TLS library either. If it's a limited environment, you might only get reasonable performance if you use the system ciphers, and they may not be exposed as primitives, and x.509 parsing takes up a lot of code space in the likely event that you've got limitations there too.
jedberg 3y ago
In most environments you have to use the built in libraries for network connectivity, so you have to use their trust stores. Also space is very limited for the client, so you can't just put everything into it.

waiwai933 3y ago

Our solution for the same problem was to just have different subdomains for each cert signer (and make sure we ship the right base URL for each manufacturer's app), so we didn't need to do any clever device-sniffing at the SSL termination point. I think rolling our own encryption sounds much scarier, but equally we weren't running at Netflix scale.

eadmund 3y ago

This discussion is another great example of why HTTP without TLS can be just fine, even desirable.