3 ms·

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

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

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

JoshTriplett 12y ago

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