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
