5 ms·

first, it breaks the URL specification, as the "host" is no longer a host. it breaks user's expectation of one of the VERY FEW things that everyday users unders

first, it breaks the URL specification, as the "host" is no longer a host. it breaks user's expectation of one of the VERY FEW things that everyday users understand about the internet. one may manage to upload an html file to the bank's server and serve a -signed- page that google amp will cache, and then use it to phish customers from within the bank's domain. Or just use a stolen key to make thousands of such pages before the bank finds out. I think , contrary to what you say, it's a brand new, major attack surface.

Ajedi32 7y ago
> one may manage to upload an html file to the bank's server and serve a -signed- page that google amp will cache Only if you have the bank's private key, and the ability to serve arbitrary content from the bank's domain. In which case... yeah, I don't see how the signed exchanges standard makes that problem significantly worse.
- buboard 7y ago
  i don't know what's the max expiration for amp's cache, but i could set a really-long expiration date on the file and remove it from the server without the bank ever knowing it existed. SGX don't even require an upload - one disgruntled employee could do the same with a stolen key. Nobody benefits from this shit than google. Do we really need more attack surfaces?
danans 7y ago
> first, it breaks the URL specification, as the "host" is no longer a host. By this definition, "host" hasn't been a host in a long time, since the time it was possible to route DNS traffic to multiple IP addresses, possibly in different datacenters. > it breaks user's expectation of one of the VERY FEW things that everyday users understand about the internet. How is signing content directly less authentic than signing only at the web server? Signing content directly at the time of publishing ensures that it was created using the private keys of the entity in question, regardless of the delivery mechanism for the content. > one may manage to upload an html file to the bank's server and serve a -signed- page that google amp will cache, Signed content exchanges specifically limit that by putting the content signing step at the content creator level, not the web server level. Unless you steal the content creator's private keys, you can't represent your content as theirs.
- buboard 7y ago
  > "host" hasn't been a host in a long time, Does SXG make this better or worse? > ensures that it was created using the private keys signing at the server ensures that it was created using the key AND served from a host they control. How is that not better? > you can't represent your content wouldn't the server sign all http responses by default? all you would need to do is upload a file
  - danans 7y ago
    > wouldn't the server sign all http responses by default? all you would need to do is upload a file No, the content has to be signed when it is created, in the content management system or similar content creation tool, not when the server sends it. The content management system itself must have strong controls on it (ACLs, controlled user accounts, protected private keys stored only on encrypted and access controlled media, regular audits, etc). Basically the server itself is no longer trusted as the arbiter of content authenticity, the actual content creator is. Concretely, when the editor at a publication approves an article after reviewing it, it is signed for delivery at the moment of publication, not at the moment that the request is served.
    - buboard 7y ago
      so that means i can sign a page on the editor's computer, take it with me and serve it to amp from my website? that sounds even more dangerous tbh. it delegates security from people who may know a little bit about it (web hosts) to people who likely know nothing about it (writers) what happens if someone's key is stolen and they need to re-issue it? All the previously published copies are now invalid?
jsnell 7y ago
> first, it breaks the URL specification, as the "host" is no longer a host. Really, how so? RFC 3986 goes out of it's way to make clear that the "host" component doesn't mean DNS, and doesn't even have to denote a host. "In other cases, the data within the host component identifies a registered name that has nothing to do with an Internet host." "A URI resolution implementation might use DNS, host tables, yellow pages, NetInfo, WINS, or any other system for lookup of registered names." > it breaks user's expectation of one of the FEW things that everyday users understand about the internet. What, exactly and concretely, is that expectation? > one may manage to upload an html file to the bank's server and serve a -signed- page that google amp will cache, and then use it to phish customers from within the bank's domain. If the attacker can upload arbitrary pages to the bank's website, just why would they need signed exchanges? They've already got their phishing page on the correct domain.
- buboard 7y ago
  > RFC 3986 goes out of it's way the RFC uses the word "host" and not "signer". It also says that the "host" is intented to be looked up in some service registry, and there is no such thing for arbitrary signers. > exactly and concretely, is that expectation One of the common security advice banks used to give is "check your browser address that you are in our server" > just why would they need signed exchanges with signed exchanges they can fool amp to cache the page long after it has been deleted from the server
  - danans 7y ago
    > One of the common security advice banks used to give is "check your browser address that you are in our server" " in our server" is a simplification of the technical explanation: "signed by our computers using our private keys before delivery to you". That is still maintained in the case of signed content exchange, but instead the transport function is provided by a different server. It's not much different than, i.e. signing a compiled app with your private keys before uploading it to an app store. Such apps also use hosts to identify themselves and their content, even though they are delivered via app-store mechanisms.

