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.
> 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.
>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.
> 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.
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.
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.
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.
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.
> 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.
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).
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.
My point was designed to illustrate that TLS can be in some cases found to have considerable overheads in certain applications. For example, delivery of static content.
I'm not saying that it's relevant in most cases; but saying that the overhead of TLS is minimal is factually incorrect - in some relatively common cases it is anything but.
If a company like Netflix says that it'd cost them >$100M per year to deliver their already encrypted content using TLS (recently they've got those costs down, but they still say it's expensive), I'm more inclined to listen to them saying that TLS has real costs (because they've done the analysis) than you saying it doesn't.
Netflix aren't the only ones. It's CDNs in general - a modern processor will decrypt and encrypt AES at about 1Gbps per core; meaning that you're talking about (for a high-throughput server) needing a lot of compute in addition to a lot of ram.
I'm sure that it can be worked around (Cloudflare apparently worked with Intel to optimise their version of OpenSSL), but certainly what Google or Cloudflare do won't necessarily apply to what everyone else does, and Cloudflare's not exactly known for serving large files.
Again, this is more a 'don't assume what works for you works for everyone' and not at all a 'it's wrong in every case' type point.
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/
> "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.
>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.
How would you bootstrap a secure encrypted login for a user who was browsing the site without SSL? I agree with you that anonymous data access is often encrypted unnecessarily, but in practice deploying HTTPS is an all-or-nothing deal.
> How would you bootstrap a secure encrypted login for a user who was browsing the site without SSL?
If you have a website where users sign in you are pretty much left with SSL from the sign-in form on but you can move an indirection between the sign in and out so that a user has a chance to verify they are authenticating on the right site. Fundamentally there is no difference from the user's perspective for as long you are okay with moving the log-in box to a secure URL where the user can check the authentication.
>> 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.
Excellent. It means that it's a lot more out in the open and noticeable.
>> owever 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.
Also good, making sure there's a lot of uninteresting stuff under encryption means that the interesting stuff stands out less.
Also makes it harder for ISPs to alter content or inject advertising. A good thing.
> 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.
Good. Censorship and other attacks should be as noisy, obtrusive, and damaging as possible, so that we have more incentive to stop it (by both legal and technical means). Such attacks should not pass silently.
> 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.
Why do you need to use them in the absence of SSL?
Many ridiculously tiny devices still have enough power to run a simple TLS stack. And if you're really trying to access web services from some potato-powered device that can't run a TLS stack, you have much the same problems as a device that can't run a fully capable network stack at all. In either case, speak a simpler encrypted protocol (e.g. Bluetooth Low Energy, 6LoWPAN) to a local device, that can either provide the services you need or access them on your behalf.
> Good. Censorship and other attacks should be as noisy, obtrusive, and damaging as possible
Agreed. It's human nature to not bother to speak up when a group you're not a part of is attacked. If widespread encryption means that more people will be affected when governments try to censor traffic, then I'd say we have one more argument for widespread encryption. http://hmd.org.uk/resources/poetry/first-they-came-pastor-ma...
>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.
Good. Make the censorship visible. Make it all or nothing. Force people to move to technologies that cannot be censored (or that at least are more resistant).
The alternative is to let the government censor everything they want and let people see only what the government approves of, with the latter just being easier to deploy and switch to the former if it ever crosses the line.
>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.
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.
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" 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.
You can send (lightweight) HTML page and subresource hashes in secure channel, and deliver fonts and images and videos in cleartext without compromising on integrity.
> When you want a piece of information be authentic, chances are high that the information is also of private nature.
That's not true at all. For instance that we fetch web fonts via SSL is just because there is no other way to verify the identity of the webfont otherwise. There is nothing inherently private about a web font.
>You can verify authenticity through signatures -- no need to encrypt the full body for that.
If NYT or Yahoo Finance has a javascript widget to let a reader pick a stock symbol, and dynamically choose start and end points of stock performance, what "body of text" is relevant to compute a "signature"? What if the NYT has an option to dynamically translate their stories into other languages, or rotate different related stories on a sidebar? Are servers constantly regenerating thousands of signatures for all unforseen combinations of dynamic text? And how do these multiple signatures continuously travel from the server to the browser? Presumably it would be an encrypted channel because cleartext signatures would be vulnerable to tampering. Would a browser then have twin-channels (2 ports) open for the NYT page? One channel is encrypted for the signatures and the other channel is the cleartext? Why would this scheme be "better"? You still have encryption somewhere.
Cleartext+signature is better, because, 1. signature can be much smaller than cleartext, so encryption cost is less, 2. cleartext can be inspected, 3. for static content, signature can be precomputed (can't do that with TLS), 4. for static content, cleartext can be sent as-is, for example using sendfile (can't do that with TLS), and possibly more advantages I haven't thought of in 5 minutes.
I suppose you have some encryption in this (I'm no expert), I'm only arguing against encrypting the full body, because for larger downloads, full-body encryption might cause extreme overhead (think Netflix or Steam)
Except even Netflix has recently announced they are going to be performing "Full Body" encryption on their video streams and that it was financially worth it for them to do so.
You can make value based arguments for/against pervasive encryption, but technical arguments against it continue to be debunked.
Not sure where you get the idea that anecdotes count as "technical arguments", but let's stay with the Netflix example: According to another comment in this thread, Netflix measured severe performance drops with SSL: https://news.ycombinator.com/item?id=9465553
Not sure how one of the largest sites on the internet with intensive bandwidth successfully implementing encryption is anecdotal. Performance drop or not, they implemented it because they find the benefits to outweigh the costs.
Netflix, and many others before them, have demonstrated it is possible to do so. Obviously there is an impact.
But many people like to immediately say, "its too resource intensive! it cant be done! its not practical". Those people are wrong. It's expensive. It may take engineers. But it can be done.
The cost (e.g. for obtaining and updating certificates) would be the same. You might save some CPU cycles, but only if the content is completely static.
The cost of signing a document is virtually the same as encrypting it since for example PKI signatures are encryption with your private key which then are decrypted with the public one the validate "authenticity"
For other operations that provide authenticity like an HMAC it's the same deal, the good thing about having a cryptographic MAC assigned to a message is that you can easily compress the entire message in transit and now have to force clients to compress the message prior to encryption.
> The cost of signing a document is virtually the same as encrypting it since for example PKI signatures are encryption with your private key which then are decrypted with the public one the validate "authenticity"
The cost of putting a checksum on a document however is tiny in comparison. Any many of the cases where we currently fetch resources from CDNs there is no reason we could not leave out the SSL and instead reference assets by SHA1.
The checksum is obviously transmitted out of line on a secure channel.
And even if we would go back to cryptographically signing resources you still benefit from it tremendously speed wise because after the initial signing, you can serve up the same data to everyone directly from memory or filesystem. Your argument does not work either way.
>> The checksum is obviously transmitted out of line on a secure channel.
Then you have all the problems of setting up a second, secure channel. This would seem to increase complexity, not decrease it.
>> And even if we would go back to cryptographically signing resources you still benefit from it tremendously speed wise because after the initial signing, you can serve up the same data to everyone directly from memory or filesystem.
Sure, if all your data is static this might help in terms of speed, you could drop some of the TLS overhead, though not all of it because you've still got to somehow verify a server signing key or your 'out of line' channel (which is probably going to have to be authenticated and integrity checked itself now.... TLS seems a good way to achieve this)
> Then you have all the problems of setting up a second, secure channel. This would seem to increase complexity, not decrease it.
It reduces the total number of endpoints that need to go through SSL. That is a win complexity wise. I do not need to hand over SSL keys to my CDN for instance. I just put the file there and keep my checksum list on a server I actually do control the keys on. As an example. That is reducing complexity and makes it more secure in the process. At the cost of people knowing which files are downloaded.
>> It reduces the total number of endpoints that need to go through SSL. That is a win complexity wise. I do not need to hand over SSL keys to my CDN for instance. I just put the file there and keep my checksum list on a server I actually do control the keys on.
So each asset loading connection now requires two connections, one to the content-holder or cache and another to the reference server. I'm not sure this is really reducing complexity. Plus you now need another server that's prepared to accept just as many connections as the CDN to serve signatures, likely increasing latency. I would be surprised if the total compute power and cost comes down very much with this scheme.
I can see how it helps server security in this case, reducing private-key proliferation.
>> At the cost of people knowing which files are downloaded.
Yes, this is still the case, that an observer will know exactly what assets you are loading.
> So each asset loading connection now requires two connections, one to the content-holder or cache and another to the reference server.
No. If you do it checksum based the checksum is embedded at the place where the asset is referenced from which is an encrypted page. There is even a spec for this in the context of web resources already.
If you do it with cryptographic signing then the same rule applies as with SSL, you just skip the encryption. This is not rocket science.
>> If you do it checksum based the checksum is embedded at the place where the asset is referenced from which is an encrypted page
So you are still loading an encrypted page from somewhere? This scheme gets more complex by the post! I think by extracting this idea from your head piecemeal we have confused me!
Let's see if I have this straight -
I browse to https://www.example.com and get served a page that is authenticated and integrity-checked, but not encrypted. Probably via TLS in NULL cipher mode. Embedded in that page are simple sha2 (sha1 is bad, collisions may be possible) hashes of all the images etc that I need to load. The CDN provides these and I can verify the hashes against what I'm expecting.
OK, you've removed protocol overhead on the assets (if they are binary assets this is likely a very small percentage). And you've removed encryption from everywhere. This allows people to get a verified page that's not secret. There's no reason I can think of this would not work. You're still having to give your private key to any third party cache/front-end that serves your HTML.
At this point we're down to an idealogical argument - I think crypto-everywhere is good because I prefer as little information as possible to leak to any interested parties, regardless of how sensitive it is, and because using crypto on everything helps to hide the important stuff. You would rather some things be observable, and don't think the overheads are justified. This we are not going to resolve :)
> I do not need to hand over SSL keys to my CDN for instance.
You shouldn't do that anyway. If you want to offload your large files to a CDN without compromising your SSL traffic, just have your CDN serve your huge files from yoursite.thecdn.com, for which they legitimately can have an SSL certificate, and then serve your checksums from yoursite.com, for which you have an SSL certificate.
I'm not a cryptographer, so I don't know the details on how signatures work, but this problem is already solved. It doesn't matter whether you have to have to establish a sidechannel for the signature -- it should still pay off for larger downloads.
So we would still have to rely on encryption. The system is now more complicated for the benefit of saving a few CPU cycles and allowing everyone to read the content of the message. When we tend to have plenty of CPU cycles to spare this trade off looks like a loss even not counting privacy as a virtue in and of itself.
Encryption bundles orthogonal concerns, authenticity and confidentiality. Since there are situations confidentiality is not desired (see OP), I think we should work on making cleartext+signature easier.
True, and this is largely a good thing - if you actually want a secure connection you do not want your browser accepting a NULL cipher suite and saying "Hey! I'm using TLS!"
There's no reason why browser-makers couldn't put in a capability to fetch some resources this way, without telling the user that what thy are doing is 'secure'.
However by the time you've done your RSA verification and a per-packet SHA256 HMAC or similar, the overhead of AES encrypting the data might not actually be all that much more...
This stance implies that the complexity of having some systems or parts of systems encrypted, but not others is without cost.
I would not be able to teach my grandmother the UI of this system, she has a hard time with chrome's SSL lock icon as it is. Encrypting everything is a great situation for her so she can shop online safely.
You certainly can have authenticity without encryption - just think of how Debian package downloads are authenticated with gpg. In fact this option is built into TLS - RSA/SHA with the null cipher suite.
It doesn't solve the CA problem or the cost problem (you still have the whole cost of setting up a TLS session, actually encrypting the payload is the cheap part). But it's possible.
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.
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.
> 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.
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.
Among the informed. The government will try to push that idea that encrypting everything means that you get drug lords, child molesters, and terrorist running wild while not encrypting will mean all the former will be caught and society will be safe and happy.
... as justified by many arguments from ignorance, like "I don't think everyone ...", and "There is no technical reason..." over and over. Even one counterexample for those (some helpfully supplied in comments hereabouts) makes the arguments invalid.
> ... as justified by many arguments from ignorance, like "I don't think everyone ...", and "There is no technical reason..." over and over. Even one counterexample for those (some helpfully supplied in comments hereabouts) makes the arguments invalid.
I gave one very practical example of encryption being applied to file transfers without a technical reason why that has to be. The same applies to the majority of resources fetched from CDNs. The only reason we use SSL for that is because there is no other method that browsers currently support for guaranteeing the integrity of the loaded information.
Authentication and Integrity are just as much part of SSL/TLS as secrecy is. For code I'm going to run on my system, I quite like the idea that I can tell where it comes from and if it's correct.
When it comes down to it, it's nobody else's business what python code-modules I'm downloading, it might give them enough information to attack my servers, so secrecy isn't a bad thing either.
To be fair, Armin presented the solution to the first argument in the form of checksums. Your 2nd argument is valid though.
I also think it's a bit of a shame that we're having to do all this encryption these days. Think of all that wonderful caching capability we're losing. Still, I come down on the side of "necessary evil", given the increasingly malicious attacks on parties that aren't using it.
> When it comes down to it, it's nobody else's business what python code-modules I'm downloading, it might give them enough information to attack my servers, so secrecy isn't a bad thing either.
There is much bigger issue there: nobody verifies package signatures. Most packages do not even have ones. So you fundamentally have no way to verify that what you downloaded is what you wanted. Someone could have stolen my PyPI access credentials and uploaded a broken package under one of my releases.
Or I'm just a bad person and would ship you bad code.
> This is bad practice, and is not solved by less integrity and authenticity checking!
No, it's a completely orthogonal issue which was my point. But you were bringing up a potential security issue which is that people might know what packages you are using. I'm bringing up that you are installing completely untrusted packages which is your actual issue there, not that someone might be able to know what you are using.
Let alone that with AGPL libraries for instance you are required to disclose that anyways.
>> I'm bringing up that you are installing completely untrusted packages which is your actual issue there, not that someone might be able to know what you are using.
There are multiple 'actual' issues here.
One, you have identified, is that the content on the server is not very well verified. This is a problem I agree, and solutions are likely non-trivial. TLS will not fix this for you.
The second one is making sure that what is on the server is accurately replicated on the client. Authentication (am I talking to the real server?) and integrity checking (did I really get what the server tried to send me?) are important here. TLS can address this.
The third is giving away information about modules installed, which may be another risk. TLS will mitigate this.
You're right that the AGPL would require you to disclose to any user which modules are in use and give over the source to anyone that uses your service and asks for it, and in general security by obscurity is a bad idea anyway - however I may not have users, I may be setting up a server only for me to access, and I may not want passive traffic sniffers to know that my experimental server is likely to be running an easily-compromised version of a service for the next five minutes until I patch it.
That certainly helps repeatability of install, but it doesn't (so far as I can tell) help if you've been MITM'd on first download. So it's a bit like a self-signed certificate at that point.
See, there's an argument that women should not wear short skirts and tank tops, because this provokes potential rapists. Better safe than sorry, no?
While this may make short-term practical sense, it's fundamentally wrong. Nobody should be raped, short skirt or not. It's the law enforcement that needs to change and prevent such things, not women. Women, if anything, should carry pepper spray.
Same thing applies to the privacy of communication. Nobody should be a subject to an unreasonable search. Yes, having your communication open provokes any number of three-letter agencies to want to snoop on it, just in case. And if they find it encrypted, they want to crack it — again, just in case. Why not yield?
Again, this is fundamentally wrong, it goes against the letter of the law and the spirit of it. It's the law enforcement that needs to change, not citizens. First have a probable case, preferably a court order, etc. Citizens, id anything, should use encryption more.
> See, there's an argument that women should not wear short skirts and tank tops, because this provokes potential rapists. Better safe than sorry, no?
This discussion went emotional very quickly.
> It's the law enforcement that needs to change, not citizens.
Last time I was looking there was no world government. What a country has to do and does not have to do is fundamentally decided by it's lawmakers. In some countries those are elected, in others they are not. I'm a programmer and as such I limit my general impact on technical things. I might have the opportunity to shape legislation but I do not claim that I know what every country should do.
This argument was not intended to be emotional; it's just a bit less technical and more down-to-earth. Unfortunately, when we're looking at what is right or wrong thing to do, some emotions inevitably wake up. Still, the same point can be made using strictly rational arguments, both from first principles or from practice and history.
Also please note that nobody is forced to wear revealing skirts or use concealing encryption. You are free to do what you think is right. I very much appreciate what you do, and wish you to continue unhindered. I hope we can disagree on the point of usefulness of encryption in certain cases without affecting everything else.
> 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.
The very next sentence of TFA is, "As there is no need to operate on a partial file there is no technical reason why the entire transfer would have to be SSL encrypted." Clearly, the procedure envisioned is that the checksum is served over TLS.
So then what? Am I supposed to connect to multiple servers, one for SHAs and the other for blobs? What is the point of that? To be fair, by this point in the article I was just skimming it.
Checksums can be simply listed on TLS-enabled websites, or in PGPed emails, or whatever. They don't need to be on CDNs, which in many cases would be indicated for software distribution. The other thing to keep in mind is that a checksum can certify the entire distribution process, from a packager's personal machine all the way to your hard drive. TLS only proves that no one eavesdropped on the connection between your client and whatever machine claims to be the CDN, which for software distribution is pointless and unhelpful.
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.
> 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.
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.
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.
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.
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.
>> 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.
I think you are misrepresenting the position opposed to you.
Pro-encryption people think that blindly trusting government is a bad idea because that trust is too easy to abuse, and cryptography is needed to maintain individual autonomy in a digital world so as to enable individuals to exert their democratic power over the government, so that policy changes can still happen in a democratic process in the future.
Also, you might want to think about why you would not call it a "decree from elites" if the same people decided to not offer encryption, thus not giving individuals the option to encrypt their data as they wish. Or would you?
>Government has rightful authority justified by democratic process.
This is satire, right?
Non-democratic governments.
Tyranny of the majority.
Independent agencies with the ability to blackmail those in authority.
>not by decree from elites using technology such as encryption
We aren't forcing you to encrypt. You can post your credit card number in plain text on any forums you like. You can choose to only use websites that allow http and choose to always use http.
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 ...
This is a really interesting argument you've advanced. The chart you describe is illustrative and the changes wrought on it certainly disturbing.
Unfortunately, I think you have over-simplified a complex issue to a dichotomy (encrypt everything or nothing) that is perhaps more confusing than helpful.
Encryption is a broad and diverse subject, as well as a field of expertise (not mine). I doubt parties in the debate have axioms that align here as there are so many interpretations and levels of detail to disagree about. Put more clearly I don't think any three people reading this would agree on what you mean by encryption in your post.
If you instead said "protect" "everything" / all traffic / all data/ all browsing /... , and gave some details as to the threats you are concerned about, it might strengthen the argument you are making.
EG : "protect" the "names of sites I visit" from sousveillance ... "protect" the "integrity of software packages I download" from "evilgrade" attacks ... protect "the pseudo-anonymity" of "journalists posting to social networks" from "state sponsored malware injection" ... and so on. Encryption techniques could be (are) used against all of these problems, but in different ways.
There is a lot to discuss and try to understand in these issues. Thank you for contributing positively to the discussion ( and I hope I am as well).
> 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.)
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.
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?
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.
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.
> 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.
> 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.
>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 we are dealing with intelligent actors instead of unguided evolution. They will go after those tools as long as anyone could possibly use SSL.
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.
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.
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.
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.
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.
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".
>"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 ope...
133 comments
[ 2.8 ms ] story [ 191 ms ] thread> 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?
> I'm sorry I don't hate freedom like you.
...and you just destroyed your own argument with the ad hominems.
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).
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.
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.
> 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.
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?
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.
There you go, a counterexample for your blatant overgeneralization.
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.
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
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.
ISPs have incentives too (advertising, user tracking, etc).
From your link: "The servers are also designed to deliver between 10Gbps and 40Gbps of continuous bandwidth utilization"
So how many terabits per second are you pushing out? Oh… oh you're not? You're not network bound at all? Well then…
And for reference: https://www.entrust.com/ssl-is-not-computationally-expensive... https://devcentral.f5.com/articles/dispelling-the-new-ssl-my... From 2011
> Google do it because their content is more dynamic
Isn't Youtube SSL?
I'm not saying that it's relevant in most cases; but saying that the overhead of TLS is minimal is factually incorrect - in some relatively common cases it is anything but.
If a company like Netflix says that it'd cost them >$100M per year to deliver their already encrypted content using TLS (recently they've got those costs down, but they still say it's expensive), I'm more inclined to listen to them saying that TLS has real costs (because they've done the analysis) than you saying it doesn't.
Netflix aren't the only ones. It's CDNs in general - a modern processor will decrypt and encrypt AES at about 1Gbps per core; meaning that you're talking about (for a high-throughput server) needing a lot of compute in addition to a lot of ram.
I'm sure that it can be worked around (Cloudflare apparently worked with Intel to optimise their version of OpenSSL), but certainly what Google or Cloudflare do won't necessarily apply to what everyone else does, and Cloudflare's not exactly known for serving large files.
Again, this is more a 'don't assume what works for you works for everyone' and not at all a 'it's wrong in every case' type point.
"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/
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.
How would you bootstrap a secure encrypted login for a user who was browsing the site without SSL? I agree with you that anonymous data access is often encrypted unnecessarily, but in practice deploying HTTPS is an all-or-nothing deal.
If you have a website where users sign in you are pretty much left with SSL from the sign-in form on but you can move an indirection between the sign in and out so that a user has a chance to verify they are authenticating on the right site. Fundamentally there is no difference from the user's perspective for as long you are okay with moving the log-in box to a secure URL where the user can check the authentication.
Excellent. It means that it's a lot more out in the open and noticeable.
>> owever 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.
Also good, making sure there's a lot of uninteresting stuff under encryption means that the interesting stuff stands out less.
Also makes it harder for ISPs to alter content or inject advertising. A good thing.
Good. Censorship and other attacks should be as noisy, obtrusive, and damaging as possible, so that we have more incentive to stop it (by both legal and technical means). Such attacks should not pass silently.
> 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.
Why do you need to use them in the absence of SSL?
Many ridiculously tiny devices still have enough power to run a simple TLS stack. And if you're really trying to access web services from some potato-powered device that can't run a TLS stack, you have much the same problems as a device that can't run a fully capable network stack at all. In either case, speak a simpler encrypted protocol (e.g. Bluetooth Low Energy, 6LoWPAN) to a local device, that can either provide the services you need or access them on your behalf.
Agreed. It's human nature to not bother to speak up when a group you're not a part of is attacked. If widespread encryption means that more people will be affected when governments try to censor traffic, then I'd say we have one more argument for widespread encryption. http://hmd.org.uk/resources/poetry/first-they-came-pastor-ma...
Good. Make the censorship visible. Make it all or nothing. Force people to move to technologies that cannot be censored (or that at least are more resistant).
The alternative is to let the government censor everything they want and let people see only what the government approves of, with the latter just being easier to deploy and switch to the former if it ever crosses the line.
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.
It would be trivial to add something like <rel signatory="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.
That's not true at all. For instance that we fetch web fonts via SSL is just because there is no other way to verify the identity of the webfont otherwise. There is nothing inherently private about a web font.
The same applies to Python packages on PyPI etc.
http://www.w3.org/TR/SRI/
If NYT or Yahoo Finance has a javascript widget to let a reader pick a stock symbol, and dynamically choose start and end points of stock performance, what "body of text" is relevant to compute a "signature"? What if the NYT has an option to dynamically translate their stories into other languages, or rotate different related stories on a sidebar? Are servers constantly regenerating thousands of signatures for all unforseen combinations of dynamic text? And how do these multiple signatures continuously travel from the server to the browser? Presumably it would be an encrypted channel because cleartext signatures would be vulnerable to tampering. Would a browser then have twin-channels (2 ports) open for the NYT page? One channel is encrypted for the signatures and the other channel is the cleartext? Why would this scheme be "better"? You still have encryption somewhere.
You can make value based arguments for/against pervasive encryption, but technical arguments against it continue to be debunked.
Netflix, and many others before them, have demonstrated it is possible to do so. Obviously there is an impact.
But many people like to immediately say, "its too resource intensive! it cant be done! its not practical". Those people are wrong. It's expensive. It may take engineers. But it can be done.
For other operations that provide authenticity like an HMAC it's the same deal, the good thing about having a cryptographic MAC assigned to a message is that you can easily compress the entire message in transit and now have to force clients to compress the message prior to encryption.
The cost of putting a checksum on a document however is tiny in comparison. Any many of the cases where we currently fetch resources from CDNs there is no reason we could not leave out the SSL and instead reference assets by SHA1.
A signed checksum like an HMAC is much better.
And even if we would go back to cryptographically signing resources you still benefit from it tremendously speed wise because after the initial signing, you can serve up the same data to everyone directly from memory or filesystem. Your argument does not work either way.
Then you have all the problems of setting up a second, secure channel. This would seem to increase complexity, not decrease it.
>> And even if we would go back to cryptographically signing resources you still benefit from it tremendously speed wise because after the initial signing, you can serve up the same data to everyone directly from memory or filesystem.
Sure, if all your data is static this might help in terms of speed, you could drop some of the TLS overhead, though not all of it because you've still got to somehow verify a server signing key or your 'out of line' channel (which is probably going to have to be authenticated and integrity checked itself now.... TLS seems a good way to achieve this)
It reduces the total number of endpoints that need to go through SSL. That is a win complexity wise. I do not need to hand over SSL keys to my CDN for instance. I just put the file there and keep my checksum list on a server I actually do control the keys on. As an example. That is reducing complexity and makes it more secure in the process. At the cost of people knowing which files are downloaded.
So each asset loading connection now requires two connections, one to the content-holder or cache and another to the reference server. I'm not sure this is really reducing complexity. Plus you now need another server that's prepared to accept just as many connections as the CDN to serve signatures, likely increasing latency. I would be surprised if the total compute power and cost comes down very much with this scheme.
I can see how it helps server security in this case, reducing private-key proliferation.
>> At the cost of people knowing which files are downloaded.
Yes, this is still the case, that an observer will know exactly what assets you are loading.
No. If you do it checksum based the checksum is embedded at the place where the asset is referenced from which is an encrypted page. There is even a spec for this in the context of web resources already.
If you do it with cryptographic signing then the same rule applies as with SSL, you just skip the encryption. This is not rocket science.
So you are still loading an encrypted page from somewhere? This scheme gets more complex by the post! I think by extracting this idea from your head piecemeal we have confused me!
Let's see if I have this straight -
I browse to https://www.example.com and get served a page that is authenticated and integrity-checked, but not encrypted. Probably via TLS in NULL cipher mode. Embedded in that page are simple sha2 (sha1 is bad, collisions may be possible) hashes of all the images etc that I need to load. The CDN provides these and I can verify the hashes against what I'm expecting.
OK, you've removed protocol overhead on the assets (if they are binary assets this is likely a very small percentage). And you've removed encryption from everywhere. This allows people to get a verified page that's not secret. There's no reason I can think of this would not work. You're still having to give your private key to any third party cache/front-end that serves your HTML.
At this point we're down to an idealogical argument - I think crypto-everywhere is good because I prefer as little information as possible to leak to any interested parties, regardless of how sensitive it is, and because using crypto on everything helps to hide the important stuff. You would rather some things be observable, and don't think the overheads are justified. This we are not going to resolve :)
You shouldn't do that anyway. If you want to offload your large files to a CDN without compromising your SSL traffic, just have your CDN serve your huge files from yoursite.thecdn.com, for which they legitimately can have an SSL certificate, and then serve your checksums from yoursite.com, for which you have an SSL certificate.
There's no reason why browser-makers couldn't put in a capability to fetch some resources this way, without telling the user that what thy are doing is 'secure'.
However by the time you've done your RSA verification and a per-packet SHA256 HMAC or similar, the overhead of AES encrypting the data might not actually be all that much more...
I would not be able to teach my grandmother the UI of this system, she has a hard time with chrome's SSL lock icon as it is. Encrypting everything is a great situation for her so she can shop online safely.
It doesn't solve the CA problem or the cost problem (you still have the whole cost of setting up a TLS session, actually encrypting the payload is the cheap part). But it's possible.
>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.
sslsniff was released over a decade ago.
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.
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.
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.
... as justified by many arguments from ignorance, like "I don't think everyone ...", and "There is no technical reason..." over and over. Even one counterexample for those (some helpfully supplied in comments hereabouts) makes the arguments invalid.
I gave one very practical example of encryption being applied to file transfers without a technical reason why that has to be. The same applies to the majority of resources fetched from CDNs. The only reason we use SSL for that is because there is no other method that browsers currently support for guaranteeing the integrity of the loaded information.
When it comes down to it, it's nobody else's business what python code-modules I'm downloading, it might give them enough information to attack my servers, so secrecy isn't a bad thing either.
I also think it's a bit of a shame that we're having to do all this encryption these days. Think of all that wonderful caching capability we're losing. Still, I come down on the side of "necessary evil", given the increasingly malicious attacks on parties that aren't using it.
There is much bigger issue there: nobody verifies package signatures. Most packages do not even have ones. So you fundamentally have no way to verify that what you downloaded is what you wanted. Someone could have stolen my PyPI access credentials and uploaded a broken package under one of my releases.
Or I'm just a bad person and would ship you bad code.
SSL does not solve that problem.
This is bad practice, and is not solved by less integrity and authenticity checking!
>> Or I'm just a bad person and would ship you bad code.
Nobody said it solves everything, but it does help prevent unrelated third parties getting in on the act, actively or passively.
No, it's a completely orthogonal issue which was my point. But you were bringing up a potential security issue which is that people might know what packages you are using. I'm bringing up that you are installing completely untrusted packages which is your actual issue there, not that someone might be able to know what you are using.
Let alone that with AGPL libraries for instance you are required to disclose that anyways.
There are multiple 'actual' issues here.
One, you have identified, is that the content on the server is not very well verified. This is a problem I agree, and solutions are likely non-trivial. TLS will not fix this for you.
The second one is making sure that what is on the server is accurately replicated on the client. Authentication (am I talking to the real server?) and integrity checking (did I really get what the server tried to send me?) are important here. TLS can address this.
The third is giving away information about modules installed, which may be another risk. TLS will mitigate this.
You're right that the AGPL would require you to disclose to any user which modules are in use and give over the source to anyone that uses your service and asks for it, and in general security by obscurity is a bad idea anyway - however I may not have users, I may be setting up a server only for me to access, and I may not want passive traffic sniffers to know that my experimental server is likely to be running an easily-compromised version of a service for the next five minutes until I patch it.
While this may make short-term practical sense, it's fundamentally wrong. Nobody should be raped, short skirt or not. It's the law enforcement that needs to change and prevent such things, not women. Women, if anything, should carry pepper spray.
Same thing applies to the privacy of communication. Nobody should be a subject to an unreasonable search. Yes, having your communication open provokes any number of three-letter agencies to want to snoop on it, just in case. And if they find it encrypted, they want to crack it — again, just in case. Why not yield?
Again, this is fundamentally wrong, it goes against the letter of the law and the spirit of it. It's the law enforcement that needs to change, not citizens. First have a probable case, preferably a court order, etc. Citizens, id anything, should use encryption more.
This discussion went emotional very quickly.
> It's the law enforcement that needs to change, not citizens.
Last time I was looking there was no world government. What a country has to do and does not have to do is fundamentally decided by it's lawmakers. In some countries those are elected, in others they are not. I'm a programmer and as such I limit my general impact on technical things. I might have the opportunity to shape legislation but I do not claim that I know what every country should do.
Also please note that nobody is forced to wear revealing skirts or use concealing encryption. You are free to do what you think is right. I very much appreciate what you do, and wish you to continue unhindered. I hope we can disagree on the point of usefulness of encryption in certain cases without affecting everything else.
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.
You're right.
To the author: What, pray tell, is this magical secure place that's secure despite not being authenticated or encrypted?
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.
"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.
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.
On a social level, I don't find any of the arguments convincing. The positives of ensuring private communication far outweigh the negatives.
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.
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.
Pro-encryption people think that blindly trusting government is a bad idea because that trust is too easy to abuse, and cryptography is needed to maintain individual autonomy in a digital world so as to enable individuals to exert their democratic power over the government, so that policy changes can still happen in a democratic process in the future.
Also, you might want to think about why you would not call it a "decree from elites" if the same people decided to not offer encryption, thus not giving individuals the option to encrypt their data as they wish. Or would you?
This is satire, right?
Non-democratic governments. Tyranny of the majority. Independent agencies with the ability to blackmail those in authority.
>not by decree from elites using technology such as encryption
We aren't forcing you to encrypt. You can post your credit card number in plain text on any forums you like. You can choose to only use websites that allow http and choose to always use http.
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 ...
Unfortunately, I think you have over-simplified a complex issue to a dichotomy (encrypt everything or nothing) that is perhaps more confusing than helpful.
Encryption is a broad and diverse subject, as well as a field of expertise (not mine). I doubt parties in the debate have axioms that align here as there are so many interpretations and levels of detail to disagree about. Put more clearly I don't think any three people reading this would agree on what you mean by encryption in your post.
If you instead said "protect" "everything" / all traffic / all data/ all browsing /... , and gave some details as to the threats you are concerned about, it might strengthen the argument you are making.
EG : "protect" the "names of sites I visit" from sousveillance ... "protect" the "integrity of software packages I download" from "evilgrade" attacks ... protect "the pseudo-anonymity" of "journalists posting to social networks" from "state sponsored malware injection" ... and so on. Encryption techniques could be (are) used against all of these problems, but in different ways.
There is a lot to discuss and try to understand in these issues. Thank you for contributing positively to the discussion ( and I hope I am as well).
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.)
[1] https://www.eff.org/deeplinks/2014/11/verizon-x-uidh
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.
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.
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/
Except we are dealing with intelligent actors instead of unguided evolution. They will go after those tools as long as anyone could possibly use SSL.
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.
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.
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.
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.
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".
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 ope...