How do you prevent mistakenly issuing certificates?

[GlenKPeterson]

Prominent, expensive certificate authorities go through a fairly elaborate offline background check to verify that a company who purchases their certificates 1. actually exists, 2. is the entity who requested the certificate, and 3. owns the appropriate domain. I guess your certificates are DV (Domain Validated) and what I'm talking about is OV (Organization Validated):
http://www.zdnet.com/will-lets-encrypt-threaten-commercial-certificate-authorities-7000036022/

Improperly issued certificates have been used to spoof legitimate sites, and, in some case, install malicious software or spy on unsuspecting users. Several examples are mentioned in the 2nd or 3rd paragraph here:
http://www.certificate-transparency.org/what-is-ct

How do you prevent this kind of misuse? Or are you planning to coordinate your release with the roll-out of Certificate Transparency (previous link)? Are you relying on DNS to establish identity? I've never heard anyone say that DNS was designed to be secure, but maybe it's better than I think. Maybe if you used enough unrelated DNS servers, accessed through unrelated networks, compared them with a huge local DNS cache, and only issued certificates when all DNS sources have agreed for some length of time...

There is no iron clad security. But a false sense of security is no good either. I don't know what, if any code changes are called for to answer these questions, but I would appreciate if you pointed me to any public documentation about how these concerns are mitigated.

P.S.
It looks like your certificates are all currently registered with the University of Michigan:
https://github.com/letsencrypt/lets-encrypt-preview/blob/master/letsencrypt/client/crypto_util.py#L77

What's in place to protect U of M from being liable if misuse happens?

Not sure if this is the right place to post this... I just signed up for your mailing list, but I didn't see any messages there yet.

[GlenKPeterson]

Understanding is dawning slowly...

I guess doing DV automatically is how many CA's work today. Still, I worry that the incentive to trick CA's into issuing rogue certificates will be greater when 90% of web traffic is encrypted than when 10% is encrypted. I'd like to see the security go up a notch to compensate for this. Maybe Certificate Transparency is that notch? If you found a different notch, I'd love to be made aware of it.

[jdkasten]

Hi Glen! Welcome to the project.

I will try to answer your questions the best that I can in order.

1. OV/EV certificates are actually a very small segment of the market. We have done many studies on the state of HTTPS certificates at the University of Michigan. Here is a general overview. We have also published our data at https://scans.io. You will find that the vast majority of the market is DV certificates.
2. As security researchers, we are aware that CAs have been tricked into issuing fraudulent certificates in the past. This has been widely publicized and goes back for many years. We have considered the current verification techniques used by CAs and are developing challenges that are standardized, and strictly stronger than what is in use today. Standardization is key, as the HTTPS CA infrastructure is only as strong as its weakest link. I would be happy to discuss why I believe the challenges proposed are stronger than the current practices if you are interested. I am a big proponent of DVSNI.

Here are a few examples of what other CAs appear to be offering...
GoDaddy
http://support.godaddy.com/help/article/7452/creating-a-web-control-page-for-ssl-validation

Trustwave
https://ssl.trustwave.com/support/support-validation.php

Comodo - practice is also found in several Comodo owned subCAs
Option 3: HTTP(S)-based DCV
https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/791/16/alternative-methods-of-domain-control-validation-dcv

InCommon
http://www.incommon.org/certificates/repository/Initiating_DCV_in_InCommon_CM.pdf

SSL.com - (I have not investigated the exact organization that owns this CA/reseller)
https://support.ssl.com/Knowledgebase/Article/View/29/0/alternative-methods-of-domain-control-validation-dcv

The exact CA policy is yet to be determined and I unfortunately cannot speak about that.

However, we are striving to improve the state-of-the-art. We have many additional resources available to us to make good decisions on regards to certificate issuance. The University of Michigan has been monitoring HTTPS for years now and the EFF has been running the SSL Observatory. We think it's very important to support ongoing improvements in the transparency of the certificate issuance process so that misissued certs can be detected immediately (and so that sites that do already have certs have practical tools to prevent misissuance of additional certs). Fortunately there are a lot of ongoing projects exploring ways of doing these things, certificate transparency being one of them. Our CA will be looking at what the most appropriate ways we can act to prevent misissuance are. We want to be more cautious and more transparent than existing DV issuers in the industry, not only so that we won't be the weakest link in the system, but so that we can help encourage deployment and adoption of technologies that make the CA system stronger and safer.

One example in regards to DNS: You may notice that the specification for DVSNI already states that CAs should use multi-path probing techniques (connecting to the server through many different network paths) in order to avoid attacks.

----- I will continue the conversation in a following comment coming shortly ----

[jdkasten]

The code you are referencing is just the generation of the CSR or (Certificate Signing Request). CAs will generally strip out just the CN (Common Name) SANs (Subject Alternative Names) and public key.

Everything else is generally thrown out for CSRs in DV certificates. When I wrote that code I was just having some fun with it.

You will notice that the certificate issued from the simple demo CA does not contain any of this organizational information. CAs must be prepared to handle all inputs and authorize certificates appropriately. I can generate a CSR for github.com and submit it to any CA. It is the CA's job to verify that I actually own the domain/organization I am requesting.

In reference to your second message here:
I will give you one other example of an improvement to the existing infrastructure that may conflict with certificate transparency to demonstrate that there are trade-offs.

It has been well documented that revocation is not an effective mechanism for certificates. one of many sources. We have the opportunity to issue short-lived certificates, given that they will now be easy to install. I will refrain from going into a long discussion about why short-lived certificates are fantastic, but it should be easy to see that it does solve the revocation problem by providing a narrow window of attack.

Certificate Transparency requires a continuous log of all certificates, if we all of a sudden begin issuing certificates at an unprecedented rate, (increased HTTPS deployment + 100x the number of certificates for every website) will the CT logs be able to keep up?
In short, there are costs to deploying different technologies.

I hope this answers your initial questions! Feel free to send any others that may come up!

[jdkasten]

@GlenKPeterson I should mention... that I don't believe the incentives to attack HTTPS will be any greater. When CAs are attacked, they are attacked for domains that reside in the Alexa Top 1000. The targeted sites are already using HTTPs by receiving a certificate from a different CA and they often have some of the best configurations and internal policies, such as configuring their servers with HSTS.

There are somewhere around ~650 different organization that have CAs that are already open to attack. Any CA can sign for any domain and the system is only as strong as its weakest link. This paper sheds more light on the attack surface of HTTPS.

The only question is whether the Let's Encrypt CA will weaken the ecosystem as a whole. That is why posing stronger challenges and having tighter policies is important to the working group. By standardizing strong challenges and working within the community, we can improve the security of the ecosystem as a whole, all while enabling HTTPS for everyone.