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
