3 ms·

“These findings underscore the importance for software developers in China to use well-supported encryption implementations such as TLS instead of attempting to

“These findings underscore the importance for software developers in China to use well-supported encryption implementations such as TLS instead of attempting to custom design their own.” I’m very interested in better understanding this. Why do they elect to do this? Is this just developer hubris, as found everywhere? Does this relate to government regulation or control, whether above or under the table?

newaccount74 3y ago
My experience with TLS is that it is not trivial to use. Understanding how to use eg. OpenSSL APIs correctly to ensure that a connection is secure, the certificates are valid, etc. is not trivial. The APIs are poorly documented, hard to use, and many examples you can find are outdated (some OpenSSL APIs return different numbers on success/failure depending on version). The platform native libraries are not much better. For example, the SecTrust APIs on macOS / iOS are also poorly documented, hard to use, and have bugs (eg. some time ago they suddenly started to reject valid certificates from Google cloud for some reason). Also, your code is always a ticking time bomb, because TLS algorithms are deprecated, certificates expire, etc. So you are always at the risk of your client code to stop working at some point. So in my opinion, there are often good reasons not to use TLS. But if you make a mistake, everyone will say "You should have used TLS". I wonder what people say when they find a bug despite you using standard crypto?
- jsiepkes 3y ago
  > I wonder what people say when they find a bug despite you using standard crypto? Not using TLS doesn't automatically mean you need to "roll your own crypto". They could have used a well documentend library such as Google Tink[1] instead of doing their own crypto. [1] https://github.com/google/tink https://github.com/google/tink
- manuelabeledo 3y ago
  It may not be trivial to use, but I fail to understand how a solution to a very hard problem is better if tailored. For example, Open/LibreSSL are widespread, have large communities of both maintainers and developers, which necessarily subjects them to continuous audits over time. > Also, your code is always a ticking time bomb, because TLS algorithms are deprecated, certificates expire, etc. So you are always at the risk of your client code to stop working at some point. Certificate expiration should be handled as part of the configuration management lifecycle. Same goes for TLS algos. If you are hardcoding either of these, you are definitely doing something wrong.
