If your understanding to 'compromised' certificate is leaked private key, then this certificate is not 'compromised', only MitM issued it for his own intentions and the last thing he care about is making the client secure or any party will connect to that client. Right ?
Client ask acme server for a certificate and get a certificate issued by MitM not the real and right acme server, do you consider such certificate 'compromised' or not ? (while private key is still secret)
What if this MitM issued certificate and supplied a chain to self-signed certificate to the false ( compromised without leaking private key but issued for bad intentions ) certificate , then client should validate the chain, that is easy and understandable, when reaching to that self-signed certificate how to trust it ?
>by design only public information is transmitted between the acme-client and acme-server
How to authenticate acme-server ?and how to authenticate such server in cloud based service lets say acme server is using service like CloudFlare ?
On 10/23/2018 7:45 PM, Alan Doherty wrote:
no certificate can be 'compromised' all certificates are public information by nature (everyone attempting to connect to a https site sees the public-cert thus mitm seeing it moments before it becomes public is pointless and moot) only private keys (known only to the client and never transmitted) can be 'compromised' by design only public information is transmitted between the acme-client and acme-server At 15:56 23/10/2018 Tuesday, Kas wrote:On 10/23/2018 4:52 PM, Alan Doherty wrote:again your talking about stuff unrelated to acme (and unlikely to potentially effect acme)It is related to ACME.your talking about inherent problems with https (or all public key cryptography) (thus only addressable/fixable by https related ietf groups)https uses TLS which utilize certificates issued by acme to be validated against root certificates , so acme is involved or can be, and what RFC (draft or protocol ) control that root certificates store ? How did you get it ? why not included the last process involving the store and the certificates issued by ACME in this protocol instead waiting for another draft ?acme cannot (and should not) expect its users to develop/run/use software with an otherwise completely non-standard https implementation (and thus missing any improvements/bug-fixes etc within wider https protocol/libraries) it uses https because its an existing/maintained/developed widely available protocol (and will improve with any underlying improvements to the base protocol) but acme is designed to use https not for security, just for transport its security is designed to be in the data sent/received so eavesdropping (mitm) cannot be advantageous to 3rd parties and yes many improvements could be added to https but as all automatable ones can be as effectively be intercepted by a suitably technically proficient mitm (if you check dns, mitm dns) if you check 3rd party (mitm 3rd pary) etc etc if its visual check key on a webpage (regexp replace good/bad key on all traffic to victim mitm his whole internet) only 100% secure method is out of band (phone sms etc. even these can be mitm if your a state level actor) thats why the improvements to https are made elsewhere and rigorously tested adopted/abandoned by that community thats why we rely on browsers/https libraries to secure themselves usually based on arrives with trusted keys, trusts updates to this list that are signed with an already trusted one imperfect but perfection is impossible (all we can add is hoops to jump, restrictions etc) but all automated public-key checks can obviously themselves be compromised if you have access to the client or wireHow is https relevant here ? even TLS is irrelevant as it all will go to root store and its source, MitM can issue attacks against the parties that will use the compromised certificate to establish trusted secure connection. You are missing the point, this protocol has the chance to standardize this root store and its source, and it is shame to pass it, at least to acme issued certificates and this will not contradict any existing protocol and doesn't require any change anywhere, so in theory you can build a secure bullet proof network where all the parties start with trusting one acme provider with no root store provided by any third party, and this can be the seed or motivation for other older CA's to follow, even OS's can follow and use the same protocol not to issue a certificate but to supply their root store in secure way , imagine your ability to configure a browser lets say Chrome running on Windows OS to use the root store provided by Mozilla, now Chrome is using the Windows certstore which is easy to be tampered with and its content can't be 100% updated.thats why we rely on browsers/https libraries to secure themselvesExactly , non-standardized process which allow a browser extension to inject root certificate in those libraries, and by non-standardized i mean there is no unified and securely designed process to update and ensure the root updated and secure, each browser and each system has its own method, and most of them require full update for the software before updating that root store, and acme has good chance to fix that, or at least do its part.by defining a standard or central root store you define a simple method to compromise all atm its only the wide variety of methods used that frustrates the efforts of any attempt at widspread compromise (ie you can see browserX is compromised because browserY shows an issue) as both use separate root stores defined by their maintainers no in-band method is possibly secure, so having a wide range of different non-standard ways and sources a user can verify their root store (to frustrate attempts at possibly intercepting all) again security/insecurity of https clients is NOTHING to do with a CA's job (which is providing a verifiable signature to client public keys ONLY) acme is ONLY about automating the CAs job nothing to do with what the certs are used/useable for afterwards nothing to do with the underlying design of httpsAt 13:52 23/10/2018 Tuesday, Kas wrote:On 10/23/2018 2:47 PM, Salz, Rich wrote:I don't know, there is many ways, but most likely someone will design anattack out of this and use it.If so (and I doubt it), such an attack would work on any web server/client combination, and is not specific to ACME.I don't have the mind set to think like an attacker, in internet security you can be astonished how attackers think, but let say you can only manage to know when a server (lets say university campus server) will request a certificate then all what you need is to make sure dns pointed to your laptop, and continue with the issuance the certificate, now you can utilize the CRL url in your certificate to make the victim clients makes call to an illicit url, monitored by the authority and that url let them download 50mb (crl request doesn't have size limit), how the victims can explain their phones and laptops downloaded such things, and here is the kick, the security software installed on the PC might make that request, those requests are not monitored by the system and most likely will bypass any firewall. I completely agree many of those attacks not specific to ACME, but with ACME it's concerning the parties in contact with the victim, and ACME has the ability to prevent and enhance the internet in overall. The core of the problem is with root store and who to trust, 15-20 years ago downloading a root store and verify it was something alien and unaccepted, now downloading 5mb can take few seconds and verifying it take way less, acme server can issue certificates using more than one CA certificate even it might have more than one root certificate, so why not to supply mini store so the clients of acme server can communicate in secure manner without trusting the system or any pre-supplied data, they just download the root store from example.com and you are good to go, all what is needed is acme URL or DNS with a key for DNSSEC or a key supplied by the ACME server itself. The current internet has well defined security protocols but in many cases depends on weak points, while creating new draft for such lets say root store will not go further than a draft or may be a RFC without adoption, and that why acme protocol and this draft has the power to change all of that, i am not calling for reinventing the wheel but to put a seed for better and secure internet, this seed might replace the crippled wheel, this draft will be mass adopted and i know this out of scope of this protocol intended usage, but still it has the power and the opportunity to do so, and on top of that you all who can make that happen, just think out of the box, and discuss this in depth, will this be best practice or bad practice? will such expansion to this protocol make the internet more secure or useless waste of time ? does such extra measures to secure the certificate issuance contradict with other RFC or enhance them? Please don't only think about this as how to prevent an attack (one or many) because what can go wrong will do, and this draft does have way more power and ability to move things very far in security, and i trust you can do good by at least discussing the big picture and how things will be in few years from now, as whole current system is wired with human factor administrating few key points, and all those secure castles are waiting for one CA server to fail and this will disturb the whole internet to its core._______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
