27 ms·

A bit OT, but there is a thing about CT that I keep asking me and I can't seem to find an answer: Say I use a letsencrypt certificate for my nextcloud installat

A bit OT, but there is a thing about CT that I keep asking me and I can't seem to find an answer: Say I use a letsencrypt certificate for my nextcloud installation on my home server. Now say that the german police is investigating on me. They call up the BSI and tell them "hey, can you please issue me a signed cert for nextcloud.y0ghur7.xxx so we can mitm this guy? And please, don't log it to the CT, so nobody will ever know" I will probably never know, because BSI is a trusted CA in all browsers and other http clients so they don't complain (and I am not looking at what certificate the server sent me every time I open my nc page), and nobody else will ever know that that certificate was released. Am I right? So what does CT buy me?

bouk 9y ago
At some point browsers will stop allowing certificates that are not logged through CT
- zer01 9y ago
  This is (imo) the most correct response to this query. The idea behind the CT lists is that browsers will flip into a "if it's no publicly identifiable, it's not valid" mode. The Coinbase Engineering blog actually just put out an article on this very topic today - https://engineering.coinbase.com/moving-to-expect-ct-d0d26a07046d https://engineering.coinbase.com/moving-to-expect-ct-d0d26a0....
- y0ghur7_xxx 9y ago
  > At some point browsers will stop allowing certificates that are not logged through CT Makes sense. So to be sure nobody issued a cert for one of my properties I would have to check regularly on CT logs to be sure that only certs requested by me are issued. But in that case, if someone requests a cert for one of my properties, and that cert was not requested by me, what do I do? Do I tell mozilla and google that "someone issued cert id 4d8effdd25 for my nextcloud installation (or my forum where some rebellious users meet up sometimes) to mitm me, but it was not me". Will they belive me? And it will be probably to late anyway, because propagation to a CT log can take up to one day, so they got data on all the traffic for a whole day.
  - tomschlick 9y ago
    That's what the CAA dns records are meant to prevent. It tells Certificate Authorities which of them are allowed to issue for your domain. Couple that with most providers requiring you to prove your domain via DNS or organizational status and you narrow the attack window. Also I'd assume that as the owner of a domain, you'd be able to revoke any certificate for your domain that you didn't create.
    - foota 9y ago
      Maybe that's the piece of the puzzle that's missing here? Being able to revoke a cert automatically by proof of domain ownership?
    - tomputer 9y ago
      That is mostly true, unless it's malicious Certificate Authority which may, on behalf of a governments request, ignore the CAA record on purpose to generate a certificate. This is where a TLSA record would help to prevent malicious certificates. At least, if the client (browser) validates TLSA records.
  - advisedwang 9y ago
    It's not part of CT, nor does it fully solve the issue, but you might also like Certificate Authority Authorization. CAA allows you to publish what CAs are acceptable for your domain via DNS. CAs shouldn't issues certificates against that. Of course that doesn't protect against a rogue, compromised or coerced CA, but it does protect against phony requests to the CA.
    - IgorPartola 9y ago
      It also doesn’t protect against compromised DNS, does it?
    - prdonahue 9y ago
      As you said, that only protects against CAs that follow the CA/B Forum Baseline Requirements that require they check CAA at issuance time. If a government was coercing a CA, they'd just tell them to disable this check. If this can be proven it's grounds to start the distrust process. At the very least, they should fail their next WebTrust audit.
- arkadiyt 9y ago
  > At some point browsers will stop allowing certificates that are not logged through CT Chrome is scheduled to do start doing this in April 2018
