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.
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
[email protected]
https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
