Why not just use the secure domain transfer identifier? Only the real holder
of the domain has that.
-Kyle H
On Mon, Feb 6, 2012 at 12:21 PM, Kai Engert <k...@kuix.de> wrote:
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
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
