3 ms·

You just made a really long excuse why domain is a security sandbox and domain+port is not. ALL other wb interactions are relying on Origins. Cookies rely on d

by homakov 13y ago

You just made a really long excuse why domain is a security sandbox and domain+port is not. ALL other wb interactions are relying on Origins. Cookies rely on domains solely, trying to fix http/https shadowing cookies with flags. Instead of treating them as different origins

derefr 13y ago
> ALL other wb interactions are relying on Origins. No; the very first line of my reply was the most important. SSL/TLS rely on domain, not domain+port. If two mutually-untrustworthy services both need to be carried over SSL/TLS, you need to put them on separate domains, full-stop. If your services aren't using SSL/TLS, that should be your first concern, not cookie origins; it doesn't matter what ports your service is running on if someone has MITMed your machine and put Mark's Malevolent Service on Alice's Allocated Port. Once both services are using SSL/TLS, they literally won't work any more (because you need two separate CA-signed certs) until you move one to a separate domain. Once you've done that, the "port" part of cookie origin is again irrelevant. In short: security boils down to the weakest link in the system. In a web stack, that's SSL/TLS origin identification. It doesn't matter if you "fix" cookies; as long as CAs keep signing certs for example.com instead of for https://example.com:443 https://example.com:443, you need to keep mutually-untrustworthy services on separate domains anyway.
- saurik 13y ago
  I could totally be wrong here, this is not my space of expertise (I generally do security work at much lower levels), but it is my understand that these "two mutually-untrustworthy services" that are hypothetically on the same SSL domain are only going to be able to share information via cookies, so cookies are the real problem. For all other purposes, they will be considered separate "origins": they will not be able to share local storage, they won't be able to make HTTP requests via JavaScript to each other, they won't be able to view the contents of each other's iframes or images, they won't have access to each other's message ports... in essence, these are totally different websites for every interaction that the browser even considers enforcing a security boundary for... except cookies, where apparently the port doesn't matter? That seems to be the core problem here, and I don't see how your comments about SSL are addressing actual security boundaries.
  - derefr 13y ago
    What I'm really saying is, without SSL, site B can MITM site A, and then ports don't matter, because it looks like you're talking to port 80 or whatever the attacker wanted anyway. With SSL, ports don't matter, because you can't run mutually-untrustworthy services on the same domain using SSL. So, with or without SSL, ports don't matter. Here, let me show my work: 1. All these cross-origin protections the browser uses are basically entirely meaningless without SSL, because you're talking to an unathenticated counterparty. So you've got to assume site A is using SSL+HSTS before a conversation about cross-origin protection even becomes coherent. You've also got to assume that, since site A is using HSTS, site B has to attack it by running SSL as well. 2. Now, with SSL, you can't have two separate sites on the same domain unless they're mutually-trusting, because they would need to share the same cert--and thus both have copies of the private key used to generate that cert. (Unless a CA screwed up and double-issued a cert, that is.) So you have to assume the attacker is now on a separate domain (or using a self-signed cert) for the conversation about cross-origin protection to retain coherency. 3. Disallow connections to sites with self-signed certs. (Browsers already do this.) 4. Do all the cross-origin protection stuff--like not sending cookies--when the domain is different. (Browsers already do this.) 5. You're done, because the previous assumptions simplified the problem. Your browser's SSL logic, combined with CAs' certificate-signing policies, have effectively protected you from talking to anything running on the same domain as site A, which doesn't also use the cert site A uses. Everything left is either mutually-trustworthy (that is, has access to site A's SSL private key), or has managed to break your SSL stack somewhere--in which case, we're back to the "you're screwed because you're talking to an unauthenticated counterparty" problem.
    - saurik 13y ago
      MITM attacks are only possible if you have a privileged location in the network: "the middle". Further, it is easily possible that neither the people operating Site A nor the people operating Site B have access to the SSL certificate for this domain name, as they might be behind a proxy or load balancer operated by the people holding the domain's SSL certificate. You can't just randomly MITM someone else's traffic: you need all the pieces together. Your assumptions about what is possible in certain hypothetical situations should not cause all security opportunities to be eroded. I mean, seriously: the logical conclusion to your argument is that all non-SSL websites should just share a global pool of insecure cookies, because it isn't like any of it can be considered secure anyway. The people you are protecting yourself from matters: these attacks are different threat models, and are secured separately.
