3 ms·
My thoughts were "That's probably a great project, but no one is going to use it because they'll be worried about a back door." Although it couldn't be that har
by sorbus 15y ago
My thoughts were "That's probably a great project, but no one is going to use it because they'll be worried about a back door." Although it couldn't be that hard to find one - log traffic on startup, see if it makes any requests to servers not requested by the user. Unless the theorized back door is better hidden, such as by introducing a vulnerability into its SSL implementation (and whatever other encryption tools for network traffic it uses) that makes it much easier to decrypt intercepted traffic (not sure how viable that would be; it's not my field of study).
- olefoo 15y agoI can think of two very obvious ways two suborn lib_openssl (obvious in that a competent auditor would find them) after relatively little due diligence. 1. Cripple the random number generator similar to the debian bug from 2008, this would be difficult to spot through source inspection, but not hard to spot from active queries. 2. Include valid certificates in the trusted certificate store that allow the distributor to execute a man in the middle attack. This becomes even easier if the dns servers are hardcoded to be those of the attacker. Basically, if you think the US Air Force has reasons to snoop your communications; don't use their software to communicate. Linux is freely available, build your own high security distro or use OpenBSD or write your own from scratch, don't assume software is secured unless you implicitly trust the person who claims it has been secured for the purpose you are using it; and even then they might be wrong.