6 ms·

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 s

You can verify authenticity through signatures -- no need to encrypt the full body for that. The fact that there's no (widespread) general-purpose solution to sign arbitrary traffic is IMO problematic, people apparently are fine with just paying the cost of encryption.

nine_k 11y ago
When you want a piece of information be authentic, chances are high that the information is also of private nature. It would be trivial to add something like <rel signatory="https://this.same.domain/verify" https://this.same.domain/verify" algorithm="sha2"/> to any web page, or an HTTP header of the same nature, and run an HTTPS endpoint to check the url/signature pair. Probably international news agencies could run this, so that the proverbial China government would be able to see that a web page has nothing subversive on it, but anyone could see that the page has not been tampered with, by running a checksum against the page source. A browser extension could be used for that. But it seems that nobody cares enough.
- untitaker_ 11y ago
  You can MITM the unencrypted page and cut that HTML tag out.
  - sanxiyn 11y ago
    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.
    - untitaker_ 11y ago
      Of course, I'm just arguing against the particular detailed proposal `nine_k` made.
- the_mitsuhiko 11y ago
  > 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.
  - sanxiyn 11y ago
    W3C is working on a way to verify resources like web fonts without encryption. http://www.w3.org/TR/SRI/ http://www.w3.org/TR/SRI/
  - nine_k 11y ago
    Good to know there are real cases for that! Maybe a solution will be adopted soon.
jasode 11y ago
>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.
- sanxiyn 11y ago
  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.
- untitaker_ 11y ago
  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)
  - vtlynch 11y ago
    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.
quonn 11y ago
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.
dogma1138 11y ago
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_mitsuhiko 11y ago
  > 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.
  - Nursie 11y ago
    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_mitsuhiko 11y ago
      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.
      - Nursie 11y ago
        >> 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)
Lawtonfogle 11y ago
How do I verify the signature?
- untitaker_ 11y ago
  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.
  - Lawtonfogle 11y ago
    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.

nine_k 11y ago

When you want a piece of information be authentic, chances are high that the information is also of private nature. It would be trivial to add something like <rel signatory="https://this.same.domain/verify" https://this.same.domain/verify" algorithm="sha2"/> to any web page, or an HTTP header of the same nature, and run an HTTPS endpoint to check the url/signature pair. Probably international news agencies could run this, so that the proverbial China government would be able to see that a web page has nothing subversive on it, but anyone could see that the page has not been tampered with, by running a checksum against the page source. A browser extension could be used for that. But it seems that nobody cares enough.

untitaker_ 11y ago
You can MITM the unencrypted page and cut that HTML tag out.
- sanxiyn 11y ago
  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.
  - untitaker_ 11y ago
    Of course, I'm just arguing against the particular detailed proposal `nine_k` made.
the_mitsuhiko 11y ago
> 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.
- sanxiyn 11y ago
  W3C is working on a way to verify resources like web fonts without encryption. http://www.w3.org/TR/SRI/ http://www.w3.org/TR/SRI/
- nine_k 11y ago
  Good to know there are real cases for that! Maybe a solution will be adopted soon.

jasode 11y ago

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

sanxiyn 11y ago
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.
untitaker_ 11y ago
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)
- vtlynch 11y ago
  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.

quonn 11y ago

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.

dogma1138 11y ago

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_mitsuhiko 11y ago
> 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.
- Nursie 11y ago
  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_mitsuhiko 11y ago
    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.
    - Nursie 11y ago
      >> 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)

Lawtonfogle 11y ago

How do I verify the signature?

untitaker_ 11y ago
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.
- Lawtonfogle 11y ago
  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.