Re: For discussion: MECAI: Mutually Endorsing CA Infrastructure
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 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
Re: For discussion: MECAI: Mutually Endorsing CA Infrastructure
On 07.02.2012 17:54, Ondrej Mikle wrote: The phone calls would ensure that each registered person will be aware of the certificate issuance. This is getting very close to EV validation (Sovereign Keys have the same issue). I'd say making phone calls is less effort than checking business documents, so I'm not convinced it's close to EV - because EV is out of reach for anyone running a private server. How do you plan on handling CDN services (ones with many certs)? That's a reason why I propose vouchers to be IP specific. In my understanding, each IP will have only a single certificate, regardless from where in the world you connect to it. Another weak point I see is the DNS server for the domain (only exception for this seems to be Transparent Certificates and EV validation; everything else is susceptible - DANE, Sovereign Keys...). What about this attack scenario: 1. attacker compromises DNS server for domain.com or redirects NS record 2. now of course he can get DV-validated cert and MitM mails (in contrary to the "attacker close to webserver", now it does not matter where MX for domain.com pointed to) EV doesn't help if the attacker simply decides to get a plain DV cert and hopes that a sufficient amount of users won't notice the missing green. Cert transparency requires that the domain owner constantly watches the public logs for new certs, and then you have the problem that the cert was already produced and appended to the log - you must wait for revocation. In your exaple the attacker makes a global modification to DNS, to ensure the route from CA will point to the attacker that is elswhere on the web. But if the domain is supposed to watch something anyway (e.g. cert transparency log), then the domain owner could simply watch public DNS for changes. They could ask a monitoring company to watch DNS and notify them by phone if it changes. Or they could setup a watchdog on their own on some hosted VPS elsewhere on the web. They could quickly detect the DNS manipulation, and maybe even prevent the cert from being issued. Maybe we should require that CAs must always send out multiple emails whenever a certificate is being requested, even for EV. In addition to the usual approval message to host/web/sslmaster@domain, it could be mandatory that the CA sends notification emails to each of the email addresses found in the domain registry. If the domain owners are smart, they will use email addresses from secondary domains. Thus, even if the attacker can hijack the DNS of the domain in question, the attacker might be unable to do it for those secondary domains, too. If the domain owners receive notification about a fraudulent certificate request, they can quickly react. At least they will know which CA might soon issue a false certificate - and the domain owner can contact that CA and request cancellation or revocation. If the CA were required to make phone calls to domain registry entries, even for DV, whether owner is an organization or a private person, this attack wouldn't succeed. 3. attacker tricks registrar into changing WHOIS data or transferring domain. Feasibility of this step heavily depends on registrar's procedures, but sometimes they just send some authcookie to mailbox attacker controls. (There was also an incident with a registrar that suffered from CSRF which could make victim unwittingly change registration data.) I think this attack is beyond the "CA's power are abused and it goes undetected" attack vector, which is the primary problem I'm trying to solve with the MECAI proposal. Being able to modify WHOIS data and hijack a domain is a separate attack and might require solutions from a different angle. I think the best we can do in the short term is to achieve quick detection of abused CA powers, and get certificates revoked, and make revocation checks strict. Kai -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: For discussion: MECAI: Mutually Endorsing CA Infrastructure
My previous message was a proposed solution to the problem "attacker is
close to the server and uses it to obtain a new fraudulent cert", and I
proposed to use an organizational approach to prevent that attack.
In addition, another potential attack is, the attacker has obtained a
certificate from a "hacked CA", so that no approval process was
necessary. In addition the attacker is close to the router, so that the
routes from most (or even all) other CAs can be controlled by the
attacker, which means the routes from all vouching authorities can be
controlled by the attacker. With the solution described so far, MECAI
wouldn't be helpful, because all CAs would happily produce a voucher for
the attacker.
I hope we can come up with an incremental solution for this attack
vector on top of the current MECAI proposal.
Here is an initial idea for a solution. It requires that vouching
authorities keep a record of the recently seen certificates. Whenever a
server desires to switch to a newer certificate, the server must use TLS
client authentication with any of the recently seen certificates.
More detailed description:
(Note I mix the terms CA and vouching authority, but both should refer
to the vouching authority.)
In the beginning, the CA's bookkeeping state for an IP address is empty.
The first time a CA receives a request for vouching for a new IP address
with no previous state (or with an expired state), the vouching
authority will only check the ownership of the certificate (requires
client authentication using this certificate on the incoming connection
from the server, and by performing the TLS handshake to the IP,
connection initiated by the vouching authority, requiring that the
server uses the same certificate).
The CA will remember the assocation {IP, certificate}. In future
requests, as long as this requesting IP requests a voucher for the same
certificate, the described bidirectional authentication and verification
will be sufficient.
If an IP requests a voucher for a renewed certificate which continues to
use the same key pair, no additional proof is necesary.
As soon as an IP requests a voucher for a certificate with a different
key pair, the server must prove ownership of the previous certificate.
This can be done as part of the server-requests-voucher protocol. In
addition to the previously described checks, the vouching authority will
challenge the server with random data chosen by the authority. The
server must respond with a digital signature of the random data, which
was created using the private key that belongs to the previous certificate.
What happens if an attacker uses a false certificate for a domain that
is not yet using SSL? The worst that can happen is a temporary denial of
service attack to start using SSL, because it makes it harder for the
real domain owner to switch away from the false bookkeeping, which is
being kept by the vouching authorities. However, as soon as the false
certificate used by the attacker has been revoked, the vouching
authorities will revert to the "empty" bookkeeping state. Also, because
vouchers are per IP, the real domain owner can simply ensure that a
different IP address will be used for the real server. Also, it should
probably be defined that the bookkeeping done by vouching authorities
(the pairs of {IP, certificate}) will expire 10 days after no more
requests using a valid certificate were made for the given IP.
The vouching authorities are expected to keep multiple recent records
per IP, if there are incoming requests using more than one certificate.
For example, a server could prepare for a revocation scenario, by owning
two certificates from two separate CAs. The server could daily request
vouchers for both certificates. Now, if one of the two issueing CAs got
compromised and revoked, or if one of the server certificates gets
revoked, the server can continue to use the other certificate for
authentication to the voucher authority. This also allows the server to
get a voucher for a new replacement certificate obtained from a third CA.
In other words, if the vouching authority has bookkeeping records about
valid authenticated requests from an IP for two different certificates,
then any of both certificates will be valid for authentication and
requesting vouchers for future certificates (until the bookkeeping
record for an older certificate expires).
Kai
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: For discussion: MECAI: Mutually Endorsing CA Infrastructure
Hi, Kai Engert wrote: > 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. [...snip...] > The phone calls would ensure that each registered person will be aware > of the certificate issuance. This is getting very close to EV validation (Sovereign Keys have the same issue). How do you plan on handling CDN services (ones with many certs)? Convergence and Perspectives suffer from that as well. Another weak point I see is the DNS server for the domain (only exception for this seems to be Transparent Certificates and EV validation; everything else is susceptible - DANE, Sovereign Keys...). What about this attack scenario: 1. attacker compromises DNS server for domain.com or redirects NS record 2. now of course he can get DV-validated cert and MitM mails (in contrary to the "attacker close to webserver", now it does not matter where MX for domain.com pointed to) 3. attacker tricks registrar into changing WHOIS data or transferring domain. Feasibility of this step heavily depends on registrar's procedures, but sometimes they just send some authcookie to mailbox attacker controls. (There was also an incident with a registrar that suffered from CSRF which could make victim unwittingly change registration data.) The rest is identical like in the "close to webserver" case, with an extra "bonus" that attacker may make the server appear working fine when sending DNS responses to original owner's home/work network using low TTL. The attacker can also fool Convergence this way, because he'll let the notaries see both original cert and fraudulent cert. Since question to Convergence is "Is this hash of domain.com OK?", Convergence notary looks into DB and says "Sure, seen it." In my clone of Perspectives server I simply store all seen certs with full chains, with possibly overlapping time periods (so operator could check it). An ad-hoc solution for DNS-hacking would be passive DNS database, but attacker must not know which IPs/networks belong to probes. (With so many observatories we are slowly moving towards Peter Gutmann's continuity idea.) Ondrej -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
