7 ms·

Unintended Affordances (or why I believe encrypting everything is a bad idea)

61 points by mtuncer 11y ago

the_mitsuhiko 11y ago
In case someone reads the cached version, I added a note about my point about Wifi after it was brought up that the attacker could be the Wifi provider itself so refresh the page.
thomashabets2 11y ago
Hello Mr NSA. > First of all encryption cannot stand on it's own, it needs the concept of trust. Wrong. Passive eavesdroppers. Pay attention. > There is another cost and that's the actual cost in CPU cycles. SSL is bloody expensive compared to not doing it. Wrong. AES-NI and the fact that Google uses it should be proof enough. This used to be true, but isn't anymore. > Until fairly recently there was no real way to scale SSL without handing over your private keys to a your frontend SSL machines. I'm pretty sure Cloudflare did not invent this. > forcing SSL on people out of principle should consider that I'm sorry I don't hate freedom like you. > A big cost of encryption however is lawful interception. If this is your problem then just give them the keys. Problem solved. > [antivirus] started to destroy SSL traffic I would assume that the MITM proxy running on localhost also checks CAs, so what's the problem? (besides breaking cert pinning) > I'm firmly of the opinion that none of [SSL MITM] would have happened if SSL traffic was less common. OF COURSE not. They would just MITM it without crypto stuff. So… it would just be worse. > There will be the point in a year or two when the first websites that got forgotten and had SSL configured What's so special about a year or two from now?
- amyjess 11y ago
  > Hello Mr NSA. > I'm sorry I don't hate freedom like you. ...and you just destroyed your own argument with the ad hominems.
  - deleted 11y ago
    [deleted]
  - thomashabets2 11y ago
    http://lmgtfy.com/?q=define+joke http://lmgtfy.com/?q=define+joke
- 0942v8653 11y ago
  > I would assume that the MITM proxy running on localhost also checks CAs, so what's the problem? (besides breaking cert pinning) Superfish did not check CAs. > OF COURSE not. They would just MITM it without crypto stuff. So… it would just be worse. I think the author is arguing here that the MITM attack wouldn't bother with encrypted traffic (which is obviously a very weak argument).
  - the_mitsuhiko 11y ago
    > I think the author is arguing here that the MITM attack wouldn't bother with encrypted traffic (which is obviously a very weak argument). That SSL interception on computers is on the rise is something every PC game developer can probably attribute to. Right now you cannot pin any certificates any more because of the widespread penetration of SSL intercepting firewalls and antivirus solutions.
  - untitaker_ 11y ago
    >I think the author is arguing here that the MITM attack wouldn't bother with encrypted traffic (which is obviously a very weak argument). I think the author is arguing that SSL requires active eavesdropping, which: 1.) Might break encryption (see Superfish), while the user thinks they're using proper SSL (author argued about the "false sense of security" in a separate section) 2.) Might just break things -- more an argument about software stability than privacy or security.
  - thomashabets2 11y ago
    Huh. Well that's superfish. Surely the norm among big name AV is to check CAs? Or am I being naive? > I think the author is arguing here that the MITM attack wouldn't bother with encrypted traffic (which is obviously a very weak argument) That wouldn't be the case if it was all encrypted, so it's actually a counter-argument.
- untitaker_ 11y ago
  >Hello Mr NSA. Oh wow, way to start a constructive discussion. >Wrong. AES-NI and the fact that Google uses it should be proof enough. This used to be true, but isn't anymore. Are you saying the cost of encryption is affordable for everybody because it is for Google?
  - amyjess 11y ago
    > Are you saying the cost of encryption is affordable for everybody because it is for Google? On top of that, it assumes everybody has the latest processors. In reality, people don't upgrade their computers every year. Worse, it's people with older computers who need to eke out every bit of performance their processors offer. Like, sure, I can afford to burn CPU cycles because I have a Haswell i7, but someone with an old Core 2 can't, and they're the ones who will have to burn CPU on encryption, and I don't need to because my powerful CPU has AES-NI.
    - thomashabets2 11y ago
      If you don't have AES-NI, then you don't have much traffic. Otherwise you would have bought newer servers. And you therefore don't have a problem either way.
      - untitaker_ 11y ago
        I don't use encryption for media streaming on my Raspberry Pi because the lack of hardware support for crypto means the download rates drop from 70 to 7 Mbit/s. I won't spend money on the new model because people on the internet tell me streaming cartoon series is sensitive traffic. There you go, a counterexample for your blatant overgeneralization.
        thomashabets2 11y ago
        :-) I seem to remember getting 50-70Mbps with SSL on my Raspberry Pi (not RPi2). I had to tweak my cipherlist, but not to anything unreasonable insecure. The limiting factor there though was by far the USB hard drive attached. Banana Pi has SATA onboard, and not a NIC that's attached over the USB bus, so I'd recommend that in most cases.
- deleted 11y ago
  [deleted]
- CHY872 11y ago
  > Wrong. Passive eavesdroppers. Pay attention. If you're in a position and have the motivation to passively eavesdrop, you probably have the hardware to actively eavesdrop as well. > Wrong. AES-NI and the fact that Google uses it should be proof enough. This used to be true, but isn't anymore. Pure garbage. For example, Netflix saw a 50% capacity drop on their servers by enabling TLS [0]. Google do it because their content is more dynamic, so TLS isn't much in the way of extra demand. If you have mostly static content, the overhead of TLS is pretty much all your overhead. [0] - https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf
  - thomashabets2 11y ago
    > If you're in a position and have the motivation to passively eavesdrop, you probably have the hardware to actively eavesdrop as well. Targeted, yes. Wholesale, no. When I said pay attention I was referring to the fact that in a post-Snowden world the fact that people do this is not even secret any more. Edit: I'm new to HN and don't know why the reply button is missing, but I think you and I have different definition of the word "wholesale". But in any case it's beside the point, since if someone sniffs all Atlantic cables they can see exactly what I do on US servers, while they will only see hostnames and some side channels if it's all SSL. They will not MITM all SSL connections with a forged cert, just to create a dossier on every living human to be retrieved later if they become "interesting". They will if it's HTTP and you can do it passively.
    - CHY872 11y ago
      No, it can be done wholesale. For example, a corporate firewall of the kind used in any large business will happily (and cheaply) MITM every TLS connection that goes through it. It'd be easy for an ISP to install such a device for unsigned certs, if the payoff were great enough. ISPs have incentives too (advertising, user tracking, etc).
      - bonjarber 11y ago
        You are absolutely right that corporations do this. It's important to understand how this is happening though. In order to do so, they must add their own Certificate Authority to your browser so that it accepts a certificate signed by a non-root Certificate Authority as valid. This is easy to manage at a corporate level thanks to things like Active Directory that allow you to install root CA's in the browsers of your domain users. It is far more difficult for an ISP to install a non-root CA in your browser, therefore mitigating this risk.
JoshTriplett 11y ago
Having read the entire article, I'd say that while it's good to consider the implications of encrypting all traffic (including those mentioned in the article), it's perfectly reasonable to have done so and still come to the conclusion that every single one of those implications are entirely by design features, rather than bugs. "Lawful intercept": sure, you have the right, good luck with that. We're not going to make the Internet less secure for the benefit of government interception; if anything, we're making it more secure because of the possibility of government interception. This one is a very old argument, and easily debunked: assuming you allow any encryption at all, just having less of it doesn't make lawful interception any easier, because of course all the illicit traffic will be encrypted. The only thing it does is make encrypted traffic seem more suspicious, which isn't good for anyone. SNI works just about everywhere these days, and it's quite safe for most services to just turn it on and write off the few systems (IE on XP, and truly ancient mobile devices) that can't cope. People don't get used to clicking certificate warnings away because browsers have gone out of their way to make that painful, and it should be. If you don't understand TLS, learn, or count on other people to have learned. That's no excuse for not using it. There are many folks working on fixing the CA problem, but even without that completely fixed, SSL is still better than cleartext. All that said, I do think the first section of the article, about unintended affordances (such as emergencies) is worth considering in other technological contexts. That point was made years ago: http://code-is-law.org/ http://code-is-law.org/
- the_mitsuhiko 11y ago
  > "Lawful intercept": sure, you have the right, good luck with that. We're not going to make the Internet less secure for the benefit of government interception; if anything, we're making it more secure because of the possibility of government interception. Government censorship is happening if you want it or not. The main difference is now that there is a lot more collateral damage with SSL deployed. > If you don't understand TLS, learn, or count on other people to have learned. That's no excuse for not using it. I agree in the sense that anyone who runs a security critical website should deploy SSL and there is no excuse for not doing it. However what triggered the whole article was that more and more websites become completely impossible to use in the absence of SSL even for anonymous data access.
