3 ms·

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

> 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 12y 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 12y 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 12y 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)
    - the_mitsuhiko 12y ago
      > 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.
      - Nursie 12y ago
        >> 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.
        the_mitsuhiko 12y ago
        > 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.
        12y ago

Nursie 12y 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 12y 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 12y 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)
  - the_mitsuhiko 12y ago
    > 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.
    - Nursie 12y ago
      >> 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.
      - the_mitsuhiko 12y ago
        > 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.
        12y ago