4 ms·

Your fundamental assumption is totally wrong. You simply cannot calculate the signature once and then store it and use it forever after, even for static content

by jamess 18y ago

Your fundamental assumption is totally wrong. You simply cannot calculate the signature once and then store it and use it forever after, even for static content. That leaves you open to a whole class of attacks from a simple replay on up. To protect yourself, you'd need at minimum a nonce supplied by the client per request. You've given no thought to exactly what the signature would be over, nor how having one or more untrusted caches between you and the client might affect the content. If you think you can merely sign the payload, not the headers, think again. Where exactly do cookies live? What effect can the status line have on a client's behaviour? Now ask yourself, what are caches allowed to do a request without stepping outside the bounds of the standard? Yes, exactly. You haven't addressed at all how the client would even get hold of the public key needed to verify the signature. You haven't addressed what the signature is over in the event the server uses some content encoding like gzip, or the chunked encoding. You don't even add the obvious and trivial optimisation that the signature would be best sent as a trailer rather than a header, neither do you define the behaviour if the server wishes to send trailer fields after the HTTP payload. The only thing that can be concluded from this is that you don't really understand security or indeed HTTP. I'm baffled by the attitude that you admit you don't know anything about these topics, but you're trying contribute something to the field anyway. This is completely arse backwards, and in no other field of endeavour would anyone even consider tolerating it. Would a peer reviewed biology journal look kindly on me if I sent them my thoughts on protein folding? I think not. The attitude that any software engineer can do security is prevalent in the industry and gets us in to ridiculous amounts of trouble. You wouldn't believe how many software and hardware products I've seen that are completely broken security wise thanks to this. If you're interested in the field, I'd suggest starting by reading the canonical introductory text, Secrets and Lies .(http://www.schneier.com/book-sandl.html http://www.schneier.com/book-sandl.html) This is not a field anyone is going to thank you if you want to learn on the job.

m_eiman 18y ago
I'll answer your final points first. To compare my brainstorming to trying to submit a paper to a journal isn't a relevant comparison. I'd say a better comparison would be a student saying to a teacher "You know I thought a bit about this folding thing, wouldn't it be possible to...?". If I were that student I would expect to get the answer "No, because ..." - which is indeed the answer I got. I don't know about you, but the best way for me to learn something is to try to do it, fail, learn something from the failure and try again. In some fields, like in security, it's better if that failure is someone on HN telling me that I'm a clueless moron rather than someone else stealing a million credit card numbers due to me being a clueless moron. Thanks for the reading suggestion, and sorry for wasting your time with uneducated ideas. On to some thoughts on the other points. The signature would be over the content in its original form, so if it was transferred using gzip encoding it'd be ungzippped before verifying the signature. Since headers need to be signed too (and possibly the status line), I'd have to add another header that specifies which headers are in the signature, and the client would need to drop any non-signed headers before doing anything with the content. I'll need to read more about what can happen to a request along the way, though. I'll need to add a header that specifies the URI of the content too, to prevent someone from switching the content of different URIs ('yes' button graphics for 'no' button graphics or something like that). I was going to use the normal PGP infrastructure to get public keys, but if I trust the keylist to contain valid PGP identifiers I might as well put the public keys there and skip the PGP step (when I wrote the draft, I had recently looked into PGP and I suppose that everything looked like a PGP-shaped nail at the time). Putting a signature in the content would break it for browsers that don't support Content-Signature, so that wouldn't do. Adding post-content headers isn't allowed by HTTP, as far as I know, so that would also break for non-supporting browsers. Thanks for your feedback, and I'll try not to have as many gaping holes in my next attempt! I'll also make sure that someone who actually knows his stuff is responsible for security if and when I make a product that relies on it.

by jamess 18y ago

m_eiman 18y ago

I'll answer your final points first. To compare my brainstorming to trying to submit a paper to a journal isn't a relevant comparison. I'd say a better comparison would be a student saying to a teacher "You know I thought a bit about this folding thing, wouldn't it be possible to...?". If I were that student I would expect to get the answer "No, because ..." - which is indeed the answer I got. I don't know about you, but the best way for me to learn something is to try to do it, fail, learn something from the failure and try again. In some fields, like in security, it's better if that failure is someone on HN telling me that I'm a clueless moron rather than someone else stealing a million credit card numbers due to me being a clueless moron. Thanks for the reading suggestion, and sorry for wasting your time with uneducated ideas. On to some thoughts on the other points. The signature would be over the content in its original form, so if it was transferred using gzip encoding it'd be ungzippped before verifying the signature. Since headers need to be signed too (and possibly the status line), I'd have to add another header that specifies which headers are in the signature, and the client would need to drop any non-signed headers before doing anything with the content. I'll need to read more about what can happen to a request along the way, though. I'll need to add a header that specifies the URI of the content too, to prevent someone from switching the content of different URIs ('yes' button graphics for 'no' button graphics or something like that). I was going to use the normal PGP infrastructure to get public keys, but if I trust the keylist to contain valid PGP identifiers I might as well put the public keys there and skip the PGP step (when I wrote the draft, I had recently looked into PGP and I suppose that everything looked like a PGP-shaped nail at the time). Putting a signature in the content would break it for browsers that don't support Content-Signature, so that wouldn't do. Adding post-content headers isn't allowed by HTTP, as far as I know, so that would also break for non-supporting browsers. Thanks for your feedback, and I'll try not to have as many gaping holes in my next attempt! I'll also make sure that someone who actually knows his stuff is responsible for security if and when I make a product that relies on it.