jasode 11y ago
>There is the idea that “there is no such thing as insensitive web traffic” and that the privacy of communication is absolute. The essay seems to center on "privacy" and "hiding". The other use for encryption is "authenticity". We want to have trust that the pixels on the desktop monitor or iPhone are actually correct. Whether a user is a city administrator looking at weather.com pixels to decide whether to shutdown schools for the day, or a grandmother looking at NYT or Yahoo pixels to check a stock price before selling, encryption helps ensure the veracity of what their eyeballs see. Grandma doesn't care if the government or Facebook knows she read the New York Times. Someone on the subway can look over her shoulder to discover that same datapoint. On the other hand, she does need to have confidence that what she reads has not been tampered with. One could attempt to write "data protection" protocols that send multiple hashes to verify the payload. However, if the hashes are cleartext, you're back to where you started with broken trust because the hashes can be spoofed. The necessity of encryption (without regard for hiding or privacy) appears again.
- untitaker_ 11y ago
  You can verify authenticity through signatures -- no need to encrypt the full body for that. The fact that there's no (widespread) general-purpose solution to sign arbitrary traffic is IMO problematic, people apparently are fine with just paying the cost of encryption.
  - nine_k 11y ago
    When you want a piece of information be authentic, chances are high that the information is also of private nature. It would be trivial to add something like <rel signatory="https://this.same.domain/verify" https://this.same.domain/verify" algorithm="sha2"/> to any web page, or an HTTP header of the same nature, and run an HTTPS endpoint to check the url/signature pair. Probably international news agencies could run this, so that the proverbial China government would be able to see that a web page has nothing subversive on it, but anyone could see that the page has not been tampered with, by running a checksum against the page source. A browser extension could be used for that. But it seems that nobody cares enough.
Lawtonfogle 11y ago
The author seems to be calling a lot of things effectively bugs of encryption that I see as features. >Unfortunately, SSL prevents this. Unfortunately because it means that if a website hosts partially illegal shared content, then the whole website is down and not just the subsets of it which are legally problematic. >But not everybody is entitled to privacy in all situations. For instance convicted criminals are not. Likewise many lawful professions need to be heavily surveyed for security. >a pilot hid his psychological problems from his employer and intentionally caused a plane to crash. In my view this is all valid reasons to encrypt everything. When prisoners are made such based on unjust laws, I say that anything that gives them their rights is good. Forcing a government to be very overt about its censorship of websites is good. Allowing people to hide their mental disorders in a world where a mental disorder is still seen as a moral failing is good. Encrypting everything enforces a positive change on society. Governments have to be more open about their censorship, allowing for greater discussion. Dissidents can communicate in secret, allowing for greater freedom. Critical systems have to be built so that a single individual cannot cause a large loss of life. Groups that are required to be surveyed must directly incorporate it into their systems As for the cost of using SSL, my understanding is that they are much overstated.
sre_ops 11y ago
So here we have someone who does not understand how gates work trying to talk about encryption.
icehawk 11y ago
>From an economical perspective a few years ago nobody would have thought about building a SSL MITM proxy for these purposes. sslsniff was released over a decade ago.
- the_mitsuhiko 11y ago
  From my limited testing Anti-virus solutions did not start to scan SSL connections by default until last year.
  - icehawk 11y ago
    There have been security appliances that have had the ability to MITM and scan SSL traffic since at least 2010.
jpgvm 11y ago
I take issue with these arguments. I respect the author but this doesn't read well reasoned. Firstly CAs not being equipped to scale and the inevitable mistakes that will happen in a highly manual process. Thankfully this has already been resolved, we have DNS - if you are in control of DNS you are authenticated. This is is the system to be used in the EFF automated certificate issuing protocol. As for CPU cycles we have Moore's law (which is still in full effect for things like SSL decryption). That and many many motivated engineers. The next bit is where things get sour. It seems the argument is because law enforcement has the "right" to read your traffic that anything you do to dissuade them will only result in further systematic destruction of privacy, i.e MITM attacks on SSL. The final points around complexity do make some sense but those are against SSL, not against encryption IMO. SSL and TLS are both hugely complicated but this need not be the case. As for my point of view. We need encryption. Why? Because communication has changed. Communication used to be manual and as such the attacks against it were manual and unable to be orchestrated at scale. Government surveillance was better understood because communication was simpler so lawmakers couldn't destroy all privacy accidentally. Now almost all communication is digital, it's become economical to simply subvert -everyones- privacy. Lawmakers are at a loss to understand even basic computer science let alone what motivated and technically sophisticated "law enforcement" agencies can do with such massive amounts of information. We need encryption to save privacy before it's lost forever.
- the_mitsuhiko 11y ago
  > We need encryption. Why? Because communication has changed. I never said that we don't need encryption, far form it. I said we do not need to encrypt everything and I firmly stand by that. If we do want to encrypt the entirety of the internet traffic then I believe we need to consider all the consequences this causes. That was my point, not more, not less.
  - jpgvm 11y ago
    I understand. I maybe should have been more specific in my point that I think encrypting everything is the only reasonable defence against such pervasive invasion of privacy. The long term solution is to get to the point where lawmakers talk about encryption, authentication and integrity as things they actually understand. Rather than having people with ulterior motives explain these things to them with snail mail analogies. However, that is many decades off. For now we have encryption and the means to ensure MITM attacks are ineffective.
Skunkleton 11y ago
> But not everybody is entitled to privacy in all situations. Most people are entitled to privacy on the machines that they own. Having to log or monitor internet traffic is the special case, and should not be the default. > That privacy and safety stand in a big conflict was recently quite dramatically demonstrated when a pilot hid his psychological problems from his employer and intentionally caused a plane to crash. You claim a background in psychology, you should be able to recognise this as fear mongering. > The trust there is acquired by giving someone at a specific (private!) institution money and a copy of a passport. This system does not scale, and the number of SSL hosts is exploding. A technological limitation in the current state of internet crypto is not a reason to abandon the concept. Everyone agrees that the concept of a CA isn't great. Someone will solve the problem eventually. > SSL is bloody expensive compared to not doing it. SSL is largely implemented in hardware these days. This is no longer true. > SSL scales really badly intentionally. I find it hard to accept that someone sat down and designed a system to not scale intentionally. Especially hard to believe when you look at the scale of SSL deployment today. > A big cost of encryption however is lawful interception. This is not the place to discuss if governments should have the ability to intercept your internet traffic or not but in many cases they have that right. A big cost of any societal construct is law enforcement. You can make the same argument about cars, or wigs, or plastic surgery. Most of the world strives to not limit personal freedoms out of fear. > Unfortunately because it means that if a website hosts partially illegal shared content, then the whole website is down and not just the subsets of it which are legally problematic. It is up to the website owners to manage this risk, with or without encryption. > A shocking amount of Windows users run software that MITMs SSL connections to scan for viruses, malware etc. Even Ad providers (Superfish cough) started to destroy SSL traffic because it became so widespread that it was necessary. I'm firmly of the opinion that none of that would have happened if SSL traffic was less common. MITM is the default with unsecured traffic. Again, TLS isn't perfect, but why give up? > To give you an example of how ridiculous our love for SSL has become: PyPI. It's the Python package service. As of recently the Python package installer downloads every package via SSL. Why? There is no technical reason for this unless you want to hide from someone that you are downloading a specific Python package which seems pointless. NO!!!!! Package managers are a huge target! What better way to sneak malicious code into someone work than through package management traffic? TLS mitigates this! This is a situation in which a trusted connection is a must.
im3w1l 11y ago
I agree with the point about CDN's. Cloudflare is a single point of failure, that could tamper with connections to a large part of the web.
maerF0x0 11y ago
Not a fan of this argument. It applies the small economic negatives w/o counting the value of the positives. Pro: Democracy is more stable and more guaranteed Pro: Lower level criminals are thwarted and the cost of attacks prohibit profitability of small attacks. Pro: Increasing value of transactions are becoming possible online. No one in their right (or educated) mind would sign into a $10k+ account if their password/traffic wasnt protected.
rakoo 11y ago
> There is no technical reason for this unless you want to hide from someone that you are downloading a specific Python package which seems pointless. "Oh, I see you're downloading this package in a slightly old version that is still vulnerable. I guess you're going to install it, which means you'll be vulnerable in the next 10 mins" This is one of the main obstacles of things like apt-p2p or debtorrent (i.e downloading your system packages in a p2p fashion): you don't wan't to tell the whole world what are the packages on your machine.
- falcolas 11y ago
  Agreed. There is a very technical reason for wanting to encrypt downloads. There's a political reason as well: "I see you just downloaded pycrypto - we're going to throw you on a watchlist since you obviously want to hide something". This speculation is based on past actions doing this very thing with Tor.
