3 ms·

Ever hear the term "computationally expensive"? Here's a hint, modular exponentiation of very big numbers is an extremely expensive operation. Encrypting a bloc

by jamess 18y ago

Ever hear the term "computationally expensive"? Here's a hint, modular exponentiation of very big numbers is an extremely expensive operation. Encrypting a block of plaintext with a bulk cipher is a very cheap operation. Thanks to the marvels of HTTP keep-alive and TLS session resumption, serving the content over HTTPS is almost guaranteed cheaper than employing this crude hack. This is not even to touch upon the problems not addressed like the HTTP response is designed to be mutable, or that this "solution" offers no replay protection. Also, two words; Hash MAC. Want a real solution to the problem, here: http://www.sun.com/products/networking/sslaccel/suncryptoaccel6000/index.xml http://www.sun.com/products/networking/sslaccel/suncryptoacc...

brk 18y ago
So then, you're not too fond of his suggestion?
- jamess 18y ago
  I think that would be a fair assessment, yes. Classic case of person with no security training or experience trying to do security. The more I read it, the more painful it seems. You have to do a TLS handshake with the server anyway to get the bloody keylist (apparently the idea of certificate extensions is a bit too much to grasp) so if you have TLS, and you've already established a session why on earth would you need or want to employ this hack?
  - pedalpete 18y ago
    actually, in defense of m_eiman, i don't think you are being completely fair. Though your technical abilities clearly outweigh his (and mine, and many if not most here on HackerNews), your response sounds somewhat insulting, and I hope i am just misunderstanding your tone. You say this is a 'Classic case of a person with no security training or experience trying to do security'. That is not what m_eiman is trying to do at all. What is trying to be accomplished is to remove an security warning when there is not threat. Not everybody careas about 'certificate extensions',and I know i've never looked it up myself, but the point of the original 37 Signals post, and the follow-up post by m_eiman was to be able to reliably include non-https data in an https page (if I even have that correctly). Anyway, the reason I wrote this is because I believe it is VERY important to support the discussion of these ideas, and maybe take the time to explain why something might or might not work (which you did at a very high level in your first comment), but it is really your second follow-up which serves to potentially prevent people from posting ideas that though somewhat flawed, could still have some merit.
  - m_eiman 18y ago
    Indeed I'm no security expert, and I've never claimed to be. That's why I posted it here: to get some feedback from people who know what they're talking about. As for certificate extensions being too much to grasp, it's more a case of not knowing about them. Although it might be hard to belive, some people haven't spent much time working with certificates! Next, what would be the point of using this instead of TLS? I've tried to do a few things that TLS doesn't, as far as I know, do: * Support for caches/proxies such as Squid Caches could help with lowering network traffic, although it's probably just big corporations that use proxies that would actually benefit from this. * No need for one certificate per server IP Since I don't run a server park full of https servers I don't know how much of a problem this would be in real life, but I imagine that maintaining and updating certificates for lots of machines can be a lot of work. * Third party servers can serve verified content Suppose you'd like to use Amazon CloudFront to serve your static content. They don't support TLS, but with Content-Signature you could use them anyway. * Less load on the server Assuming that the signature isn't re-calculated on the fly for each request, but instead stored and re-used, the extra work for the server to support this is close to zero with static content. For dynamic content it's not as nice, but could be used if you have a cacheing proxy in front of whatever is generating the content. On the client side you'd have to check a PGP signature (or some other scheme, if that'd be better for some reason) for each file. I haven't done any performance tests on this, I just assumed that in the grand scheme of things this wouldn't be a big problem. So.. Maybe it's not a good idea, but some of these properties would be useful and aren't provided by TLS.
    - 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 might be misunderstanding what you're saying here with the replay comment, but I'd like to point out that I'm not trying to encrypt the content - I just want the client to be able to verify the source of the content.

by jamess 18y ago

brk 18y ago

So then, you're not too fond of his suggestion?

jamess 18y ago
I think that would be a fair assessment, yes. Classic case of person with no security training or experience trying to do security. The more I read it, the more painful it seems. You have to do a TLS handshake with the server anyway to get the bloody keylist (apparently the idea of certificate extensions is a bit too much to grasp) so if you have TLS, and you've already established a session why on earth would you need or want to employ this hack?
- pedalpete 18y ago
  actually, in defense of m_eiman, i don't think you are being completely fair. Though your technical abilities clearly outweigh his (and mine, and many if not most here on HackerNews), your response sounds somewhat insulting, and I hope i am just misunderstanding your tone. You say this is a 'Classic case of a person with no security training or experience trying to do security'. That is not what m_eiman is trying to do at all. What is trying to be accomplished is to remove an security warning when there is not threat. Not everybody careas about 'certificate extensions',and I know i've never looked it up myself, but the point of the original 37 Signals post, and the follow-up post by m_eiman was to be able to reliably include non-https data in an https page (if I even have that correctly). Anyway, the reason I wrote this is because I believe it is VERY important to support the discussion of these ideas, and maybe take the time to explain why something might or might not work (which you did at a very high level in your first comment), but it is really your second follow-up which serves to potentially prevent people from posting ideas that though somewhat flawed, could still have some merit.
- m_eiman 18y ago
  Indeed I'm no security expert, and I've never claimed to be. That's why I posted it here: to get some feedback from people who know what they're talking about. As for certificate extensions being too much to grasp, it's more a case of not knowing about them. Although it might be hard to belive, some people haven't spent much time working with certificates! Next, what would be the point of using this instead of TLS? I've tried to do a few things that TLS doesn't, as far as I know, do: * Support for caches/proxies such as Squid Caches could help with lowering network traffic, although it's probably just big corporations that use proxies that would actually benefit from this. * No need for one certificate per server IP Since I don't run a server park full of https servers I don't know how much of a problem this would be in real life, but I imagine that maintaining and updating certificates for lots of machines can be a lot of work. * Third party servers can serve verified content Suppose you'd like to use Amazon CloudFront to serve your static content. They don't support TLS, but with Content-Signature you could use them anyway. * Less load on the server Assuming that the signature isn't re-calculated on the fly for each request, but instead stored and re-used, the extra work for the server to support this is close to zero with static content. For dynamic content it's not as nice, but could be used if you have a cacheing proxy in front of whatever is generating the content. On the client side you'd have to check a PGP signature (or some other scheme, if that'd be better for some reason) for each file. I haven't done any performance tests on this, I just assumed that in the grand scheme of things this wouldn't be a big problem. So.. Maybe it's not a good idea, but some of these properties would be useful and aren't provided by TLS.
  - 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 might be misunderstanding what you're saying here with the replay comment, but I'd like to point out that I'm not trying to encrypt the content - I just want the client to be able to verify the source of the content.