

Ask HN: 37 signals loathing mixed content - A possible solution? - m_eiman

I read the 37 signals piece on mixed content, and remembered a brainstorming session I had last summer where I designed a scheme to solve this problem.<p>http://eiman.tv/misc/http-content-signature.html<p>Basically it's a couple of HTTP headers with a signed hash of the content, letting the client verify the integrity of the content. This allows the content to be served from a non-HTTPS server, a proxy or a cache while maintaining some of the benefits of HTTPS.<p>Anyway, it'd be interesting to hear what you people think of the concept! If it works it'd be a useful addition to the web.
======
jamess
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/suncryptoacc...](http://www.sun.com/products/networking/sslaccel/suncryptoaccel6000/index.xml)

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

~~~
jamess
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?

~~~
m_eiman
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
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>) This is not a field anyone is
going to thank you if you want to learn on the job.

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