- Matt3o12_ 9y ago
  How can they efficiently do that? Will they send a request to Google/Mozilla/Firefox and asks if cert ABC logged? I see two issues with that: 1) the browser vendors know each site and subdomain I visit. This seems to be a privacy issue. 2) every new visits adds a lot of latency because they need to check the certificate every time I request a site (now it becomes: dns, ssl handshake, cert check, http transfer). 3) when the cert check server is down, what is supposed to happen? Fail every ssl request? This adds a new point of failure. Just allow it? An attacked could black-hole the dns or block the IP address.
  - y0ghur7_xxx 9y ago
    > How can they efficiently do that? The web server sends a Signed Certificate Timestamp in the TLS Handshake¹. The browser will check that. Apache support is coming², and other web server vendors are probably working on it as well. ¹https://tools.ietf.org/html/rfc6962#page-13 https://tools.ietf.org/html/rfc6962#page-13 ²https://httpd.apache.org/docs/trunk/mod/mod_ssl_ct.html https://httpd.apache.org/docs/trunk/mod/mod_ssl_ct.html
    - prdonahue 9y ago
      Even better is embedding the SCTs in the x509 structure itself so that you don't have to rely on obtaining/caching and the sending in the handshake. (Yes, there's some cases where a policy change my require the addition of additional SCTs—or different ones altogether—but this should be the exception not the norm.)
  - schoen 9y ago
    See "SCT" in https://www.certificate-transparency.org/how-ct-works https://www.certificate-transparency.org/how-ct-works
  - the8472 9y ago
    Similar to OCSP stapling the server could also include CT publication attestations.
merb 9y ago
if you want to mit the guy you would need to re-route ANY traffic from nextcloud.y0ghur7.xxx to the BSI datacenter, I'm not sure if that is even possible. (also this does not find the owner of the site, how they do that you can read more about the dozens of takedowns of black market sites inside the onion network (most of the time it is/was human error))
vetrom 9y ago
At least google chrome (and im sure plenty of other browsers) embed some certs (or at least their hashes) in the browser to protect against this sort of attack for some services. See https://news.ycombinator.com/item?id=9078506 https://news.ycombinator.com/item?id=9078506 for some discussion on this -- its a slightly different response to a slightly different threat model.
- y0ghur7_xxx 9y ago
  That's cert pinning. I think you are talking about something else.
eledra 9y ago
There is Certificate Transparency for that problem. It is on work though.
usernam 9y ago
Not answering the concert regarding CT (I concur). But the obvious answer for truly secure connections is your own CA root or a self-signed cert you manually install/enforce. You don't want to pass through another CA if your service is private. You actually don't need to. In fact, you'd want to manually enforce a single root or distrust system certificates entirely when doing so to avoid the problem you describe. Most decently-written software that supports SSL/TLS allows you do that. The CA system is for services that you intend to make public.
- y0ghur7_xxx 9y ago
  > But the obvious answer for truly secure connections is your own CA root or a self-signed cert you manually install/enforce. > Most decently-written software that supports SSL/TLS allows you do that. Unfortunately maintaining your own CA and installing it on all your devices is no easy feat. On android it's not even possible without root, and most IoT devices are not "decently-written". So what you say is true on paper, but delegating your CA to an external service like letsencrypt is unfortunately the only doable way as things are now.

bouk 9y ago

At some point browsers will stop allowing certificates that are not logged through CT

zer01 9y ago
This is (imo) the most correct response to this query. The idea behind the CT lists is that browsers will flip into a "if it's no publicly identifiable, it's not valid" mode. The Coinbase Engineering blog actually just put out an article on this very topic today - https://engineering.coinbase.com/moving-to-expect-ct-d0d26a07046d https://engineering.coinbase.com/moving-to-expect-ct-d0d26a0....
y0ghur7_xxx 9y ago
> At some point browsers will stop allowing certificates that are not logged through CT Makes sense. So to be sure nobody issued a cert for one of my properties I would have to check regularly on CT logs to be sure that only certs requested by me are issued. But in that case, if someone requests a cert for one of my properties, and that cert was not requested by me, what do I do? Do I tell mozilla and google that "someone issued cert id 4d8effdd25 for my nextcloud installation (or my forum where some rebellious users meet up sometimes) to mitm me, but it was not me". Will they belive me? And it will be probably to late anyway, because propagation to a CT log can take up to one day, so they got data on all the traffic for a whole day.
- tomschlick 9y ago
  That's what the CAA dns records are meant to prevent. It tells Certificate Authorities which of them are allowed to issue for your domain. Couple that with most providers requiring you to prove your domain via DNS or organizational status and you narrow the attack window. Also I'd assume that as the owner of a domain, you'd be able to revoke any certificate for your domain that you didn't create.
  - foota 9y ago
    Maybe that's the piece of the puzzle that's missing here? Being able to revoke a cert automatically by proof of domain ownership?
  - tomputer 9y ago
    That is mostly true, unless it's malicious Certificate Authority which may, on behalf of a governments request, ignore the CAA record on purpose to generate a certificate. This is where a TLSA record would help to prevent malicious certificates. At least, if the client (browser) validates TLSA records.
