Comment by jasode | Hacker News Reader

Comment by jasode | Hacker News Reader

Parent Full thread

>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 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.

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.

>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 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.

A checksum does not guarantee anything, I can intercept that traffic in flight, alter it and put a new checksum in.

A signed checksum like an HMAC is much better.

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.

> 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.

>> 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 :)

Calculating the checksum of a document and encrypting this checksum is far less costly than encrypting the whole document.

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.

But it seems that nobody cares enough.

> 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.

The same applies to Python packages on PyPI etc.

W3C is working on a way to verify resources like web fonts without encryption.

http://www.w3.org/TR/SRI/

Good to know there are real cases for that! Maybe a solution will be adopted soon.

You can MITM the unencrypted page and cut that HTML tag out.

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.

Of course, I'm just arguing against the particular detailed proposal `nine_k` made.

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.

How do I verify the signature?

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.

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.

Set your ciphersuite to RSA_NONE_SHA256...

No common browsers support cipher suites without encryption.

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...

What does that solve? They can MITM to modify the clear text and the signature.

Encryption does not actually imply authenticity, some encryption methods can allow you to validate authenticity but it's not universal.

Reply on news.ycombinator.com