krig 11y ago
As I understand it, your argument on a technical level is basically that SSL and the CA system as-is sucks, and I think most people would agree with that. That's something that can be fixed (at least according to djb). On a social level, I don't find any of the arguments convincing. The positives of ensuring private communication far outweigh the negatives.
Nursie 11y ago
This article takes the position the government has the right to shut down communication it dislikes and spy on communication as it sees fit, as this is legal in some places and the author does not want to get into whether or not it should be legal. This is a fundamental disconnect with how many people on the pro-encryption side think - the government has no right to do this, regardless of the law, and therefore we will do all we can to get in the way. >> Cryptography is black magic. It's maths. >> As of recently the Python package installer downloads every package via SSL. Why? There is no technical reason for this unless you want to hide There are multiple reasons. One might be to ensure integrity of the file, and authenticity of the source. TLS gives you this, plaintext not so much. Another is that the more uninteresting stuff there is getting encrypted, the better, as it means it's less noteworthy.
- sanxiyn 11y ago
  I think you are misrepresenting the position opposed to you. My position is like this: pro-encryption people distrust government, which is fundametally mistaken position. Government has rightful authority justified by democratic process. Policy change should be done by democratic process, not by decree from elites using technology such as encryption. Such policy-change-by-technology bypasses democratic process and is dangerous. Trust is human construct, so "trust math, not government" is position that is not only wrong, but also is confused.
  - Nursie 11y ago
    >> Government has rightful authority justified by democratic process. Policy change should be done by democratic process, not by decree from elites using technology such as encryption. This is demonstrably false in light of releases like Snowden's stuff. There is little to no democratic oversight, and at every turn the people are denied the knowledge of what their government is doing and are therefore denied the ability to voice any opposition. How can you democratically oppose something if nobody will even tell you it's going on? >> Such policy-change-by-technology bypasses democratic process and is dangerous. Democracy is being bypassed everywhere here.
  - zAy0LfpBZLC8mAC 11y ago
jerf 11y ago
So, I've upvoted the article because these are things that need to be discussed. And I don't have good answers necessarily, all I really have is a sort of counterpoint to add to the pile of confusing issues. Consider the two-dimensional graph of difficulty of hostile interception of traffic vs. the value of hostile interception of traffic to the intercepting entity. ("Interception" including both attacking authenticity and privacy of the connection.) In the low/low side, you have, say, my blog posts. Deliberately public, of interest to pretty much nobody "official", unencrypted, unauthenticated HTTP. On the high/high side, well-encrypted inter-colo traffic between two computers owned by a bank, or perhaps an arms manufacturer. 10 years ago, this was a rich graph with lots of interesting nuances. Who even cares about the easy/easy cases? Of course the hard/hard cases justify encryption. And there's a lot of in between and useful cost/benefit analysis that could be done. I think the original article is written based on this mental conception of the landscape. However, recently between technological advances and increased discovery about what is being done by governments (and remember, not just the US government, many have been caught doing things and many more are presumably getting away with things we still have not heard about) and a variety of corporations (and remember all this Superfish stuff and such predates the mandatory encryption!) has revealed that the previously-rich 2D landscape really isn't 2D after. It turns out that there is no "difficulty" dimension. It's all very easy to intercept, at scale, if not downright trivial. Governments hoover (both the vacuum and as in J. Edgar) up entire fiber optic trunks. Companies and spyware get a footprint on a machine and basically nuke all SSL flat for thousands of machines or entire major corporations at a time. In the other dimension, it has become pretty clear that even "trivial metadata" allows far more information to be exposed about someone than any but a handful of computer scientists would have believed 10 years ago [1]. Everything has a great deal more value than we thought. The net effect of all of this is that it collapses the entire previously-two-dimensional landscape to a nearly a single point. Everything is trivial to collect, and everything leaks a shocking amount of information, and information is power. Consequently, regardless of the fact that both answers suck in their own way, we really only have one choice: Require encryption, or not. There's no middle ground anymore. We used to have one, but it's collapsed away. And, frankly, acknowledging everything in the original article and with the amplification that there's probably even some stuff missing that could be added, I'm pretty sure that in the end, there's still only one reasonable choice, which is the direction we're currently headed in. Yeah, it sucks. But a root cause analysis of the problem isn't that it's the encryption's fault... it's the companies, spyware, and government that have put in so very, very much effort into collapsing this landscape. Blame them for the measures we have to take to protect everybody. Though, even as you do so, bear in mind that in the rich, complex ecosystem of the Internet, parasites are ultimately inevitable, so it's also no use pretending that if we just fix the current companies and governments we could somehow change the problems. The only answer is that, yeah, we have to rewrite how the "laws of physics" of this ecosystem work. The only other alternative is the overproliferation of parasites and a resulting value collapse of the ecosystem to humanity as it becomes too untrustworthy to use for a variety of things we'd really like to use it for. (That is, I'm not claiming that the Internet would become entirely useless, but we'd really like to be able to use it for important things, not just Buzzfeed and cat videos.) [1]: http://33bits.org/about/ http://33bits.org/about/
fennecfoxen 11y ago
> The greatest impact on user's safety would have been the development of per user encryption for public Wifi access points. Instead what happened is that now every larger website has to implement SSL Assuming that, once it's off the wifi, it's utterly unrealistic that an attacker could be anywhere else in the packet path? That -- even outside of ecommerce -- there's no way any icky ISP could be doing deep packet inspection to sell your data out for ads, or any virus on a cheap consumer-grade router interested in hijacking your profile to turn into a spambot? And assuming, moreover, that this New Technological Capability would be deployed in a consistent and timely fashion? Sure, I agree it'd be an excellent deterrent to many attacks on its own, but end-to-end encryption easily wins. (And if you're really an interesting "larger website" then you have the resources to make SSL happen.)
- the_mitsuhiko 11y ago
  Of course the ISP could fiddle with your data. But likewise a post man could open your mail. That fiddling with data is not a crime is first and foremost a policy and law problem.
  - zAy0LfpBZLC8mAC 11y ago
    Given that encryption also solves the problem, and solves it much more reliably than policy and law ever could, how do you justify the statement that it's first and foremost a policy and law problem?
  - Lawtonfogle 11y ago
    Notice that most people send any mail of substance in a envelope and not a post card. Encryption is the same deal, just with a better envelope.
sgdread 11y ago
I want to point another thing: more and more ISPs are moving away network neutrality. Latest example: Verizon is injecting cookies into users request to be able track their activities and then sell gathered info to advertisers [1] I don't have problems with 3-letter agencies doing what they have to do (though, I would prefer to have proper governance over data access procedures and SSL might help there too), but ISPs should not be altering your traffic. Especially if you pay for the service. SSL prevents cookies injection. [1] https://www.eff.org/deeplinks/2014/11/verizon-x-uidh https://www.eff.org/deeplinks/2014/11/verizon-x-uidh
- the_mitsuhiko 11y ago
  ISPs should most likely not be allowed by law to intercept traffic for such purposes.
unreal37 11y ago
An interesting read. Perhaps he should have said "Using SSL is like using antibiotics. If everyone is using it all the time, the attackers just find ways around it that are impossible to defend against and you're screwed." Not sure I get the analogy about having gates on the subway are bad when people need to use the subway in an emergency. Like, if you have a stab wound and are taking the subway to the hospital, its better not to have to fumble around for change in your pocket and line up for a ticket? Seems like there are actually very few or no emergencies where someone needs to ride the subway for free. Also, I'm no SSL expert, but even if the certificate is expired and the user acknowledges the error, isn't the communication still encrypted? They don't lose the encryption just because of an expired certificate do they? I honestly don't know, but I just assumed that's how it worked. The one thing I agree with is that the trust model for SSL is opaque to most users. I have no idea who my browsers trust by default, and I have no idea who those guys trust, and even if there is a 3rd degree of trust beyond that, and so ultimately there are thousands of people around the world who could spin up an SSL certificate that my browser would trust without question. Strange system.
- zAy0LfpBZLC8mAC 11y ago
  > Perhaps he should have said "Using SSL is like using antibiotics. If everyone is using it all the time, the attackers just find ways around it that are impossible to defend against and you're screwed." Except no such mechanism exists. If you build proper crypto, it's secure, attackers can not simply make it insecure by wishing it were. > Also, I'm no SSL expert, but even if the certificate is expired and the user acknowledges the error, isn't the communication still encrypted? But it might be using a compromised key, for example. Also, one problem is people getting used to clicking "OK" on SSL warnings, which might backfire when confronted with an actual attack.
  - unreal37 11y ago
    > Except no such mechanism exists. If you build proper crypto, it's secure, attackers can not simply make it insecure by wishing it were. It's like the XKCD cartoon.[1] The best crypto can be defeated by a wrench and a guy willing to hit you with it. Or more likely, by passing laws requiring all the major companies of the world to give the government access to the servers whenever they wish. Or by building backdoors into routers that allow them into networks. The way to defeat good crypto is to go around it. [1] https://xkcd.com/538/ https://xkcd.com/538/
