For discussion: MECAI: Mutually Endorsing CA Infrastructure

[Kai Engert]

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 and Regards
Kai

[Marsh Ray]

On 10/21/2011 08:09 AM, Kai Engert wrote:
> This is an idea how we could improve today's world of PKI, OCSP,
> CA's.
>
> https://kuix.de/mecai/

This is great. We need these kinds of ideas.

> Review, thoughts and reports of flaws welcome.

OK, this is a serious thought, not just a flippant remark:

Why would CAs want to act as VAs, and more importantly, why would they
want to revoke their vouching?

CAs seem to put a lot of emphasis on structured legal
agreements/contracts. Surely they have such agreements in place when
they cross-sign each other, so they would likely want them for this VA
system. Contracts are enforced primarily by legal action with courts and
lawyers and this adds very concrete risks and expenses even in the
clearest of cases. On the other hand, declining to stop vouching for a
partner CA experiencing some "moderate problems" (e.g. some compromised
resellers issued fraudulent certs that were eventually revoked) seems
associated with purely abstract risks (e.g. loss of confidence in the
system as a whole).

CAs are not the Relying Parties (i.e., users) and they're not even the
software vendors to the RPs (like Mozilla). It's not clear to me if they
feel the RPs are actually party to these contracts or to what extent
they otherwise consider themselves liable to the RPs. But I suspect that
the CAs themselves would be at least as reluctant to eliminate one of
their fellow members as a vendor of client software.

So is providing the CAs collectively with a tool to more efficiently
reinforce or remove endorsements amongst themselves going to result in a
substantial improvement over the system we have now?

Or would the cost of new infrastructure be better spent on something
else like, say, a more robust mechanism for informing users about
software security updates?

- Marsh

[Marsh Ray]

[Eddy Nigg]

On 10/21/2011 03:09 PM, From Kai Engert:

> 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.
>

Interesting - but it probably will never work. I don't see CAs
cooperating to this extend, it will probably create a few other issues
on the way.

However I'm still not sure why hard fail for revocation status can't be
enforced. You've got OCSP, CRLs and if browsers implement fail-over and
redundancy correctly, it could work already today I guess. From my
experience it's the browsers which fail to use the full potential.

For CAs that don't provide sufficient alternatives (multiple OCSP URIs,
CRLs), redundant servers etc., subscribers will find better sources for
their certificates.

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

[Kai Engert]

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/

After more brainstorming I came up with some incremental ideas.

Thanks a lot to Adam Langley for pointing out scenarios that weren't yet
sufficiently handled by the design I had presented earlier.

(a) Need better handling for swapping certs in large deployments, in
particular, the need to create vouchers for new certs, while the old
certs are still being actively used.

(b) The requirement that servers constantly (at least daily) require
updated configuration appears impracticable for some environments.

(c) The proposal so far assumed that each server is aware of its own IP
address, and can use an appropriate voucher. But maybe that's not true?
Maybe we need something more flexible?


Proposed solution for (a):

Let's design the voucher-fetching protocol to use any port. The
initially described idea was, a server connects to the vouching
authority (VA), asks for a voucher, and the VA will call back, by
contacting the port in question.

This was based on the idea, a voucher should be port specific. I want to
move away from this proposal. Let's define that a voucher for hostname
A.B.COM can be valid for any port number at hostname A.B.COM

If a server is in possession of multiple valid certificates, it should
be allowed to obtain a voucher for each of them.

If A.B.COM is currently configured to use cert C-1, but plans to switch
to C-2 soon, it must be able to prepare by obtaining a voucher for C-2.

This can be solved, if the server can instruct the VA to contact a
secondary service/port on the hostname, e.g. 444.

While the primary port (443) still uses C-1, the service at port 444 can
be configured to use C-2.

