On 21.10.2011 15:09, Kai Engert wrote:
This is an idea how we could improve today's world of PKI, OCSP, CA's.
https://kuix.de/mecai/
Review, thoughts and reports of flaws welcome.
Thanks to Peter Eckersley, who first mentioned to me at 28c3 that there
is one scenario that isn't solved by the MECAI proposal. Meanwhile
several people have mentioned this to me, including people at Fosdem and
a comment from today in "reddit".
If the attacker is able to hack the router that is close to the
webserver (e.g. hack the ISP that hosts the webserver), then the
attacker might be able to simply apply for a certificate from a CA and
intercept the (plaintext) approval emails the CA sends to the domain's
mail server.
In other words, the problem is, an attacker could ask for a certificate
without the domain owner noticing.
Here's one solution I could think of: In addition to everything already
done, maybe we should require that issueing a certificate requires
(additional) phone call(s).
We have:
- attacker
- CA
- domain owner
- domain owner's phone number or ISP's phone number in the domain registry
Let's say the attacker hacked the ISP's router and is able to intercept
emails.
The attacker requests a cert from the CA.
CA sends email to hostmaster@domain and requests approval.
The CA could call each phone number listed in the domain registry, and
tell them, there is a request for a cert for "domain", a transaction
number (chosen by the CA) and a random approval code (also chosen by the
CA).
There could be a standardized hostname like "certapproval" as in
certapproval.name-of-ca.com
The phone calls would ensure that each registered person will be aware
of the certificate issuance.
At least one of the phone contacts listed in the domain registry must be
aware of the requested cert issuance. This person will receive the
approval code from the CA and visit website certapproval.name-of-ca.com
The person would enter the transaction number. The website can now
display the details of the certificate request. The person can check the
information, and enter the approval code to approve the cert issuance.
Lazy ISPs who don't care could simply ignore such phone calls.
This also means, people running a website have an interest to keep their
phone number in the registry up to date. If the number isn't up to date,
they can't get a cert - or they face the risk that a random person will
just do what they are being told to do on the phone and have an
attackers certificate approved.
This might probably make certificates slightly more expensive, because
certificate issuance cannot be fully automated.
Maybe a certificate policy could be included in a certificate if this
procedure has been followed. And browsers could decide to drop security
indicators if this policy is missing.
(EV policies could also be updated to include this requirement.)
If the domain registry contains only the ISP's phone number (e.g. for
privacy reasons), and if the CA request was initiated by the domain
owner, it should be the ISP's responsibility to make contact with the
domain owner, using the identification procedures that have been agreed
on between customer and ISP, and forward the information.
In order to go around this, the attacker would have to be able to get
the domain registry information updated. I would hope the ISPs inform
domain owners when this is attempted or has happened.
Is there a flaw in my thinking, a reason why this wouldn't help?
Do you think this additional phone call might be an acceptable future
standard procedure for issueing any server certificate?
Kai
--
Sending me encrypted e-mail:
- get my S/MIME cert from https://kuix.de/smime-keyserver/
- get my GPG/PGP key from http://pgp.uni-mainz.de/
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