thomashabets2 11y ago
Tell this to Github. They are being Javascript DDoSed thanks to non-encrypted connections. And no, it's not "the same thing" if China forced baidu to do it directly, or if they made CNNIC forge an SSL cert.
adricnet 11y ago
Thank you for posting and discussing on HN. More discussion and more viewpoints can only help as we all struggle with these political and technical issues.
JulianMorrison 11y ago
Nice bit of assuming the government's self-granted permissions are "rights" and then hand wringing they can't access them, there. I find myself unconvinced.
Zmetta 11y ago
Encrypting everything promotes individual agency, the freedom of an individual to communicate solely (encryption) and certainly (MAC) with whomever that individual chooses. Cryptographic protocols do not inherently cause performance or logistics complications (Resource usage, content isolation) as these are side effects of other underlying issues with the technology upon which we implement cryptography and can be fixed without compromising the security of cryptography. The only argument against pervasive solid encryption with potential validity is external-party bypassing; where the external-party is outside the intended group of involved parties (Bob & Alice) and wishes to access or manipulate the secured communications. The most obvious situation being some external authority wishing to prevent or prosecute a crime. Traditionally, in the US, you (and your property) have agency until a warrant, subpena, or probable cause arises. At this point, and no sooner, the acting authority suspends some part of that agency for the assumed greater good of the society and begins collecting evidence through an established process. Without this suspension of agency the authority, traditionally, cannot and should not be treating you or your property with reduced agency; the authority should not be preemptively diminishing your agency by starting that evidence collection process (compromising protections) with zero probably cause. It is the problem and responsibility of that authority, as set out by the social contract of free agents comprising our society, to reduce agency and collect evidence AFTER probably cause arises and NOT as the default against every citizen.
sqeaky 11y ago
This article ignores the complexity of not encrypting everything. What is the recourse for the average Joe when his social network doesn't encrypt logins? Facebook did this for years, the average user just ignored it and logged in, no amount of training or convincing could dissuade many. What will the user interface look like for a site that is not encrypted but verified secure? It is hard enough to get people verify the lock icon is green or gold. Many ignore and just assume that online shopping is so fraught with hackers that it cannot be done safely. This will not help that situation. Why do we care about the cost of CPU cycles? No matter how good the encryption is a human still needs to make a decision. Settling on a simple one helps the human make it faster. CPU cycles get cheaper every year but the brain hasn't improved in thousands. Encrypting everything is simple and can be made to work even for less technical people.
- sqeaky 11y ago
  As a secondary point even if don't get simplicity isn't incorrectly setup encryption, better than none? For one example: Self signed certificates don't protect you from a man in the middle perpetrated by the government or ISP, but they will stop neighbors with packet sniffers. If we forgo simplicity I will still encrypt what I can. Having only some protection is not the same as my protection being an illusion.
makmanalp 11y ago
I like this essay, not because I agree with most of its arguments, but because it raises interesting ones. What's frustrating about it, to me, is that the main thrust seems to be "There are problems with TLS, and especially using it everywhere", which is very valid. But then the message / proposed solution is "let's just give up on TLS except for what I arbitrarily define as important". What I would have hoped for is "let's try to make it better".
bonjarber 11y ago
>"this system is even larger than in the past and as such slip-ups are only going to increase.” Yes, the system is certainly larger (as is the internet as a whole) and slip-ups are natural. Luckily these 'slip ups' are typically simple things like certs expiring or supporting outdated cipher suites. These are just minor configuration fixes that things like Lets Encrypt aim to fix (both distribution and configuration of TLS). The thing is, even the worst 'slip ups' don't make you any more insecure than only supporting HTTP. _Any_ amount of TLS is better than none. That is a weak argument to start with. >"SSL is bloody expensive compared to not doing it." No it’s not. Certs are not expensive (another thing improved by Let’s Encrypt). This opinion exists from people spreading these kinds of rumors. It’s 2015 and the minor difference in processing power is negligible. If your web hosting can’t handle the difference in processing costs, you need to look for a better hosting platform. >"Not only does that mean that you are downloading a really big certificate, but also that the SSL encryption is a bit of a lie for you as a user.” 'Really big certificate' when has this been an issue for anyone ever? A CDN providing SSL is still better than no SSL. That "lie" _still_ protects the user at their host->Local Router->ISP->CDN. This is massive value not offered via just HTTP. >"The cost of deploying SSL should not be underestimated, and forcing SSL on people out of principle should consider that.” The cost raised by implementing SSL vs the cost of hosting a web application is negligible. It's pennies on the dollar to ensure your users can have a safer experience using your site. Security comes at a cost, this is part of life. >"The second method is to go to the local ISP and tell them to disable access to it. The rather is the better option in the sense that it only affects the citizens of that country and it isolates the problem. Unfortunately, SSL prevents this.” Yep it's a real shame that it's harder to censor websites. Joe Shmoe the intended reader shouldn't use SSL just in case the government wants to blacklist his domain. >"Even Ad providers (Superfish cough) started to destroy SSL traffic because it became so widespread that it was necessary. I'm firmly of the opinion that none of that would have happened if SSL traffic was less common. “ THE WHOLE REASON THESE AD PROVIDERS ARE BREAKING SSL IS BECAUSE THEY CAN NO LONGER WILLY NILLY READ/INJECT YOUR TRAFFIC. This exactly what Version + AT&T's "super cookie" was doing to HTTP traffic. SSL _prevents_ shit like this from happening. SSL being less common in no way equals less ads reading/injecting your content. >"The greatest impact on user's safety would have been the development of per user encryption for public Wifi access points.” This exists. It's called IPSec and it's a way bigger hassle than SSL, so we all agreed in the 90's that it made more sense to prioritize SSL over IPSec. >"Instead what happened is that now every larger website has to implement SSL to protect against the only realistic attack vector which is someone surfing at Starbucks.” This is absolutely false. I would argue the _most_ users are at risk further down the pipeline, not at Starbucks. We know for a fact that ISP's like Verizon have injected cookies into HTTP traffic leaving their networks and we know for a fact that Governments have done dragnet collections of HTTP traffic. SSL protects users at every step of their internet journey, suggesting half ass encryption is bullshit. >"I now no longer claim I have any understanding of SSL at all.” This is the most accurate statement he makes in the entire article. >"Cryptography is black magic.” Here in lies the problem. It's not. It's actually the opposite, it's open source and it's inner workings can be explained by a multitude of resources. The various features you call 'bugs' in SSL/TLS are things the security community has refined over many years. Crypto is hard, and a lot of things that seem intuitive are not. TLS exists in it's current state because it accomplishes what we want crypto to do. Saying "everyone fuck this thing I'm frustrated with" is counter productive to the whole process. ANY amount of SSL is better for the user than none. >"but the truth is that the most popular cryptography library (OpenSSL) is an old and complex mess. Even if the library itself would be okay, there are so many ways to misuse it and it's really badly documented.” Oh boi let's jump on the OpenSSL hate wagon. We know OpenSSL has had it's issues and there are lots of people helping to make it better (https://cryptoservices.github.io/…/2015/03/09/openssl-audit… https://cryptoservices.github.io/…/2015/03/09/openssl-audit…). The fact that OpenSSL has the occasional implementation error doesn't make the SSL/TLS protocol any worse. >"Gone are the days where you could fully understand how a web application works.“ This has gone from trying to make some kind of point to full whine fest. Yes, web applications have become complicated. So have all parts of technology. As things grow their internals become more intricate and complicated. Also gone are the days where you can fully understand the inner workings of your car engine. Doesn't mean we shouldn't use airbags. >"As of recently the Python package installer downloads every package via SSL. Why? There is no technical reason for this unless you want to hide from someone that you are downloading a specific Python package which seems pointless." Or you know, you don't want packages injected/swapped out with malware when you download them. If I'm downloading code I'm about to run on my system, you better be sure as hell I'm going to want to want integrity and confidentiality of said code. TLS is a standardized way of ensuring both of those things. >"It's plenty to download the package over an untrusted connection and to then verify the checksum with one you downloaded from a secure place." WHERE IS THIS MAGICALLY SECURE PLACE? HOW DOES ONE COMMUNICATE WITH THIS SECURE PLACE? For a guy who considers SSL to be too much effort, I'm to believe that everything he downloads is checked against checksums received via his 'secure place'