- homakov 13y ago
  SSL interactions and localStorage - which one looks closer to what cookies do? Ok we can reconsider problem without SSL part. There are two http apps under different ports. If second is hacked it can get httponly cookies of first. Very simple threat. SSL design is more high level, of course they can not use origins. But it doesn't prove that cookies are ok

by homakov 13y ago

derefr 13y ago

> ALL other wb interactions are relying on Origins. No; the very first line of my reply was the most important. SSL/TLS rely on domain, not domain+port. If two mutually-untrustworthy services both need to be carried over SSL/TLS, you need to put them on separate domains, full-stop. If your services aren't using SSL/TLS, that should be your first concern, not cookie origins; it doesn't matter what ports your service is running on if someone has MITMed your machine and put Mark's Malevolent Service on Alice's Allocated Port. Once both services are using SSL/TLS, they literally won't work any more (because you need two separate CA-signed certs) until you move one to a separate domain. Once you've done that, the "port" part of cookie origin is again irrelevant. In short: security boils down to the weakest link in the system. In a web stack, that's SSL/TLS origin identification. It doesn't matter if you "fix" cookies; as long as CAs keep signing certs for example.com instead of for https://example.com:443 https://example.com:443, you need to keep mutually-untrustworthy services on separate domains anyway.

saurik 13y ago
I could totally be wrong here, this is not my space of expertise (I generally do security work at much lower levels), but it is my understand that these "two mutually-untrustworthy services" that are hypothetically on the same SSL domain are only going to be able to share information via cookies, so cookies are the real problem. For all other purposes, they will be considered separate "origins": they will not be able to share local storage, they won't be able to make HTTP requests via JavaScript to each other, they won't be able to view the contents of each other's iframes or images, they won't have access to each other's message ports... in essence, these are totally different websites for every interaction that the browser even considers enforcing a security boundary for... except cookies, where apparently the port doesn't matter? That seems to be the core problem here, and I don't see how your comments about SSL are addressing actual security boundaries.
- derefr 13y ago
  What I'm really saying is, without SSL, site B can MITM site A, and then ports don't matter, because it looks like you're talking to port 80 or whatever the attacker wanted anyway. With SSL, ports don't matter, because you can't run mutually-untrustworthy services on the same domain using SSL. So, with or without SSL, ports don't matter. Here, let me show my work: 1. All these cross-origin protections the browser uses are basically entirely meaningless without SSL, because you're talking to an unathenticated counterparty. So you've got to assume site A is using SSL+HSTS before a conversation about cross-origin protection even becomes coherent. You've also got to assume that, since site A is using HSTS, site B has to attack it by running SSL as well. 2. Now, with SSL, you can't have two separate sites on the same domain unless they're mutually-trusting, because they would need to share the same cert--and thus both have copies of the private key used to generate that cert. (Unless a CA screwed up and double-issued a cert, that is.) So you have to assume the attacker is now on a separate domain (or using a self-signed cert) for the conversation about cross-origin protection to retain coherency. 3. Disallow connections to sites with self-signed certs. (Browsers already do this.) 4. Do all the cross-origin protection stuff--like not sending cookies--when the domain is different. (Browsers already do this.) 5. You're done, because the previous assumptions simplified the problem. Your browser's SSL logic, combined with CAs' certificate-signing policies, have effectively protected you from talking to anything running on the same domain as site A, which doesn't also use the cert site A uses. Everything left is either mutually-trustworthy (that is, has access to site A's SSL private key), or has managed to break your SSL stack somewhere--in which case, we're back to the "you're screwed because you're talking to an unauthenticated counterparty" problem.
  - saurik 13y ago
    MITM attacks are only possible if you have a privileged location in the network: "the middle". Further, it is easily possible that neither the people operating Site A nor the people operating Site B have access to the SSL certificate for this domain name, as they might be behind a proxy or load balancer operated by the people holding the domain's SSL certificate. You can't just randomly MITM someone else's traffic: you need all the pieces together. Your assumptions about what is possible in certain hypothetical situations should not cause all security opportunities to be eroded. I mean, seriously: the logical conclusion to your argument is that all non-SSL websites should just share a global pool of insecure cookies, because it isn't like any of it can be considered secure anyway. The people you are protecting yourself from matters: these attacks are different threat models, and are secured separately.
homakov 13y ago
SSL interactions and localStorage - which one looks closer to what cookies do? Ok we can reconsider problem without SSL part. There are two http apps under different ports. If second is hacked it can get httponly cookies of first. Very simple threat. SSL design is more high level, of course they can not use origins. But it doesn't prove that cookies are ok