TLS vs signing

Talk about internet security, computer security, personal security, your social security number...
Post Reply
User avatar
Thrawn
Master Bug Buster
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

TLS vs signing

Post by Thrawn »

A while ago I was reading some blog comments discussing restrictions on mixed secure/insecure content, and someone made an interesting suggestion: resources such as images don't usually need confidentiality, just integrity. It would be useful to have some kind of intermediate protocol between HTTP and HTTPS, where resources are signed (to prevent tampering), but not encrypted, and can therefore be cached just like HTTP.

Does anyone see any obvious pitfalls with that idea?
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.

True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:37.0) Gecko/20100101 Firefox/37.0
barbaz
Senior Member
Posts: 10841
Joined: Sat Aug 03, 2013 5:45 pm

Re: TLS vs signing

Post by barbaz »

Um, that it's easily MITM-able? An attacker could strip the signature, modify the content, sign it with their own or a hacked key, and serve it to you. Or just serve you their own content entirely, with some valid signature.
The browser would have to know in advance who is "supposed" to sign a resource, how can it?

And for those of us with data usage limits, what would be the bandwidth usage of that vs just encrypting the connection?
*Always* check the changelogs BEFORE updating that important software!
-
User avatar
Thrawn
Master Bug Buster
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

Re: TLS vs signing

Post by Thrawn »

I think the idea is that the PKI infrastructure would be the same as regular TLS. You contact a server and get its certificate, verify that, then make a plaintext connection and expect the response to be signed with the key that matches the certificate. So there shouldn't be any more MITM issues than normal.

I don't think bandwidth would be drastically different, although you might save some roundtrips on the TLS handshake. The biggest difference would be that the response would be cacheable - which is good in general, and excellent for content delivery networks (which would be able to deliver pre-signed content without needing to possess the key). You'd also be able to compress without running into attacks like CRIME and BREACH.

Cookie handling would have to be considered, of course; I think the connection should be treated as insecure for that purpose (so cookies marked Secure would not be sent). If a resource is actually tied to the user session and not exposed to the public, then it should be served over full TLS.
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.

True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:37.0) Gecko/20100101 Firefox/37.0
barbaz
Senior Member
Posts: 10841
Joined: Sat Aug 03, 2013 5:45 pm

Re: TLS vs signing

Post by barbaz »

Thrawn wrote:I think the idea is that the PKI infrastructure would be the same as regular TLS. You contact a server and get its certificate, verify that, then make a plaintext connection and expect the response to be signed with the key that matches the certificate.
OK, makes sense.
Thrawn wrote:The biggest difference would be that the response would be cacheable - which is good in general, and excellent for content delivery networks (which would be able to deliver pre-signed content without needing to possess the key).
How so? Someone would need the key for the CDN's SSL/TLS certificate in order to validly sign the resources on that CDN...
Thrawn wrote:Cookie handling would have to be considered, of course; I think the connection should be treated as insecure for that purpose (so cookies marked Secure would not be sent). If a resource is actually tied to the user session and not exposed to the public, then it should be served over full TLS.
Cookie handling should treat this protocol like the plain HTTP that it is. True that a MITM won't be able to interfere with the traffic, but they can still eavesdrop on everything that's going on, so secure cookies could get just as stolen if sent over this protocol as over regular plain HTTP.
*Always* check the changelogs BEFORE updating that important software!
-
User avatar
Thrawn
Master Bug Buster
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

Re: TLS vs signing

Post by Thrawn »

barbaz wrote: How so? Someone would need the key for the CDN's SSL/TLS certificate in order to validly sign the resources on that CDN...
If a CDN is sitting in front of example.com (the way Cloudflare does) and serving its content (with extra caching and worldwide distribution), then the webmaster of example.com can provide the CDN with signed copies of his assets, and never has to hand over his private key.
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.

True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:28.0) Gecko/20100101 Firefox/28.0
barbaz
Senior Member
Posts: 10841
Joined: Sat Aug 03, 2013 5:45 pm

Re: TLS vs signing

Post by barbaz »

Ah, I thought you meant like youtube's ytimg.com or something like cloudfront.net.
*Always* check the changelogs BEFORE updating that important software!
-
User avatar
Thrawn
Master Bug Buster
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

Re: TLS vs signing

Post by Thrawn »

It's more of a Web Application Firewall scenario, I guess...Cloudflare actually developed their own solution for serving a site without holding the private key (by establishing a secure channel to a client-controlled server that would perform key operations for them), but it would be much simpler with signing.
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.

True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:37.0) Gecko/20100101 Firefox/37.0
Ángel
Posts: 2
Joined: Sat Aug 22, 2015 1:01 am

Re: TLS vs signing

Post by Ángel »

You will love http://www.w3.org/TR/SRI/, what you propose is precisely the goal of the Subresource Integrity spec. :)
Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Firefox/40.0
User avatar
Thrawn
Master Bug Buster
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

Re: TLS vs signing

Post by Thrawn »

Yes, that does sound on-target. Thanks for sharing it.

I like the idea of putting the hash in a HTML attribute; that means minimal server-side involvement. The resource load could be a perfectly ordinary HTTP request; the origin could be a CDN that doesn't even know about the spec.

There have been people asking before if NoScript could do something like this, but I think the answer was, it's not as fine-grained as that. Too many resources to be feasible.
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.

True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (Linux; U; Android 4.0.4; en-us; HUAWEI U8950N-51 Build/HuaweiU8950N-51) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30
User avatar
Thrawn
Master Bug Buster
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

Re: TLS vs signing

Post by Thrawn »

And, it's coming in Firefox 43 :)
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.

True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0
Post Reply