Re: For discussion: MECAI: Mutually Endorsing CA Infrastructure
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 -- 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 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 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org
Re: For discussion: MECAI: Mutually Endorsing CA Infrastructure
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. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online -- 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 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
--
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
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
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
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
Re: For discussion: MECAI: Mutually Endorsing CA Infrastructure
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
Re: OCSP-in-DNS (was Re: For discussion: MECAI: Mutually Endorsing CA Infrastructure)
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 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
OCSP-in-DNS (was Re: For discussion: MECAI: Mutually Endorsing CA Infrastructure)
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 -- 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 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
For discussion: MECAI: Mutually Endorsing CA Infrastructure
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 -- 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 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 -- 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 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:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
