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) >1_ OpenSSL heartbleed went undetected for almost 2 years. this had nothing to do with certs, all to do with the underlying encription implementation >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 >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 > ( 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) >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) >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 >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 >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 [email protected] https://www.ietf.org/mailman/listinfo/acme