61 points by mtuncer 11y ago

In case someone reads the cached version, I added a note about my point about Wifi after it was brought up that the attacker could be the Wifi provider itself so refresh the page.

thomashabets2 11y ago

Hello Mr NSA. > First of all encryption cannot stand on it's own, it needs the concept of trust. Wrong. Passive eavesdroppers. Pay attention. > There is another cost and that's the actual cost in CPU cycles. SSL is bloody expensive compared to not doing it. Wrong. AES-NI and the fact that Google uses it should be proof enough. This used to be true, but isn't anymore. > Until fairly recently there was no real way to scale SSL without handing over your private keys to a your frontend SSL machines. I'm pretty sure Cloudflare did not invent this. > forcing SSL on people out of principle should consider that I'm sorry I don't hate freedom like you. > A big cost of encryption however is lawful interception. If this is your problem then just give them the keys. Problem solved. > [antivirus] started to destroy SSL traffic I would assume that the MITM proxy running on localhost also checks CAs, so what's the problem? (besides breaking cert pinning) > I'm firmly of the opinion that none of [SSL MITM] would have happened if SSL traffic was less common. OF COURSE not. They would just MITM it without crypto stuff. So… it would just be worse. > There will be the point in a year or two when the first websites that got forgotten and had SSL configured What's so special about a year or two from now?

amyjess 11y ago
> Hello Mr NSA. > I'm sorry I don't hate freedom like you. ...and you just destroyed your own argument with the ad hominems.
- deleted 11y ago
  [deleted]
- thomashabets2 11y ago
  http://lmgtfy.com/?q=define+joke http://lmgtfy.com/?q=define+joke
0942v8653 11y ago
> I would assume that the MITM proxy running on localhost also checks CAs, so what's the problem? (besides breaking cert pinning) Superfish did not check CAs. > OF COURSE not. They would just MITM it without crypto stuff. So… it would just be worse. I think the author is arguing here that the MITM attack wouldn't bother with encrypted traffic (which is obviously a very weak argument).
- the_mitsuhiko 11y ago
  > I think the author is arguing here that the MITM attack wouldn't bother with encrypted traffic (which is obviously a very weak argument). That SSL interception on computers is on the rise is something every PC game developer can probably attribute to. Right now you cannot pin any certificates any more because of the widespread penetration of SSL intercepting firewalls and antivirus solutions.
- untitaker_ 11y ago
  >I think the author is arguing here that the MITM attack wouldn't bother with encrypted traffic (which is obviously a very weak argument). I think the author is arguing that SSL requires active eavesdropping, which: 1.) Might break encryption (see Superfish), while the user thinks they're using proper SSL (author argued about the "false sense of security" in a separate section) 2.) Might just break things -- more an argument about software stability than privacy or security.
- thomashabets2 11y ago
  Huh. Well that's superfish. Surely the norm among big name AV is to check CAs? Or am I being naive? > I think the author is arguing here that the MITM attack wouldn't bother with encrypted traffic (which is obviously a very weak argument) That wouldn't be the case if it was all encrypted, so it's actually a counter-argument.
untitaker_ 11y ago
>Hello Mr NSA. Oh wow, way to start a constructive discussion. >Wrong. AES-NI and the fact that Google uses it should be proof enough. This used to be true, but isn't anymore. Are you saying the cost of encryption is affordable for everybody because it is for Google?
- amyjess 11y ago
  > Are you saying the cost of encryption is affordable for everybody because it is for Google? On top of that, it assumes everybody has the latest processors. In reality, people don't upgrade their computers every year. Worse, it's people with older computers who need to eke out every bit of performance their processors offer. Like, sure, I can afford to burn CPU cycles because I have a Haswell i7, but someone with an old Core 2 can't, and they're the ones who will have to burn CPU on encryption, and I don't need to because my powerful CPU has AES-NI.
  - thomashabets2 11y ago
    If you don't have AES-NI, then you don't have much traffic. Otherwise you would have bought newer servers. And you therefore don't have a problem either way.
    - untitaker_ 11y ago
      I don't use encryption for media streaming on my Raspberry Pi because the lack of hardware support for crypto means the download rates drop from 70 to 7 Mbit/s. I won't spend money on the new model because people on the internet tell me streaming cartoon series is sensitive traffic. There you go, a counterexample for your blatant overgeneralization.
      - thomashabets2 11y ago
        :-) I seem to remember getting 50-70Mbps with SSL on my Raspberry Pi (not RPi2). I had to tweak my cipherlist, but not to anything unreasonable insecure. The limiting factor there though was by far the USB hard drive attached. Banana Pi has SATA onboard, and not a NIC that's attached over the USB bus, so I'd recommend that in most cases.
deleted 11y ago
[deleted]
CHY872 11y ago
> Wrong. Passive eavesdroppers. Pay attention. If you're in a position and have the motivation to passively eavesdrop, you probably have the hardware to actively eavesdrop as well. > Wrong. AES-NI and the fact that Google uses it should be proof enough. This used to be true, but isn't anymore. Pure garbage. For example, Netflix saw a 50% capacity drop on their servers by enabling TLS [0]. Google do it because their content is more dynamic, so TLS isn't much in the way of extra demand. If you have mostly static content, the overhead of TLS is pretty much all your overhead. [0] - https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf
- thomashabets2 11y ago
  > If you're in a position and have the motivation to passively eavesdrop, you probably have the hardware to actively eavesdrop as well. Targeted, yes. Wholesale, no. When I said pay attention I was referring to the fact that in a post-Snowden world the fact that people do this is not even secret any more. Edit: I'm new to HN and don't know why the reply button is missing, but I think you and I have different definition of the word "wholesale". But in any case it's beside the point, since if someone sniffs all Atlantic cables they can see exactly what I do on US servers, while they will only see hostnames and some side channels if it's all SSL. They will not MITM all SSL connections with a forged cert, just to create a dossier on every living human to be retrieved later if they become "interesting". They will if it's HTTP and you can do it passively.
  - CHY872 11y ago
    No, it can be done wholesale. For example, a corporate firewall of the kind used in any large business will happily (and cheaply) MITM every TLS connection that goes through it. It'd be easy for an ISP to install such a device for unsigned certs, if the payoff were great enough. ISPs have incentives too (advertising, user tracking, etc).
    - bonjarber 11y ago
      You are absolutely right that corporations do this. It's important to understand how this is happening though. In order to do so, they must add their own Certificate Authority to your browser so that it accepts a certificate signed by a non-root Certificate Authority as valid. This is easy to manage at a corporate level thanks to things like Active Directory that allow you to install root CA's in the browsers of your domain users. It is far more difficult for an ISP to install a non-root CA in your browser, therefore mitigating this risk.

JoshTriplett 11y ago

Having read the entire article, I'd say that while it's good to consider the implications of encrypting all traffic (including those mentioned in the article), it's perfectly reasonable to have done so and still come to the conclusion that every single one of those implications are entirely by design features, rather than bugs. "Lawful intercept": sure, you have the right, good luck with that. We're not going to make the Internet less secure for the benefit of government interception; if anything, we're making it more secure because of the possibility of government interception. This one is a very old argument, and easily debunked: assuming you allow any encryption at all, just having less of it doesn't make lawful interception any easier, because of course all the illicit traffic will be encrypted. The only thing it does is make encrypted traffic seem more suspicious, which isn't good for anyone. SNI works just about everywhere these days, and it's quite safe for most services to just turn it on and write off the few systems (IE on XP, and truly ancient mobile devices) that can't cope. People don't get used to clicking certificate warnings away because browsers have gone out of their way to make that painful, and it should be. If you don't understand TLS, learn, or count on other people to have learned. That's no excuse for not using it. There are many folks working on fixing the CA problem, but even without that completely fixed, SSL is still better than cleartext. All that said, I do think the first section of the article, about unintended affordances (such as emergencies) is worth considering in other technological contexts. That point was made years ago: http://code-is-law.org/ http://code-is-law.org/

the_mitsuhiko 11y ago
> "Lawful intercept": sure, you have the right, good luck with that. We're not going to make the Internet less secure for the benefit of government interception; if anything, we're making it more secure because of the possibility of government interception. Government censorship is happening if you want it or not. The main difference is now that there is a lot more collateral damage with SSL deployed. > If you don't understand TLS, learn, or count on other people to have learned. That's no excuse for not using it. I agree in the sense that anyone who runs a security critical website should deploy SSL and there is no excuse for not doing it. However what triggered the whole article was that more and more websites become completely impossible to use in the absence of SSL even for anonymous data access.

