3 ms·

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 certifi

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.

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.