5 ms·
Humble opinion: It is easy to block apps from sending sensitive information over the internet by running your own DNS cache and root along with a packet filter.
by gwu78 12y ago
Humble opinion: It is easy to block apps from sending sensitive information over the internet by running your own DNS cache and root along with a packet filter.
Humble opinion: If someone really wanted to send sensitive information over the internet, they could do better than HTTPS. Moreover, in the event the user is curious what is being sent, doing an experiment like the one here with a proxy becomes unnecessarily more complicated when the app is using HTTPS.
Humble opinion: Anything that makes it more difficult for the user to see what information an app is sending is not in the user's best interests.
Fact: Are there any alternatives to the scheme used by HTTPS for transmitting and receiving sensitive information? en.wikipedia.org/wiki/NaCl_(software) works pretty good and the code can fit in a Tweet. Suprisingly, its use seems to be spreading; unlike SSL, it does not encourage reliance on untrusted commercial third parties such as SSL cert vendors, "secure" content delivery networks, etc.
Fact: Incidentally NaCl compiles without using make. It requires only /bin/sh and (opinion:) the short scripts are easier to edit than makefiles.
- icebraining 12y agoSSL doesn't require relying on any third-parties, any more than NaCl does - you can use a pinned self-signed certificate, and you don't need any CDNs. CA issued certs are only used in websites, because you don't have a secure channel with which to transmit the pinned cert, but they're redundant for apps.
- gwu78 12y ago"SSL doesn't require relying on any third parties" The word "require" was in quotes for a reason. I have changed the sentence to say "encourage". In practice many people using SSL do rely on third parties. In my opinion this is where many problems arise. My opinion is that most people are not aware SSL can be set up without using third parties, and even among those who are, the whole scheme is so cumbersome and error-prone that such persons are content to pay untrusted vendors, or to allow browser authors, to manage their "security". "... they're redundant for apps." OK, that's a fair point. My comments on third party vendors are only applicable to websites. My comments on the other problems with OpenSSL apply to both apps and websites.
- icebraining 12y agoMy comments on third party vendors are only applicable to websites. But NaCl can't be (securely) used on sites at all, so there's no alternative to SSL there anyway.
- gwu78 12y agoI run CurveCP servers on my computers and they can serve encrypted HTML. It is possible. See curvecp.org/httpcurve.html If you want a working example, see curveprotect.org
- icebraining 12y agoOf course it's possible to transmit encrypted HTML over other channels; I can also zip my HTML files and put a password on them. I was talking about serving a website that can be securely accessed using standard software, not special tools.
- gwu78 12y agoDid you see the other thread that made the HN front page shortly after this one? It was regarding "deprecating" plain text HTTP traffic. It seems some readers believe there is a "requirement" to involve third parties where SSL-"secured" websites are concerned.
- rakoo 12y agoTLS and NaCl are entirely different beasts. NaCl is a nice piece of technology, but TLS isn't just a technology solution; it's fundamentally a policy solution. TLS solves (or tries to, at least) both the "who am I talking to" problem and the "are we talking securely" problem. NaCl can only replace the second one, which is a nonsensical idea to propose because it's not an issue (and it's the easier problem to solve anyway)
- gwu78 12y agoThe first problem can be addressed by the CurveCP prototype, which uses NaCl. tinysshd (see tinyssh.org) coupled with curvecpserver is a working example.