jasode 11y ago

>There is the idea that “there is no such thing as insensitive web traffic” and that the privacy of communication is absolute. The essay seems to center on "privacy" and "hiding". The other use for encryption is "authenticity". We want to have trust that the pixels on the desktop monitor or iPhone are actually correct. Whether a user is a city administrator looking at weather.com pixels to decide whether to shutdown schools for the day, or a grandmother looking at NYT or Yahoo pixels to check a stock price before selling, encryption helps ensure the veracity of what their eyeballs see. Grandma doesn't care if the government or Facebook knows she read the New York Times. Someone on the subway can look over her shoulder to discover that same datapoint. On the other hand, she does need to have confidence that what she reads has not been tampered with. One could attempt to write "data protection" protocols that send multiple hashes to verify the payload. However, if the hashes are cleartext, you're back to where you started with broken trust because the hashes can be spoofed. The necessity of encryption (without regard for hiding or privacy) appears again.

untitaker_ 11y ago
You can verify authenticity through signatures -- no need to encrypt the full body for that. The fact that there's no (widespread) general-purpose solution to sign arbitrary traffic is IMO problematic, people apparently are fine with just paying the cost of encryption.
- nine_k 11y ago
  When you want a piece of information be authentic, chances are high that the information is also of private nature. It would be trivial to add something like <rel signatory="https://this.same.domain/verify" https://this.same.domain/verify" algorithm="sha2"/> to any web page, or an HTTP header of the same nature, and run an HTTPS endpoint to check the url/signature pair. Probably international news agencies could run this, so that the proverbial China government would be able to see that a web page has nothing subversive on it, but anyone could see that the page has not been tampered with, by running a checksum against the page source. A browser extension could be used for that. But it seems that nobody cares enough.

Lawtonfogle 11y ago

The author seems to be calling a lot of things effectively bugs of encryption that I see as features. >Unfortunately, SSL prevents this. Unfortunately because it means that if a website hosts partially illegal shared content, then the whole website is down and not just the subsets of it which are legally problematic. >But not everybody is entitled to privacy in all situations. For instance convicted criminals are not. Likewise many lawful professions need to be heavily surveyed for security. >a pilot hid his psychological problems from his employer and intentionally caused a plane to crash. In my view this is all valid reasons to encrypt everything. When prisoners are made such based on unjust laws, I say that anything that gives them their rights is good. Forcing a government to be very overt about its censorship of websites is good. Allowing people to hide their mental disorders in a world where a mental disorder is still seen as a moral failing is good. Encrypting everything enforces a positive change on society. Governments have to be more open about their censorship, allowing for greater discussion. Dissidents can communicate in secret, allowing for greater freedom. Critical systems have to be built so that a single individual cannot cause a large loss of life. Groups that are required to be surveyed must directly incorporate it into their systems As for the cost of using SSL, my understanding is that they are much overstated.

sre_ops 11y ago

So here we have someone who does not understand how gates work trying to talk about encryption.

icehawk 11y ago

>From an economical perspective a few years ago nobody would have thought about building a SSL MITM proxy for these purposes. sslsniff was released over a decade ago.

the_mitsuhiko 11y ago
From my limited testing Anti-virus solutions did not start to scan SSL connections by default until last year.
- icehawk 11y ago
  There have been security appliances that have had the ability to MITM and scan SSL traffic since at least 2010.

jpgvm 11y ago

I take issue with these arguments. I respect the author but this doesn't read well reasoned. Firstly CAs not being equipped to scale and the inevitable mistakes that will happen in a highly manual process. Thankfully this has already been resolved, we have DNS - if you are in control of DNS you are authenticated. This is is the system to be used in the EFF automated certificate issuing protocol. As for CPU cycles we have Moore's law (which is still in full effect for things like SSL decryption). That and many many motivated engineers. The next bit is where things get sour. It seems the argument is because law enforcement has the "right" to read your traffic that anything you do to dissuade them will only result in further systematic destruction of privacy, i.e MITM attacks on SSL. The final points around complexity do make some sense but those are against SSL, not against encryption IMO. SSL and TLS are both hugely complicated but this need not be the case. As for my point of view. We need encryption. Why? Because communication has changed. Communication used to be manual and as such the attacks against it were manual and unable to be orchestrated at scale. Government surveillance was better understood because communication was simpler so lawmakers couldn't destroy all privacy accidentally. Now almost all communication is digital, it's become economical to simply subvert -everyones- privacy. Lawmakers are at a loss to understand even basic computer science let alone what motivated and technically sophisticated "law enforcement" agencies can do with such massive amounts of information. We need encryption to save privacy before it's lost forever.

the_mitsuhiko 11y ago
> We need encryption. Why? Because communication has changed. I never said that we don't need encryption, far form it. I said we do not need to encrypt everything and I firmly stand by that. If we do want to encrypt the entirety of the internet traffic then I believe we need to consider all the consequences this causes. That was my point, not more, not less.
- jpgvm 11y ago
  I understand. I maybe should have been more specific in my point that I think encrypting everything is the only reasonable defence against such pervasive invasion of privacy. The long term solution is to get to the point where lawmakers talk about encryption, authentication and integrity as things they actually understand. Rather than having people with ulterior motives explain these things to them with snail mail analogies. However, that is many decades off. For now we have encryption and the means to ensure MITM attacks are ineffective.

Skunkleton 11y ago

> But not everybody is entitled to privacy in all situations. Most people are entitled to privacy on the machines that they own. Having to log or monitor internet traffic is the special case, and should not be the default. > That privacy and safety stand in a big conflict was recently quite dramatically demonstrated when a pilot hid his psychological problems from his employer and intentionally caused a plane to crash. You claim a background in psychology, you should be able to recognise this as fear mongering. > The trust there is acquired by giving someone at a specific (private!) institution money and a copy of a passport. This system does not scale, and the number of SSL hosts is exploding. A technological limitation in the current state of internet crypto is not a reason to abandon the concept. Everyone agrees that the concept of a CA isn't great. Someone will solve the problem eventually. > SSL is bloody expensive compared to not doing it. SSL is largely implemented in hardware these days. This is no longer true. > SSL scales really badly intentionally. I find it hard to accept that someone sat down and designed a system to not scale intentionally. Especially hard to believe when you look at the scale of SSL deployment today. > A big cost of encryption however is lawful interception. This is not the place to discuss if governments should have the ability to intercept your internet traffic or not but in many cases they have that right. A big cost of any societal construct is law enforcement. You can make the same argument about cars, or wigs, or plastic surgery. Most of the world strives to not limit personal freedoms out of fear. > Unfortunately because it means that if a website hosts partially illegal shared content, then the whole website is down and not just the subsets of it which are legally problematic. It is up to the website owners to manage this risk, with or without encryption. > A shocking amount of Windows users run software that MITMs SSL connections to scan for viruses, malware etc. Even Ad providers (Superfish cough) started to destroy SSL traffic because it became so widespread that it was necessary. I'm firmly of the opinion that none of that would have happened if SSL traffic was less common. MITM is the default with unsecured traffic. Again, TLS isn't perfect, but why give up? > To give you an example of how ridiculous our love for SSL has become: PyPI. It's the Python package service. As of recently the Python package installer downloads every package via SSL. Why? There is no technical reason for this unless you want to hide from someone that you are downloading a specific Python package which seems pointless. NO!!!!! Package managers are a huge target! What better way to sneak malicious code into someone work than through package management traffic? TLS mitigates this! This is a situation in which a trusted connection is a must.

im3w1l 11y ago

I agree with the point about CDN's. Cloudflare is a single point of failure, that could tamper with connections to a large part of the web.

maerF0x0 11y ago

Not a fan of this argument. It applies the small economic negatives w/o counting the value of the positives. Pro: Democracy is more stable and more guaranteed Pro: Lower level criminals are thwarted and the cost of attacks prohibit profitability of small attacks. Pro: Increasing value of transactions are becoming possible online. No one in their right (or educated) mind would sign into a $10k+ account if their password/traffic wasnt protected.

rakoo 11y ago

> There is no technical reason for this unless you want to hide from someone that you are downloading a specific Python package which seems pointless. "Oh, I see you're downloading this package in a slightly old version that is still vulnerable. I guess you're going to install it, which means you'll be vulnerable in the next 10 mins" This is one of the main obstacles of things like apt-p2p or debtorrent (i.e downloading your system packages in a p2p fashion): you don't wan't to tell the whole world what are the packages on your machine.

falcolas 11y ago
Agreed. There is a very technical reason for wanting to encrypt downloads. There's a political reason as well: "I see you just downloaded pycrypto - we're going to throw you on a watchlist since you obviously want to hide something". This speculation is based on past actions doing this very thing with Tor.