- advisedwang 9y ago
  It's not part of CT, nor does it fully solve the issue, but you might also like Certificate Authority Authorization. CAA allows you to publish what CAs are acceptable for your domain via DNS. CAs shouldn't issues certificates against that. Of course that doesn't protect against a rogue, compromised or coerced CA, but it does protect against phony requests to the CA.
  - IgorPartola 9y ago
    It also doesn’t protect against compromised DNS, does it?
  - prdonahue 9y ago
    As you said, that only protects against CAs that follow the CA/B Forum Baseline Requirements that require they check CAA at issuance time. If a government was coercing a CA, they'd just tell them to disable this check. If this can be proven it's grounds to start the distrust process. At the very least, they should fail their next WebTrust audit.
arkadiyt 9y ago
> At some point browsers will stop allowing certificates that are not logged through CT Chrome is scheduled to do start doing this in April 2018
Matt3o12_ 9y ago
How can they efficiently do that? Will they send a request to Google/Mozilla/Firefox and asks if cert ABC logged? I see two issues with that: 1) the browser vendors know each site and subdomain I visit. This seems to be a privacy issue. 2) every new visits adds a lot of latency because they need to check the certificate every time I request a site (now it becomes: dns, ssl handshake, cert check, http transfer). 3) when the cert check server is down, what is supposed to happen? Fail every ssl request? This adds a new point of failure. Just allow it? An attacked could black-hole the dns or block the IP address.
- y0ghur7_xxx 9y ago
  > How can they efficiently do that? The web server sends a Signed Certificate Timestamp in the TLS Handshake¹. The browser will check that. Apache support is coming², and other web server vendors are probably working on it as well. ¹https://tools.ietf.org/html/rfc6962#page-13 https://tools.ietf.org/html/rfc6962#page-13 ²https://httpd.apache.org/docs/trunk/mod/mod_ssl_ct.html https://httpd.apache.org/docs/trunk/mod/mod_ssl_ct.html
  - prdonahue 9y ago
    Even better is embedding the SCTs in the x509 structure itself so that you don't have to rely on obtaining/caching and the sending in the handshake. (Yes, there's some cases where a policy change my require the addition of additional SCTs—or different ones altogether—but this should be the exception not the norm.)
- schoen 9y ago
  See "SCT" in https://www.certificate-transparency.org/how-ct-works https://www.certificate-transparency.org/how-ct-works
- the8472 9y ago
  Similar to OCSP stapling the server could also include CT publication attestations.

merb 9y ago

if you want to mit the guy you would need to re-route ANY traffic from nextcloud.y0ghur7.xxx to the BSI datacenter, I'm not sure if that is even possible. (also this does not find the owner of the site, how they do that you can read more about the dozens of takedowns of black market sites inside the onion network (most of the time it is/was human error))

vetrom 9y ago

At least google chrome (and im sure plenty of other browsers) embed some certs (or at least their hashes) in the browser to protect against this sort of attack for some services. See https://news.ycombinator.com/item?id=9078506 https://news.ycombinator.com/item?id=9078506 for some discussion on this -- its a slightly different response to a slightly different threat model.

y0ghur7_xxx 9y ago
That's cert pinning. I think you are talking about something else.

eledra 9y ago

There is Certificate Transparency for that problem. It is on work though.

usernam 9y ago

Not answering the concert regarding CT (I concur). But the obvious answer for truly secure connections is your own CA root or a self-signed cert you manually install/enforce. You don't want to pass through another CA if your service is private. You actually don't need to. In fact, you'd want to manually enforce a single root or distrust system certificates entirely when doing so to avoid the problem you describe. Most decently-written software that supports SSL/TLS allows you do that. The CA system is for services that you intend to make public.

y0ghur7_xxx 9y ago
> But the obvious answer for truly secure connections is your own CA root or a self-signed cert you manually install/enforce. > Most decently-written software that supports SSL/TLS allows you do that. Unfortunately maintaining your own CA and installing it on all your devices is no easy feat. On android it's not even possible without root, and most IoT devices are not "decently-written". So what you say is true on paper, but delegating your CA to an external service like letsencrypt is unfortunately the only doable way as things are now.