- est31 3y ago
  For the deprecated TLS algorithms, just use a bunch of reverse proxies at the front using the latest Debian, CentOS, or Ubuntu LTS, with mostly default settings. For OpenSSL, app developers don't need it. There is OS builtin libraries to do http requests (which is what was done here). As for certificates, there is plenty of solutions allowing for auto-renewal. It's very easy to set up using automation.
  - newaccount74 3y ago
    > There is OS builtin libraries to do http requests If all you want to do is fetch an URL from a public HTTPS server, then I agree. If you want to do anything even slightly more complex (eg. pin a specific cert, or use TLS with a protocol other than HTTPS) then the built in APIs are almost as bad as OpenSSL (at least on macOS/iOS, I don't know other platforms). > As for certificates, there is plenty of solutions allowing for auto-renewal. It's not a problem on the server side. It's a problem on the client side when the root certs expire. It puts an expiration date on your software.
- Nextgrid 3y ago
  It's still more trivial than rolling your own? I would understand (not approve of it, but merely understand) completely ignoring security/authentication - that would obviously be easier and avoid having to answer hard questions and make hard decisions. But here it seems like they've put even more effort actually designing some custom encryption scheme based on (wrongly-applied) cryptographic primitives complete with custom request encapsulation format, etc. This is more work than just swapping your TCP channel with a TLS one and reasonably trivial auxiliary code to load/renew certificates. In this case since they're running it over HTTP it's even easier to just put a reverse-proxy in front that will add HTTPS on top.
2OEH8eoCRo0 3y ago
> Why do they elect to do this? They could be rightly suspicious of a western TLS implementation but discovered the pitfall of writing their own. Could have also been intentional.
- manuelabeledo 3y ago
  > They could be rightly suspicious of a western TLS implementation but discovered the pitfall of writing their own. Could have also been intentional. They could have deployed TLS with some cipher of Chinese origin, not like Chinese companies haven't done this before [0] [0] https://ciphersuite.info/cs/TLS_SM4_GCM_SM3/ https://ciphersuite.info/cs/TLS_SM4_GCM_SM3/
  - lucubratory 3y ago
    If there's a zero day that's been embedded in a protocol by the NSA or actively used by the NSA, I normally wouldn't expect it to come from the actual encryption process itself. It would be something that choosing your own cipher wouldn't fix, because it would be about compromising security on the software level rather than the encryption level. There's a very good reason the PRC won't allow compromised Cisco routers, it wouldn't surprise me if there was similar thinking here, justified or not.
    - manuelabeledo 3y ago
      > … actively used by the NSA … So the NSA would purposefully embed an exploitable bug in a cipher they themselves use? > … it would be about compromising security on the software level rather than the encryption level Those are two very different things. A cipher could very well be exploitable. What you are talking about is the implementation. In other words, a vulnerable cipher would be exploitable regardless of the implementation. It is not the case, though. They tried to deploy their own protocol on top of a well known cipher.
JohnFen 3y ago
It's pretty common for devs who are inexperienced with cryptography to succumb to the temptation to roll their own, especially if they start studying cryptography algorithms. It's always a mistake, though. This is something I had to cover with younger devs quite a bit back when I worked for a company that made heavy use of cryptography.
paxys 3y ago
The article says that they use both HTTP and HTTPS endpoints, and the exchanges using HTTPS are secure (as expected). My guess is they had to build their own encryption scheme paired with plain HTTP for older devices or those that for some reason weren't compatible with the latest TLS standards (which are a lot of them).
hangonhn 3y ago
Developer ignorance rather than hubris. People who don't really know anything about cryptography has the naive and wrong impression that encryption renders your secret completely safe against anything and that only by getting the key or a major cipher vulnerability would the plaintext be revealed. They treat it like a blackbox because they don't know anything. In recent years, some of the crypto libraries have methods (i.e. Fernet) that are much safer and takes care of these issues for you but it's still very possible to make mistakes. I've seen engineers use a static IV for AES because they didn't know how they would be able to search for the encrypted data other than making the ciphertext the same for a given key and plaintext. Basically they severely weakened it because they didn't understand the purpose of a random IV. Again, they thought key + plaintext -> encrypt = super secure.

newaccount74 3y ago

My experience with TLS is that it is not trivial to use. Understanding how to use eg. OpenSSL APIs correctly to ensure that a connection is secure, the certificates are valid, etc. is not trivial. The APIs are poorly documented, hard to use, and many examples you can find are outdated (some OpenSSL APIs return different numbers on success/failure depending on version). The platform native libraries are not much better. For example, the SecTrust APIs on macOS / iOS are also poorly documented, hard to use, and have bugs (eg. some time ago they suddenly started to reject valid certificates from Google cloud for some reason). Also, your code is always a ticking time bomb, because TLS algorithms are deprecated, certificates expire, etc. So you are always at the risk of your client code to stop working at some point. So in my opinion, there are often good reasons not to use TLS. But if you make a mistake, everyone will say "You should have used TLS". I wonder what people say when they find a bug despite you using standard crypto?

jsiepkes 3y ago
> I wonder what people say when they find a bug despite you using standard crypto? Not using TLS doesn't automatically mean you need to "roll your own crypto". They could have used a well documentend library such as Google Tink[1] instead of doing their own crypto. [1] https://github.com/google/tink https://github.com/google/tink
manuelabeledo 3y ago
It may not be trivial to use, but I fail to understand how a solution to a very hard problem is better if tailored. For example, Open/LibreSSL are widespread, have large communities of both maintainers and developers, which necessarily subjects them to continuous audits over time. > Also, your code is always a ticking time bomb, because TLS algorithms are deprecated, certificates expire, etc. So you are always at the risk of your client code to stop working at some point. Certificate expiration should be handled as part of the configuration management lifecycle. Same goes for TLS algos. If you are hardcoding either of these, you are definitely doing something wrong.
est31 3y ago
For the deprecated TLS algorithms, just use a bunch of reverse proxies at the front using the latest Debian, CentOS, or Ubuntu LTS, with mostly default settings. For OpenSSL, app developers don't need it. There is OS builtin libraries to do http requests (which is what was done here). As for certificates, there is plenty of solutions allowing for auto-renewal. It's very easy to set up using automation.
- newaccount74 3y ago
  > There is OS builtin libraries to do http requests If all you want to do is fetch an URL from a public HTTPS server, then I agree. If you want to do anything even slightly more complex (eg. pin a specific cert, or use TLS with a protocol other than HTTPS) then the built in APIs are almost as bad as OpenSSL (at least on macOS/iOS, I don't know other platforms). > As for certificates, there is plenty of solutions allowing for auto-renewal. It's not a problem on the server side. It's a problem on the client side when the root certs expire. It puts an expiration date on your software.
Nextgrid 3y ago
It's still more trivial than rolling your own? I would understand (not approve of it, but merely understand) completely ignoring security/authentication - that would obviously be easier and avoid having to answer hard questions and make hard decisions. But here it seems like they've put even more effort actually designing some custom encryption scheme based on (wrongly-applied) cryptographic primitives complete with custom request encapsulation format, etc. This is more work than just swapping your TCP channel with a TLS one and reasonably trivial auxiliary code to load/renew certificates. In this case since they're running it over HTTP it's even easier to just put a reverse-proxy in front that will add HTTPS on top.

2OEH8eoCRo0 3y ago

> Why do they elect to do this? They could be rightly suspicious of a western TLS implementation but discovered the pitfall of writing their own. Could have also been intentional.

manuelabeledo 3y ago
> They could be rightly suspicious of a western TLS implementation but discovered the pitfall of writing their own. Could have also been intentional. They could have deployed TLS with some cipher of Chinese origin, not like Chinese companies haven't done this before [0] [0] https://ciphersuite.info/cs/TLS_SM4_GCM_SM3/ https://ciphersuite.info/cs/TLS_SM4_GCM_SM3/
- lucubratory 3y ago
  If there's a zero day that's been embedded in a protocol by the NSA or actively used by the NSA, I normally wouldn't expect it to come from the actual encryption process itself. It would be something that choosing your own cipher wouldn't fix, because it would be about compromising security on the software level rather than the encryption level. There's a very good reason the PRC won't allow compromised Cisco routers, it wouldn't surprise me if there was similar thinking here, justified or not.
  - manuelabeledo 3y ago
    > … actively used by the NSA … So the NSA would purposefully embed an exploitable bug in a cipher they themselves use? > … it would be about compromising security on the software level rather than the encryption level Those are two very different things. A cipher could very well be exploitable. What you are talking about is the implementation. In other words, a vulnerable cipher would be exploitable regardless of the implementation. It is not the case, though. They tried to deploy their own protocol on top of a well known cipher.

JohnFen 3y ago

It's pretty common for devs who are inexperienced with cryptography to succumb to the temptation to roll their own, especially if they start studying cryptography algorithms. It's always a mistake, though. This is something I had to cover with younger devs quite a bit back when I worked for a company that made heavy use of cryptography.

paxys 3y ago

The article says that they use both HTTP and HTTPS endpoints, and the exchanges using HTTPS are secure (as expected). My guess is they had to build their own encryption scheme paired with plain HTTP for older devices or those that for some reason weren't compatible with the latest TLS standards (which are a lot of them).

hangonhn 3y ago

Developer ignorance rather than hubris. People who don't really know anything about cryptography has the naive and wrong impression that encryption renders your secret completely safe against anything and that only by getting the key or a major cipher vulnerability would the plaintext be revealed. They treat it like a blackbox because they don't know anything. In recent years, some of the crypto libraries have methods (i.e. Fernet) that are much safer and takes care of these issues for you but it's still very possible to make mistakes. I've seen engineers use a static IV for AES because they didn't know how they would be able to search for the encrypted data other than making the ciphertext the same for a given key and plaintext. Basically they severely weakened it because they didn't understand the purpose of a random IV. Again, they thought key + plaintext -> encrypt = super secure.