krig 11y ago

As I understand it, your argument on a technical level is basically that SSL and the CA system as-is sucks, and I think most people would agree with that. That's something that can be fixed (at least according to djb). On a social level, I don't find any of the arguments convincing. The positives of ensuring private communication far outweigh the negatives.

Nursie 11y ago

This article takes the position the government has the right to shut down communication it dislikes and spy on communication as it sees fit, as this is legal in some places and the author does not want to get into whether or not it should be legal. This is a fundamental disconnect with how many people on the pro-encryption side think - the government has no right to do this, regardless of the law, and therefore we will do all we can to get in the way. >> Cryptography is black magic. It's maths. >> As of recently the Python package installer downloads every package via SSL. Why? There is no technical reason for this unless you want to hide There are multiple reasons. One might be to ensure integrity of the file, and authenticity of the source. TLS gives you this, plaintext not so much. Another is that the more uninteresting stuff there is getting encrypted, the better, as it means it's less noteworthy.

sanxiyn 11y ago
I think you are misrepresenting the position opposed to you. My position is like this: pro-encryption people distrust government, which is fundametally mistaken position. Government has rightful authority justified by democratic process. Policy change should be done by democratic process, not by decree from elites using technology such as encryption. Such policy-change-by-technology bypasses democratic process and is dangerous. Trust is human construct, so "trust math, not government" is position that is not only wrong, but also is confused.
- Nursie 11y ago
  >> Government has rightful authority justified by democratic process. Policy change should be done by democratic process, not by decree from elites using technology such as encryption. This is demonstrably false in light of releases like Snowden's stuff. There is little to no democratic oversight, and at every turn the people are denied the knowledge of what their government is doing and are therefore denied the ability to voice any opposition. How can you democratically oppose something if nobody will even tell you it's going on? >> Such policy-change-by-technology bypasses democratic process and is dangerous. Democracy is being bypassed everywhere here.
- zAy0LfpBZLC8mAC 11y ago

jerf 11y ago

So, I've upvoted the article because these are things that need to be discussed. And I don't have good answers necessarily, all I really have is a sort of counterpoint to add to the pile of confusing issues. Consider the two-dimensional graph of difficulty of hostile interception of traffic vs. the value of hostile interception of traffic to the intercepting entity. ("Interception" including both attacking authenticity and privacy of the connection.) In the low/low side, you have, say, my blog posts. Deliberately public, of interest to pretty much nobody "official", unencrypted, unauthenticated HTTP. On the high/high side, well-encrypted inter-colo traffic between two computers owned by a bank, or perhaps an arms manufacturer. 10 years ago, this was a rich graph with lots of interesting nuances. Who even cares about the easy/easy cases? Of course the hard/hard cases justify encryption. And there's a lot of in between and useful cost/benefit analysis that could be done. I think the original article is written based on this mental conception of the landscape. However, recently between technological advances and increased discovery about what is being done by governments (and remember, not just the US government, many have been caught doing things and many more are presumably getting away with things we still have not heard about) and a variety of corporations (and remember all this Superfish stuff and such predates the mandatory encryption!) has revealed that the previously-rich 2D landscape really isn't 2D after. It turns out that there is no "difficulty" dimension. It's all very easy to intercept, at scale, if not downright trivial. Governments hoover (both the vacuum and as in J. Edgar) up entire fiber optic trunks. Companies and spyware get a footprint on a machine and basically nuke all SSL flat for thousands of machines or entire major corporations at a time. In the other dimension, it has become pretty clear that even "trivial metadata" allows far more information to be exposed about someone than any but a handful of computer scientists would have believed 10 years ago [1]. Everything has a great deal more value than we thought. The net effect of all of this is that it collapses the entire previously-two-dimensional landscape to a nearly a single point. Everything is trivial to collect, and everything leaks a shocking amount of information, and information is power. Consequently, regardless of the fact that both answers suck in their own way, we really only have one choice: Require encryption, or not. There's no middle ground anymore. We used to have one, but it's collapsed away. And, frankly, acknowledging everything in the original article and with the amplification that there's probably even some stuff missing that could be added, I'm pretty sure that in the end, there's still only one reasonable choice, which is the direction we're currently headed in. Yeah, it sucks. But a root cause analysis of the problem isn't that it's the encryption's fault... it's the companies, spyware, and government that have put in so very, very much effort into collapsing this landscape. Blame them for the measures we have to take to protect everybody. Though, even as you do so, bear in mind that in the rich, complex ecosystem of the Internet, parasites are ultimately inevitable, so it's also no use pretending that if we just fix the current companies and governments we could somehow change the problems. The only answer is that, yeah, we have to rewrite how the "laws of physics" of this ecosystem work. The only other alternative is the overproliferation of parasites and a resulting value collapse of the ecosystem to humanity as it becomes too untrustworthy to use for a variety of things we'd really like to use it for. (That is, I'm not claiming that the Internet would become entirely useless, but we'd really like to be able to use it for important things, not just Buzzfeed and cat videos.) [1]: http://33bits.org/about/ http://33bits.org/about/

fennecfoxen 11y ago

> The greatest impact on user's safety would have been the development of per user encryption for public Wifi access points. Instead what happened is that now every larger website has to implement SSL Assuming that, once it's off the wifi, it's utterly unrealistic that an attacker could be anywhere else in the packet path? That -- even outside of ecommerce -- there's no way any icky ISP could be doing deep packet inspection to sell your data out for ads, or any virus on a cheap consumer-grade router interested in hijacking your profile to turn into a spambot? And assuming, moreover, that this New Technological Capability would be deployed in a consistent and timely fashion? Sure, I agree it'd be an excellent deterrent to many attacks on its own, but end-to-end encryption easily wins. (And if you're really an interesting "larger website" then you have the resources to make SSL happen.)

the_mitsuhiko 11y ago
Of course the ISP could fiddle with your data. But likewise a post man could open your mail. That fiddling with data is not a crime is first and foremost a policy and law problem.
- zAy0LfpBZLC8mAC 11y ago
  Given that encryption also solves the problem, and solves it much more reliably than policy and law ever could, how do you justify the statement that it's first and foremost a policy and law problem?
- Lawtonfogle 11y ago
  Notice that most people send any mail of substance in a envelope and not a post card. Encryption is the same deal, just with a better envelope.

sgdread 11y ago

I want to point another thing: more and more ISPs are moving away network neutrality. Latest example: Verizon is injecting cookies into users request to be able track their activities and then sell gathered info to advertisers [1] I don't have problems with 3-letter agencies doing what they have to do (though, I would prefer to have proper governance over data access procedures and SSL might help there too), but ISPs should not be altering your traffic. Especially if you pay for the service. SSL prevents cookies injection. [1] https://www.eff.org/deeplinks/2014/11/verizon-x-uidh https://www.eff.org/deeplinks/2014/11/verizon-x-uidh

the_mitsuhiko 11y ago
ISPs should most likely not be allowed by law to intercept traffic for such purposes.

unreal37 11y ago

An interesting read. Perhaps he should have said "Using SSL is like using antibiotics. If everyone is using it all the time, the attackers just find ways around it that are impossible to defend against and you're screwed." Not sure I get the analogy about having gates on the subway are bad when people need to use the subway in an emergency. Like, if you have a stab wound and are taking the subway to the hospital, its better not to have to fumble around for change in your pocket and line up for a ticket? Seems like there are actually very few or no emergencies where someone needs to ride the subway for free. Also, I'm no SSL expert, but even if the certificate is expired and the user acknowledges the error, isn't the communication still encrypted? They don't lose the encryption just because of an expired certificate do they? I honestly don't know, but I just assumed that's how it worked. The one thing I agree with is that the trust model for SSL is opaque to most users. I have no idea who my browsers trust by default, and I have no idea who those guys trust, and even if there is a 3rd degree of trust beyond that, and so ultimately there are thousands of people around the world who could spin up an SSL certificate that my browser would trust without question. Strange system.

zAy0LfpBZLC8mAC 11y ago
> Perhaps he should have said "Using SSL is like using antibiotics. If everyone is using it all the time, the attackers just find ways around it that are impossible to defend against and you're screwed." Except no such mechanism exists. If you build proper crypto, it's secure, attackers can not simply make it insecure by wishing it were. > Also, I'm no SSL expert, but even if the certificate is expired and the user acknowledges the error, isn't the communication still encrypted? But it might be using a compromised key, for example. Also, one problem is people getting used to clicking "OK" on SSL warnings, which might backfire when confronted with an actual attack.
- unreal37 11y ago
  > Except no such mechanism exists. If you build proper crypto, it's secure, attackers can not simply make it insecure by wishing it were. It's like the XKCD cartoon.[1] The best crypto can be defeated by a wrench and a guy willing to hit you with it. Or more likely, by passing laws requiring all the major companies of the world to give the government access to the servers whenever they wish. Or by building backdoors into routers that allow them into networks. The way to defeat good crypto is to go around it. [1] https://xkcd.com/538/ https://xkcd.com/538/