The primary port is used for production, while the secondary port is
simply used to assist in the configuration update. It can be a minimal
service that shuts down the connection after the TLS handshake has been
completed (doesn't offer any application data).


Proposed solution for (b) and (c):

Instead of delivering the vouchers inside of the TLS handshake, let's
broadcast them using DNS!

I had this idea just two hour ago, and I currently think (hope) it
indeed solves several problems.

S-C-Hash: A hash of a server certificate.
VA-N-Hash: A hash of a Vouching Authority's subject name
A.B.COM: A server's hostname.

As explained in the MECAI documents, the operator of a server must
regularly fetch new vouchers from many Vouching Authorities. However,
with the DNS approach, it seems sufficient to do it just once per active
server certificate (not for each IP).

The domain owner will publish multiple DNS records, one for each
combination of {Server Certificate, Vouching Authority} of the following
form:

{VA-N-Hash}.{S-C-Hash}.A.B.COM => The Voucher
(which includes recent OCSP data)

In other words, the site can publish vouchers for both C-1 and C-2 in
parallel.

A client connects to the server and obtains the server's certificate.
Then the client will attempt to find vouchers in DNS, from VAs it trusts.

The client will require (e.g.) at least 2 fresh and valid vouchers,
which are issued by VAs that are unrelated to the server certificates
issueing CA, and it will require that each voucher chains up to a
different root CA/VA.

Also, this DNS approach helps to keep the size of TLS handshakes small,
and it increases the flexibility on the client side. The client can
continue to query DNS for vouchers until it has found a sufficient
number of vouchers it trusts.

This new variation of MECAI still requires daily updates for the
vouchers, however, they now live in DNS.

In environments where multiple servers host a single hostname, the
system that fetches vouchers and updates the information in DNS can be a
different computer than the one(s) running the production site.


The original idea is still: As soon as CAs/VAs are aware that a CA got
hacked, they can blacklist it and stop issueing vouchers. (Or more
easily, they will recognize that a cert is revoked because of
information found in CRL or OCSP).

As soon as the vouchers in DNS have expired, and clients are no longer
able to obtain a sufficient amount of vouchers, the compromised certs
can be treated as revoked. This is the slow scenario.

In the fast scenario, where no DNS manipulating hackers are involved, a
domain owner could contribute to quick distribution of revocation
information, by adding OCSP revocation data to DNS. Maybe we could
define that DNS entries like
{S-C-Hash}.A.B.COM => OCSP record (revoked)


I haven't researched, but has anyone already thought of distributing
OCSP records using DNS in general?

If we had OCSP-in-DNS, we might not even require OCSP stapling. This
could run as a service completely independent of the SSL servers - only
clients would need to be updated to fetch OCSP from DNS - does this make
sense?


However, even with OCSP available in DNS, we might still need something
like MECAI, in order to deal with the absence of OCSP information.

Kai

[Rob Stradling]

On Wednesday 07 Dec 2011 04:19:09 Kai Engert wrote:
<snip>

> I haven't researched, but has anyone already thought of distributing
> OCSP records using DNS in general?
>
> If we had OCSP-in-DNS, we might not even require OCSP stapling. This
> could run as a service completely independent of the SSL servers - only
> clients would need to be updated to fetch OCSP from DNS - does this make
> sense?

Hi Kai.

We discussed OCSP-in-DNS over at m.d.s.policy earlier this year...
https://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/a5f14bbd3159c44f/446abd478dc847ec
(it's a long thread, but it does contain a lot of useful thoughts)

Recalling that discussion, Gerv recently said...
https://mail1.eff.org/pipermail/observatory/2011-September/000405.html
"...the arguments for something DNS-based are IMO very strong (much better
privacy story, very hard to DOS, cached and distributed)."

Peter Gutmann lists numerous deficiencies with the OCSP protocol - e.g. see
here...
https://mail1.eff.org/pipermail/observatory/2011-September/000330.html
I think that any future DNS-based certificate status checking protocols should
at least consider addressing some of these issues.

<snip>

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Kai Engert]

Just a quick thought, that I don't want to lose.

Maybe it would be a reasonable middle-ground to define:
- for intermediate CAs, OCSP information is published in DNS
- for servers, we use OCSP stapling