Ajedi32 7y ago

> one may manage to upload an html file to the bank's server and serve a -signed- page that google amp will cache Only if you have the bank's private key, and the ability to serve arbitrary content from the bank's domain. In which case... yeah, I don't see how the signed exchanges standard makes that problem significantly worse.

buboard 7y ago
i don't know what's the max expiration for amp's cache, but i could set a really-long expiration date on the file and remove it from the server without the bank ever knowing it existed. SGX don't even require an upload - one disgruntled employee could do the same with a stolen key. Nobody benefits from this shit than google. Do we really need more attack surfaces?

danans 7y ago

> first, it breaks the URL specification, as the "host" is no longer a host. By this definition, "host" hasn't been a host in a long time, since the time it was possible to route DNS traffic to multiple IP addresses, possibly in different datacenters. > it breaks user's expectation of one of the VERY FEW things that everyday users understand about the internet. How is signing content directly less authentic than signing only at the web server? Signing content directly at the time of publishing ensures that it was created using the private keys of the entity in question, regardless of the delivery mechanism for the content. > one may manage to upload an html file to the bank's server and serve a -signed- page that google amp will cache, Signed content exchanges specifically limit that by putting the content signing step at the content creator level, not the web server level. Unless you steal the content creator's private keys, you can't represent your content as theirs.

buboard 7y ago
> "host" hasn't been a host in a long time, Does SXG make this better or worse? > ensures that it was created using the private keys signing at the server ensures that it was created using the key AND served from a host they control. How is that not better? > you can't represent your content wouldn't the server sign all http responses by default? all you would need to do is upload a file
- danans 7y ago
  > wouldn't the server sign all http responses by default? all you would need to do is upload a file No, the content has to be signed when it is created, in the content management system or similar content creation tool, not when the server sends it. The content management system itself must have strong controls on it (ACLs, controlled user accounts, protected private keys stored only on encrypted and access controlled media, regular audits, etc). Basically the server itself is no longer trusted as the arbiter of content authenticity, the actual content creator is. Concretely, when the editor at a publication approves an article after reviewing it, it is signed for delivery at the moment of publication, not at the moment that the request is served.
  - buboard 7y ago
    so that means i can sign a page on the editor's computer, take it with me and serve it to amp from my website? that sounds even more dangerous tbh. it delegates security from people who may know a little bit about it (web hosts) to people who likely know nothing about it (writers) what happens if someone's key is stolen and they need to re-issue it? All the previously published copies are now invalid?

jsnell 7y ago

> first, it breaks the URL specification, as the "host" is no longer a host. Really, how so? RFC 3986 goes out of it's way to make clear that the "host" component doesn't mean DNS, and doesn't even have to denote a host. "In other cases, the data within the host component identifies a registered name that has nothing to do with an Internet host." "A URI resolution implementation might use DNS, host tables, yellow pages, NetInfo, WINS, or any other system for lookup of registered names." > it breaks user's expectation of one of the FEW things that everyday users understand about the internet. What, exactly and concretely, is that expectation? > one may manage to upload an html file to the bank's server and serve a -signed- page that google amp will cache, and then use it to phish customers from within the bank's domain. If the attacker can upload arbitrary pages to the bank's website, just why would they need signed exchanges? They've already got their phishing page on the correct domain.

buboard 7y ago
> RFC 3986 goes out of it's way the RFC uses the word "host" and not "signer". It also says that the "host" is intented to be looked up in some service registry, and there is no such thing for arbitrary signers. > exactly and concretely, is that expectation One of the common security advice banks used to give is "check your browser address that you are in our server" > just why would they need signed exchanges with signed exchanges they can fool amp to cache the page long after it has been deleted from the server
- danans 7y ago
  > One of the common security advice banks used to give is "check your browser address that you are in our server" " in our server" is a simplification of the technical explanation: "signed by our computers using our private keys before delivery to you". That is still maintained in the case of signed content exchange, but instead the transport function is provided by a different server. It's not much different than, i.e. signing a compiled app with your private keys before uploading it to an app store. Such apps also use hosts to identify themselves and their content, even though they are delivered via app-store mechanisms.