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 :
1_ OpenSSL heartbleed went undetected for almost 2 years.
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 )
3_ Many client software's like browsers or email clients like
Thunderbird will add every CA certificate automatically to their store (
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.
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)
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 ?
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 ?
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 ?
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).
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