(Rob, thanks for your response, I'm still digesting.)

Regards
Kai

[Kai Engert]

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/

[Ondrej Mikle]

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

[Kai Engert]

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

[Kai Engert]

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

[Kyle Hamilton]

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 <ka...@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.
>

> --
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto

[Kyle Hamilton]

[Ondrej Mikle]

On 02/07/2012 09:58 PM, Kai Engert wrote:
> 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.

Sure, provided that you call the right owner.

>> 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.

It's not true in general. There are services hidden with a load-balancer
behind a single IP. An example - 3m.com:

% dig +short 3m.com
192.28.34.26 #note: it's not fast-flux, TTL is 86400

% openssl s_client -tls1 -connect 192.28.34.26:443 -servername 3m.com
</dev/null 2>/dev/null | openssl x509 -noout -fingerprint -sha256
-issuer -subject
SHA256
Fingerprint=0A:F6:9B:2A:7C:C5:7C:7E:36:1F:49:02:EF:A4:8B:1E:4D:F6:44:43:CF:AF:8F:22:75:E8:BA:B8:61:49:A0:65
issuer= /C=US/O=Thawte, Inc./CN=Thawte SSL CA
subject= /C=US/ST=Minnesota/L=Saint Paul/O=3M Company/OU=3M Company -
P9/CN=*.3m.com

% openssl s_client -tls1 -connect 192.28.34.26:443 -servername 3m.com
</dev/null 2>/dev/null | openssl x509 -noout -fingerprint -sha256
-issuer -subject
SHA256
Fingerprint=40:21:0B:40:1F:1E:7D:61:D5:8B:C9:60:6C:07:1D:F0:1B:85:55:4D:5A:95:14:16:84:45:42:AD:82:44:97:CE
issuer= /C=US/O=Thawte, Inc./CN=Thawte SSL CA
subject= /C=US/ST=Minnesota/L=Saint Paul/O=3M Company/OU=3M Company -
P11/CN=*.3m.com

% openssl s_client -tls1 -connect 192.28.34.26:443 -servername 3m.com
</dev/null 2>/dev/null | openssl x509 -noout -fingerprint -sha256
-issuer -subject
SHA256
Fingerprint=7A:0F:F7:50:9E:8A:67:57:5A:6E:08:16:0C:A4:C2:11:D6:DD:A0:79:78:FC:49:23:8F:9A:30:B6:F6:0E:05:98
issuer= /C=US/O=Thawte, Inc./CN=Thawte SSL CA
subject= /C=US/ST=Minnesota/L=Saint Paul/O=3M Company/OU=3M Company -
P10/CN=*.3m.com

Here's a survey on CDNs done around November 2011 that shows the CDN
services (IPs are not recorded, but a simple script could check which
ones are just behind single IP):

http://constructibleuniverse.net/CDN/CDN_hosts.csv

It's CSV with '|' delimiter, fields: domain, DB id, issuer Org, issuer
CN, first seen, last seen.

> 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.

Maybe I wasn't clear before: I'm not saying EV certs would help, just
that the administrative demands/costs of verification process in
MECAI/SK are getting close to EV validation. (Technically, we could talk
about OV/IV validation instead of EV.)

> 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.

Yes. The difference between the "attacker close to webserver" and
"compromised DNS" is just in the available attack vectors:

- with DNS, it makes it easier if MX points to other machine than
webserver and makes attacking registrar as an option, whereas
- attacker "close to webserver" requires that MX points to the webserver
and that active attacker can do downgrade attack to SMTPS (if SMTPS is
used; or the webserver itself is compromised).

> 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.

I'd also add that the secondary domain should be registered with
different registrar than primary domain.

> Being able to modify WHOIS data and hijack a domain is a separate attack
> and might require solutions from a different angle.

It's a separate attack, but unfortunately very feasible (I am inclined
to say that it's generally easier than attacking a CA).

Ondrej

[Rob Stradling]

On 08/02/12 12:43, Ondrej Mikle wrote:
> On 02/07/2012 09:58 PM, Kai Engert wrote:

<snip>

>> 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.
>
> It's not true in general. There are services hidden with a load-balancer
> behind a single IP. An example - 3m.com:

Also, a TLS Server might choose a different cert depending on the cipher
suite list provided by the TLS client.

e.g.

$ openssl s_client -connect tls.secg.org:40023 -cipher RSA 2> /dev/null
| grep "Certificate chain" -A 3
Certificate chain
0 s:/OU=SAMPLE ONLY/O=Certicom
Corp./L=Toronto/SN=Ontario/CN=tls.secg.org RSA 1024 Server Certificate/C=CA
i:/OU=SAMPLE ONLY/O=Certicom
Corp./L=Toronto/SN=Ontario/CN=tls.secg.org RSA 1024 Certificate
Authority/C=CA
---

vs

$ openssl s_client -connect tls.secg.org:40023 -cipher ECDSA 2>
/dev/null | grep "Certificate chain" -A 5
Certificate chain
0 s:/OU=SAMPLE ONLY/O=Certicom
Corp./L=Toronto/ST=Ontario/CN=tls.secg.org ECC secp256r1 Server
Certificate/C=CA
i:/OU=SAMPLE ONLY/O=Certicom
Corp./L=Toronto/SN=Ontario/CN=tls.secg.org ECC secp256r1 Certificate
Authority/C=CA
1 s:/OU=SAMPLE ONLY/O=Certicom
Corp./L=Toronto/SN=Ontario/CN=tls.secg.org ECC secp256r1 Certificate
Authority/C=CA
i:/OU=SAMPLE ONLY/O=Certicom
Corp./L=Toronto/SN=Ontario/CN=tls.secg.org ECC secp256r1 Certificate
Authority/C=CA
---

AFAIK, such configurations are not widespread today, but this would
change if/when ECC certs start to be used more widely.

--

[Ondrej Mikle]

On 02/07/2012 06:04 PM, Kai Engert wrote:
> 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.

Just a technicality: {IP, list of certificates, FQDN} instead of {IP,
certificate} (see my previous post to dev.tech.crypto).

We should also investigate how various cloud services (Amazon, Akamai,
...) handle IP-to-server mapping. I don't know how often does that change.

> 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.

Sovereign Keys need to solve the same issue:
https://git.eff.org/?p=sovereign-keys.git;a=blob;f=issues/transitional-considerations.txt;h=fa3b1591820baf1f2f62740f1f0e8b7998c29174;hb=HEAD

What happens if domain is sold and former owner won't cooperate with
issuing new voucher or hand over private key for former server cert? How
can a vouching CA know that new owner is not an attacker?

I'll post a note about this discussion to sovereign-keys list, I think
they'd be interested as well.

Ondrej

[Julien Pierre]

Kai,

On 2/7/2012 12:58, Kai Engert wrote:
>
> 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.
>

That's definitely an incorrect assumption to make.
There can be a very large number of different certs on a single port/IP
combination.
The server name indication extension is one reason - there may be
different certs for different values of SNI.
Different cipher suites in the ClientHelo message as previously
mentioned can lead to certs with different KEAs.
Load balancers are yet another reason - you may end up connecting to
separate servers which could have their own separate certificates -
though not necessarily, the keys and certs could just be cloned across a
server farm .
The new Oracle Traffic Director product, which is NSS-based, supports
all the above different configurations.

Julien

[Julien Pierre]