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
>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 wire
>>>How 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 themselves
>>>Exactly , 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 https
>>
>>
>>
>>>>At 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 an
>>>>>> attack 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
>>>>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
