4 ms·

Could Eve then just register bob.com and point it to bob's random bucket to mess with him? And shouldn't Alice be able to register Alice.com and point it at Bo

Could Eve then just register bob.com and point it to bob's random bucket to mess with him? And shouldn't Alice be able to register Alice.com and point it at Bob's bucket if she feels like it? It seems like the answer already exists: don't create CNAMEs haphazardly. (But please explain it to me if I'm missing something here)

detaro 5y ago
> Could Eve then just register bob.com and point it to bob's random bucket to mess with him? If it blocks creation, she would have to know the bucket name Bob would want to create soon. At which point she could just create the bucket instead. > And shouldn't Alice be able to register Alice.com and point it at Bob's bucket if she feels like it? She can only do that with this method if Bob's bucket is called "alice.com". Doesn't seem important to support for random unrelated people, if its for a dedicated setup where Bob manages a thing for Alice you could always have a way of granting that permission specifically or to opt out of the verification. > It seems like the answer already exists: don't create CNAMEs haphazardly. "don't make mistakes". If people keep making a mistake all the time, that's not the greatest answer. There's a reason most other providers that allow you to point a domain at them do some verification.
- chaboud 5y ago
  How would it block creation? Is AWS supposed to keep a full record of CNAME entries for the Internet and keep it up to date? Since CNAME records can point to other domains, I’m not sure how AWS is supposed to police this and allow cross-referencing from other parties. Blocking based on any CNAME presence could turn into a bucket-squatting exploit pretty quickly. A CNAME record is an “I’m pointing my domain at some other place” record. Redirect to something out of your control, S3 or otherwise, and you’re handing over control of the returned content. That doesn’t so much strike me as a mistake but more as the way that CNAME records were designed to work.
  - detaro 5y ago
    yes, as mhio already pointed out the first variant doesn't actually work. The second does though, and is what's commonly done. > That doesn’t so much strike me as a mistake but more as the way that CNAME records were designed to work. "I hold something into a saw, and it gets cut. That doesn’t so much strike me as a mistake but more as the way that saws are supposed to work. Why are all these fingerless people saying our saws should have safety features?!" We know such things happen to all kinds of people all the time. It has been part of actual security problems. We know how to fix it, because many service providers do require validation. Why not consider the validation?
    - chaboud 5y ago
      You’ve tried the snark twice, but it’s not aiding your point. What is the actual mechanism you think should be implemented, and how does that support cross-party referencing while avoiding other modes of vulnerability (e.g. denial of service)?

detaro 5y ago

> Could Eve then just register bob.com and point it to bob's random bucket to mess with him? If it blocks creation, she would have to know the bucket name Bob would want to create soon. At which point she could just create the bucket instead. > And shouldn't Alice be able to register Alice.com and point it at Bob's bucket if she feels like it? She can only do that with this method if Bob's bucket is called "alice.com". Doesn't seem important to support for random unrelated people, if its for a dedicated setup where Bob manages a thing for Alice you could always have a way of granting that permission specifically or to opt out of the verification. > It seems like the answer already exists: don't create CNAMEs haphazardly. "don't make mistakes". If people keep making a mistake all the time, that's not the greatest answer. There's a reason most other providers that allow you to point a domain at them do some verification.

chaboud 5y ago
How would it block creation? Is AWS supposed to keep a full record of CNAME entries for the Internet and keep it up to date? Since CNAME records can point to other domains, I’m not sure how AWS is supposed to police this and allow cross-referencing from other parties. Blocking based on any CNAME presence could turn into a bucket-squatting exploit pretty quickly. A CNAME record is an “I’m pointing my domain at some other place” record. Redirect to something out of your control, S3 or otherwise, and you’re handing over control of the returned content. That doesn’t so much strike me as a mistake but more as the way that CNAME records were designed to work.
- detaro 5y ago
  yes, as mhio already pointed out the first variant doesn't actually work. The second does though, and is what's commonly done. > That doesn’t so much strike me as a mistake but more as the way that CNAME records were designed to work. "I hold something into a saw, and it gets cut. That doesn’t so much strike me as a mistake but more as the way that saws are supposed to work. Why are all these fingerless people saying our saws should have safety features?!" We know such things happen to all kinds of people all the time. It has been part of actual security problems. We know how to fix it, because many service providers do require validation. Why not consider the validation?
  - chaboud 5y ago
    You’ve tried the snark twice, but it’s not aiding your point. What is the actual mechanism you think should be implemented, and how does that support cross-party referencing while avoiding other modes of vulnerability (e.g. denial of service)?