Kas, I've read through this entire thread, and TBH, I really don't understand what threat you are concerned with.
Can you please describe the specific attack you have in mind? -Ekr On Wed, Oct 24, 2018 at 9:18 AM Kas <kas=40lightc....@dmarc.ietf.org> wrote: > > On 10/24/2018 4:39 PM, Alan Doherty wrote: > > At 11:02 24/10/2018 Wednesday, Kas wrote: > >> Certificate is not just a public key, it has extensions well defined > and standardized in RFC's, please educate your self with them, how and when > they should handled and what actions they might trigger, and remember this: > implementation of such handling is something can't be controlled and let me > list few facts : > > the functional part of a cert is just the public key ( > > all the rest and the extentions are just wrapping to give details of who > else is vouching for it and what identities it is associated with) > Wrong and you should not look at a certificate as a public key, please > educate yourself with deeper understanding what do extensions serve and > what critical extension means, i have a Code Signing certificate can i > use it for IIS ? it has a public key ! and it been vouched by Comodo , > do you understand what is CRL Distribution Points(2.5.29.31) and how > that certificate should be checked before considered trusted ? > > >> 1_ OpenSSL heartbleed went undetected for almost 2 years. > > this had nothing to do with certs, all to do with the underlying > encription implementation > Vulnerabilities are everywhere and they are in implementations > > >> 2_ Hackers managed to jailbreak Apple iPhone by simply opening a pdf > file ( handcrafted file with bad intentions) , imagine yourself opening a > pdf file and losing the warranty of your phone .( though many people used > that pdf intentionally ) > > again nothing to do with certs > Certs are ASN.1 a data structure language and can be utilized to > compromise a remote device, please search the web for "asn.1 > vulnerability" every system and many software got hacked by using > handcrafted certificate, in my example how a pdf (Portable Document > Format) file compromised a system > > >> 3_ Many client software's like browsers or email clients like > Thunderbird will add every CA certificate automatically to their store > > none will the entire point of the trusted root store is its involitility > > a user can add roots manually but 0 software will update its root store > except by normal (to it) software update > I said CA certificate not root certificate there is difference, CA's in > most cases will be added automatically to the store as long the root in > the store, and some will add it as not trusted without root but in many > cases will be added ! > > >> ( their own store or the system store ) , MitM can issue CA certificate > to a client which is in this case SMTP server and this server will use that > certificate and help distribute this "compromised without losing the > privatekey" certificate to everyone comes in contacting with that SMTP > server. > > thats patently impossible, otherwise new CAs could just use this method > to gain trustinstead of the current hoop jumping amd auditing they have to > go through to get included in software root stores > > (why letsencrypt for example is signed by their own and other(extant in > older sofware) roots till their own is widespread as software updates the > signatures from other older CAs are needed (to ensure at least one of the > root signitures is in potential clients root store) > There is CA certificates providers and they are sell it, an attacker can > get one from on by stealing the private key of one, it is not something > impossible or didn't happen > > >> 4_ Keeping private key secret is a MUST, but this doesn't means you > should trust the certificate from unknown sources, as they might be > targeting your clients not you.( handcrafted with bad intentions) > > again as long as it passes my validation (signed by 1 or more widely > trused roots) it is doing its job (passing and verifying my public key) > Read about the case of DigiNotar > > >> 5_ What if a company like Samsung wanted to issue certificates to its > devices to make the connections between phones and TV secure, and it don't > want to ask Apple and Microsoft to add Samsung root certificate to theirs > system store, then Samsung can't use acme protocol or it can ? > > it wouldnt prevent them at all > > or adding their own CAs root to the trusted roots on all future devices > Right, now how to update or revoke those certificate and keep the > devices working wouldn't be easier and safe that you bought a TV and the > paper guide instruct you to put X.com (it has by default) in settings > and apply the key YYYYYYY if that didn't work then visit X.com and get > the updated key after that it will be automated process, now to access > that device form you PC instead of accepting the root and install it ( > or adding it to exclusion) you do the same use X and YYYYYY > > >> and i am here not pointing the monopoly in such addition but we are in > 2018 and that root store should be more secure and obtained online from the > source in secure way, should you accept and install such root certificate > manually from every device or simply go to Samsung site and import the > their root and store and you are good to go with all their devices, is that > doable ? is that practical and safer for the average user of the internet ? > > many do CA cert for example (widely used by many before acme) and not > included in most browser softwares root stores > > but those wishing to use manually added them to their own CA root store > and advised their users/customers to do same > > and some software did include them > > > > anyone can setup a CA there is no central authority > > every large enteprise tends to have their own CA to issue certs only > seen/used internally and updates all internal machines to trust this CAs > signiture > > > > to get included in mozillas root store you have to pass their audits, > then you get included > > to get included in microsofts same > > to get included i librayX's same etc > > > > some root stores trust others audit process' and auto trust any root > audited/added by another > > some root store maintainers will > > > > there can (and shouldn't) be any single central authority > I know how certificates and store works, > If your store from Microsoft then your CA controlled by Microsoft ,while > FireFox on Windows has Mozilla store, so how many stores out there and > where you get them ? > This should be unified or separated and i can't care less about that, > the whole point is to define how to obtain the store/root of specific CA > online in a secure way, acme can do that staring by its server, it > already has online certificate revocation process that can be adopted by > every CA out there. > > Sorry i don't feel like reading and answering the rest because i am lost > and can't understand what is your point, is it to proof i am wrong in my > suggestion ?( no need to answer that ), you keep steering the subject > away, and i don't know if the editors got my point or even will have the > mood of reading any of this, > > Thank you and pretty please Alan give it rest, you proved me wrong and won > ! > > > >> The question is so simple if A asked B for certificate how A can be > sure there is no M in the middle issued the certificate ? if the answer by > depending on TLS layer then that is not a solution, as all will come to > validates a root self-signed certificate, so that question will become how > A obtain the root certificate from B to validates the issued certificate ? > > if the cert returned is signed by B then whoever signed it has B's > private key (thus must be B) > > no mitm can see any information that is not safe to leak (by design) > > > >> This draft can ignore this issue, and that is OK, but it can do better > and resolve what really needs resolving the root issue, and help internet > become more safe and secure, not for this specific protocol but as a seed > for other protocols to follow, how many RFC's been used by this draft and > how many in the future will depends on this draft ( soon to be RFC). > > the issue of which roots are trusted is again nothing to do with acme > > (acme can be used by private CAs, public untrusted CAs (like ca cert), > and public widely trusted CAs (like letsenrypt) > > > > its just a means of transmitting the public key needing signed, > authorising the identities to be verified, and obtaining the signed public > key (cert) back from the CA that the acme client has chosen > > > > the client chooses the CA based on their needs (if they want a widely > trusted one, they use one) publicly accessable webservers for instance > > if they care not about its trustability because of narrow audience > (https interfaces of routers/firewalls etc) they will often use self signed > or signed by an internal/enterprise CA > > > > *i say widely because there are infinite software developers, all with > differing lists of trusted by them roots so no CA can be assured their > current roots public key has been added to all (its why some software > delegates trust/verification to the OS or another) > > > > its also why as time passes a CA may sign its intermediate public cert > with its expiring in a few years old-root key and its valid for many more > new-roots key (because much software wont yet have the new root key > trusted, and no way to force same) due to involitile by design trusted root > store > > > > (why when lenovo software auto-added its own root to all windows root > store computers their software ran on their was such outcry as their > private key for this root was widely known and thus anyone could easily > sign certs that would be trusted by these 'victim' computers) > > found by users comparing their root stores to others > > > >> That been said ,and i really don't want to discuss attacks because it > is useless and endless discussion, so please Alan first forgive my English > (may be i wasn't clear) and pretty please don't steer the this > thread/subject away from its topic. > >> > >> > >> Best reagrds, > >> > >> K. Obaideen > >> > >> > >> On 10/24/2018 2:13 AM, Alan Doherty wrote: > >> > >>> At 18:14 23/10/2018 Tuesday, Kas wrote: > >>>> Can MitM impersonate acme server and walk the client through the > whole process and issue a certificate to the client ? yes it can. > >>>> > >>>> 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) > >>> if the cert is usable then it is no more/less secure than the one from > the CA direct > >>> (the cert being a signature from a widely trusted CA verifying the > public key the client provided, is authentically from the client) > >>> > >>> if the cert is unuasable (untrusted) the client/user/etc can detect > this > >>> > >>>> 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 ? > >>> ?? i think you again miss what a cert is and how x509 works > >>> issued for bad intentions? the acme-client is the only one who can > use the cert (as the only one with the private key) > >>> the CA has no input or control over the use of the cert (so their > intent affects nothing) > >>> > >>> > >>>>> by design only public information is transmitted between the > acme-client and acme-server > >>>> How to authenticate acme-server ? no need > >>>> and how to authenticate such server in cloud based service lets say > acme server is using service like CloudFlare ? again no need > >>> an acme client gives not one jot of care about if they are talking to > their CA or another (well they do but only insofar as getting a cert that > works) > >>> only that the cert they get is valid/invalid > >>> > >>> if a rouge CA can somehow miraculously issue valid certs, ones trusted > by others and me then its as i said no concern > >>> > >>> they could cause outage by refusing service long enough for my valid > certs to expire, they cannot cause outage/compromise or any other issue by > issuing valid certs > >>> issuing invalid certs is the same as refusing service but more costly > effort wise for the mitm thus pointless > >>> > >>> > >>> i have a private key, i have a public key, i the acme-client-owner > created both > >>> a cert is just > >>> ((my public key)+a cryptographic signature vouching for its > authenticity from my-CA)<<varies client to client > >>> +(my-CAs public key)+a cryptographic signature vouching for its > authenticity from their CA)<<invariant for however many CAs till root > >>> +(their CAs public key)+.....till a trusted root > >>> > >>> i give my CA my public key, and the identity(s) i wish to use, they > require i prove im who i claim to be, i do so > >>> they send back the varient part of the cert, the invariant part i can > obtain publicly or from my CA (the copy of the chain) > >>> i can then verify all against as many/few trusted root stores of > browsers i want (or just simpler/faster compare the current chain against > previous, as they do not vary often) > >>> > >>> (only generate-able by the owner of my CAs private key(my CA) > >>> publicly verifiable by being signed by my-CAs public key (verifiable > by looking at their CA etc) > >>> > >>> so to issue a valid cert a mitm can only possibly direct my cert > request to myCA or another-trustedCA but cannot possibly generate a cert > themselves without first compromising a trusted (by me) CAs private key > >>> if they have achieved this then they already have ownership of the CA > and thus have no need to mitm > >>> > >>> their only job is to assure the browser that my public key is valid > >>> if the browser trusts me (if cert untrusted/self signed) or my cert > they then send me data/receive data from me and encrypt/decrypt with this > public key > >>> (and i can send/receive using my private key for same) > >>> > >>> either way the data they send/receive is no more/less secure due to > the x509 cert > >>> my users would be as secure with me if i used self signed certs to > talk to me, the use of a trusted CA is just to assure strangers (those that > have not otherwise verified my authenticity) that mysite.com is not an > imposter > >>> > >>> but everyone has mysite.com's cert (its public) only mysite.com can > use it to talk as only mysite has the private key necessary to send people > data that can be decrypted by the public key embedded in that public cert > >>> > > _______________________________________________ > > Acme mailing list > > Acme@ietf.org > > https://www.ietf.org/mailman/listinfo/acme > > > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
