POST-as-GET and privacy

I realize this topic doesn’t really matter while unauthenticated GETs are still supported for the various ACME objects. But when it eventually gets turned off, I’m curious what the intent is.

For things like Orders, Authorizations, and Challenges that are tied to a specific account, should any ACME account be able to sign a POST-as-GET request to query those resources if they know the location/URL? Or should only the account owner be able to?

Today, it appears any account can sign the request and get the data. But will that always be the case?

In section 6.3 the spec says:

On receiving a request with a zero-length (and thus non-JSON) payload, the server MUST authenticate the sender and verify any access control rules.

But I can’t find any references on mandated access control rules associated with the object types. Is it basically a server implementation choice?

2 Likes

It was my understanding that only the ACME account to which the resources (orders, authzs, challenges) belong can access them. When you say that any other account can access them as well via POST-as-GET, did you test that with Boulder? Or Pebble? Or both? I would say that it would be a bug if that’s possible.

1 Like

I haven’t tested against Pebble or Prod Boulder yet. But it definitely works against Staging Boulder. I’ve also only tested getting authorization objects so far.

1 Like

The merge of “POST-as-GET” into the spec cites “privacy concerns raised in Adam’s and Ben’s AD reviews” (but without link to theses, sadyl) : https://github.com/ietf-wg-acme/acme/pull/445

Maybe @jsha remembers? (Richard Barnes doesn’t seams of have an account here)

I personally feel it’s a but that should be fixed: if the requirement of POST-as-GET only require to create any account, it doesn’t protect anything.

@tdelmas At a guess, probably these:

“Adam”: https://mailarchive.ietf.org/arch/msg/acme/cGQzjW7WQQ5oS2nrnXCXZM-2Jn8
“Ben”: https://mailarchive.ietf.org/arch/msg/acme/YLYlBVdnv2VxllVCS8pF-QueLe8

Thank you @mnordhoff !

The most wiring example there ends with the email and phone number. In the Let’s Encrypt context, as email validation is not allowed and the account entry point protected, I think it doesn’t apply. Only the discovery of domains. Which will ends up in CT logs. But could it may help discover the link between one domain and another (with are not in the same certificate)? (which can be problematic if possible, like i-am-gay.com and my-name-is-smith.com)

I don’t see anything much relevant there, did I missed it?

Skimming the message, I didn’t see a lot, but it was mentioned:

Section 6.2 notes that servers MUST NOT respond to GET requests for
sensitvie resources. Why are account resources the only sensitive ones?
Are authorizations not sensitive? Or are those considered to fall under
the umbrella of “account resources” (Section 7.1 seems pretty clear that
they do not)?

On the other hand, one of the other reviewers was named Ben Campbell; they might have said something I missed.

1 Like

Thanks for finding those links, @mnorhoff! That is accurate. The specific issue raised by reviewers was that some CAs might consider the account ID-to-hostname matching sensitive. More broadly, the issue was that we had a protocol in which some elements were authenticated, and some were not, based only on whether they happened to have polling semantics or “write” (i.e. POST) semantics.

Right now we don’t specify any access control rules for Orders, Authorizations, and Challenges (because we don’t consider those resources sensitive), but for best compatibility with other ACME servers, you should probably assume that most ACME servers will enforce that those objects can only be retrieved by the account they were created for. It’s possible we might implement such a rule in Boulder if it looks like it will be useful in encouraging the client ecosystem in the right direction.

2 Likes