thomashabets2 11y ago

Tell this to Github. They are being Javascript DDoSed thanks to non-encrypted connections. And no, it's not "the same thing" if China forced baidu to do it directly, or if they made CNNIC forge an SSL cert.

adricnet 11y ago

Thank you for posting and discussing on HN. More discussion and more viewpoints can only help as we all struggle with these political and technical issues.

JulianMorrison 11y ago

Nice bit of assuming the government's self-granted permissions are "rights" and then hand wringing they can't access them, there. I find myself unconvinced.

Zmetta 11y ago

Encrypting everything promotes individual agency, the freedom of an individual to communicate solely (encryption) and certainly (MAC) with whomever that individual chooses. Cryptographic protocols do not inherently cause performance or logistics complications (Resource usage, content isolation) as these are side effects of other underlying issues with the technology upon which we implement cryptography and can be fixed without compromising the security of cryptography. The only argument against pervasive solid encryption with potential validity is external-party bypassing; where the external-party is outside the intended group of involved parties (Bob & Alice) and wishes to access or manipulate the secured communications. The most obvious situation being some external authority wishing to prevent or prosecute a crime. Traditionally, in the US, you (and your property) have agency until a warrant, subpena, or probable cause arises. At this point, and no sooner, the acting authority suspends some part of that agency for the assumed greater good of the society and begins collecting evidence through an established process. Without this suspension of agency the authority, traditionally, cannot and should not be treating you or your property with reduced agency; the authority should not be preemptively diminishing your agency by starting that evidence collection process (compromising protections) with zero probably cause. It is the problem and responsibility of that authority, as set out by the social contract of free agents comprising our society, to reduce agency and collect evidence AFTER probably cause arises and NOT as the default against every citizen.

sqeaky 11y ago

This article ignores the complexity of not encrypting everything. What is the recourse for the average Joe when his social network doesn't encrypt logins? Facebook did this for years, the average user just ignored it and logged in, no amount of training or convincing could dissuade many. What will the user interface look like for a site that is not encrypted but verified secure? It is hard enough to get people verify the lock icon is green or gold. Many ignore and just assume that online shopping is so fraught with hackers that it cannot be done safely. This will not help that situation. Why do we care about the cost of CPU cycles? No matter how good the encryption is a human still needs to make a decision. Settling on a simple one helps the human make it faster. CPU cycles get cheaper every year but the brain hasn't improved in thousands. Encrypting everything is simple and can be made to work even for less technical people.

sqeaky 11y ago
As a secondary point even if don't get simplicity isn't incorrectly setup encryption, better than none? For one example: Self signed certificates don't protect you from a man in the middle perpetrated by the government or ISP, but they will stop neighbors with packet sniffers. If we forgo simplicity I will still encrypt what I can. Having only some protection is not the same as my protection being an illusion.

makmanalp 11y ago

I like this essay, not because I agree with most of its arguments, but because it raises interesting ones. What's frustrating about it, to me, is that the main thrust seems to be "There are problems with TLS, and especially using it everywhere", which is very valid. But then the message / proposed solution is "let's just give up on TLS except for what I arbitrarily define as important". What I would have hoped for is "let's try to make it better".

bonjarber 11y ago

>"this system is even larger than in the past and as such slip-ups are only going to increase.” Yes, the system is certainly larger (as is the internet as a whole) and slip-ups are natural. Luckily these 'slip ups' are typically simple things like certs expiring or supporting outdated cipher suites. These are just minor configuration fixes that things like Lets Encrypt aim to fix (both distribution and configuration of TLS). The thing is, even the worst 'slip ups' don't make you any more insecure than only supporting HTTP. _Any_ amount of TLS is better than none. That is a weak argument to start with. >"SSL is bloody expensive compared to not doing it." No it’s not. Certs are not expensive (another thing improved by Let’s Encrypt). This opinion exists from people spreading these kinds of rumors. It’s 2015 and the minor difference in processing power is negligible. If your web hosting can’t handle the difference in processing costs, you need to look for a better hosting platform. >"Not only does that mean that you are downloading a really big certificate, but also that the SSL encryption is a bit of a lie for you as a user.” 'Really big certificate' when has this been an issue for anyone ever? A CDN providing SSL is still better than no SSL. That "lie" _still_ protects the user at their host->Local Router->ISP->CDN. This is massive value not offered via just HTTP. >"The cost of deploying SSL should not be underestimated, and forcing SSL on people out of principle should consider that.” The cost raised by implementing SSL vs the cost of hosting a web application is negligible. It's pennies on the dollar to ensure your users can have a safer experience using your site. Security comes at a cost, this is part of life. >"The second method is to go to the local ISP and tell them to disable access to it. The rather is the better option in the sense that it only affects the citizens of that country and it isolates the problem. Unfortunately, SSL prevents this.” Yep it's a real shame that it's harder to censor websites. Joe Shmoe the intended reader shouldn't use SSL just in case the government wants to blacklist his domain. >"Even Ad providers (Superfish cough) started to destroy SSL traffic because it became so widespread that it was necessary. I'm firmly of the opinion that none of that would have happened if SSL traffic was less common. “ THE WHOLE REASON THESE AD PROVIDERS ARE BREAKING SSL IS BECAUSE THEY CAN NO LONGER WILLY NILLY READ/INJECT YOUR TRAFFIC. This exactly what Version + AT&T's "super cookie" was doing to HTTP traffic. SSL _prevents_ shit like this from happening. SSL being less common in no way equals less ads reading/injecting your content. >"The greatest impact on user's safety would have been the development of per user encryption for public Wifi access points.” This exists. It's called IPSec and it's a way bigger hassle than SSL, so we all agreed in the 90's that it made more sense to prioritize SSL over IPSec. >"Instead what happened is that now every larger website has to implement SSL to protect against the only realistic attack vector which is someone surfing at Starbucks.” This is absolutely false. I would argue the _most_ users are at risk further down the pipeline, not at Starbucks. We know for a fact that ISP's like Verizon have injected cookies into HTTP traffic leaving their networks and we know for a fact that Governments have done dragnet collections of HTTP traffic. SSL protects users at every step of their internet journey, suggesting half ass encryption is bullshit. >"I now no longer claim I have any understanding of SSL at all.” This is the most accurate statement he makes in the entire article. >"Cryptography is black magic.” Here in lies the problem. It's not. It's actually the opposite, it's open source and it's inner workings can be explained by a multitude of resources. The various features you call 'bugs' in SSL/TLS are things the security community has refined over many years. Crypto is hard, and a lot of things that seem intuitive are not. TLS exists in it's current state because it accomplishes what we want crypto to do. Saying "everyone fuck this thing I'm frustrated with" is counter productive to the whole process. ANY amount of SSL is better for the user than none. >"but the truth is that the most popular cryptography library (OpenSSL) is an old and complex mess. Even if the library itself would be okay, there are so many ways to misuse it and it's really badly documented.” Oh boi let's jump on the OpenSSL hate wagon. We know OpenSSL has had it's issues and there are lots of people helping to make it better (https://cryptoservices.github.io/…/2015/03/09/openssl-audit… https://cryptoservices.github.io/…/2015/03/09/openssl-audit…). The fact that OpenSSL has the occasional implementation error doesn't make the SSL/TLS protocol any worse. >"Gone are the days where you could fully understand how a web application works.“ This has gone from trying to make some kind of point to full whine fest. Yes, web applications have become complicated. So have all parts of technology. As things grow their internals become more intricate and complicated. Also gone are the days where you can fully understand the inner workings of your car engine. Doesn't mean we shouldn't use airbags. >"As of recently the Python package installer downloads every package via SSL. Why? There is no technical reason for this unless you want to hide from someone that you are downloading a specific Python package which seems pointless." Or you know, you don't want packages injected/swapped out with malware when you download them. If I'm downloading code I'm about to run on my system, you better be sure as hell I'm going to want to want integrity and confidentiality of said code. TLS is a standardized way of ensuring both of those things. >"It's plenty to download the package over an untrusted connection and to then verify the checksum with one you downloaded from a secure place." WHERE IS THIS MAGICALLY SECURE PLACE? HOW DOES ONE COMMUNICATE WITH THIS SECURE PLACE? For a guy who considers SSL to be too much effort, I'm to believe that everything he downloads is checked against checksums received via his 'secure place'