I agree with alan here. The ACME protocol is designed such as you don't need to trust the server (and/or any MITM) particularly much. Even the challenges are protected since you need to SHA-256 the token with your client key to aquire the valid token value. (If the challenges would not be protected this way, a attacker could replace the token values with their own, which also has a pending authorization for the victims domain)
This means an attacker cannot MITM an ACME server such as the attacker would get a valid certificate for the victim domain. ----- The only danger I could see is if the attacker MITMs the account-creation process, then they could also MITM the rest, replacing everything with their own values, and thus fooling a ACME client into authorizing a domain for an attacker. But I have a solution to this, and that is a CAA revocation mechanism: [OPTIONAL] If the ACME client receives a certificate from the CA server, for which it does not own the private key to, or is not the certificate the ACME client ordered, is not signed by a valid CA, or any other mismatchs, it may change its CAA record into "revoke" and then the CA's name. like this: example.com. CAA 0 revoke "letsencrypt.org" The CA server should periodically query the CAA record and if it sees any "revoke" posts with its own CA name, it should trigger an revocation for any and all certificates that this current DNS name owns. The query period could be constructed as a "smart back-off" algoritm, where it queries the CAA record more often the hour the certificate was issued, and then cools down into querying once a day for like an week, and then after that, querying weekly. Also, it might be smart if the server, upon processing a revocation request, could query the CAA record (regardless of when it did query it last, provided any rate limits for failed authorizations aren't met), and if it finds a revoke tag, it will process the revocation request as valid regardless of which account key signed the request. Also, in this case I think it should NOT require ownership of all domains in a certficate as it does for normal revocation checking, due to this should be a "emergency function" to block all certificates issued to a domain if a cert has been fraudulently issued. The tag "revoke" should override both issue and issuewild, meaning that any issue and issuewild bearing the same CA name as the revoke tag should be ignored. The reason im proposing a CAA revocation mechanism, is that once the attacker has gained a certificate, he could block the access to the CA server, preventing the ACME client from requesting any revocation. By allowing a scheme where the ACME client can post a revoke CAA tag, and then wait until the CA server reads it, a ACME client can easily recover from a compromised certificate. -----Ursprungligt meddelande----- Från: Acme <[email protected]> För Kas Skickat: den 23 oktober 2018 11:27 Till: Alan Doherty <[email protected]>; Salz, Rich <[email protected]>; Richard Barnes <[email protected]>; [email protected] Ämne: Re: [Acme] Please consider adding server authentication Revoke it and make all clients of the client mark the victim untrusted at a moment fits the attacker scheme, or make clients of the victim request CRL url to disturb a network, or get list of a client endpoints, cause trouble for a monitored network when the clients looks like accessing some specific IP or site. I don't know, there is many ways, but most likely someone will design an attack out of this and use it. On 10/23/2018 12:01 PM, Alan Doherty wrote: >> Acme server is CA server and shouldn't need a root store to be validated or trusted, that root store can be easily manipulated even by a software, even without locally manipulation the MitM can issue a certificate to the client by simply hijacking the connection and having certificate issued by trusted CA, and the client will validate and trust that certificate. > how would this scenario be an attack??? > > if the mitm gives over a valid cert to the 'victim'-client > what have they achieved? > > they have viewed otherwise public information that is useless to them, and 'victim' operations are uninterrupted > (as obviously an acme client (as with all CA operations) never reveals the private key to a CA or any other parties, as only the public ones transit the wire) > and gained 0 information/resources of use (and expended a lot of effort to mitm successfully, by somehow obtaining a trusted cert for the CA endpoint their impersonating) > > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme > _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
