5 ms·

I don't think this is a bad thing. ... This ought not be surprising: presumably, who better to say that Google is indeed Google than Google itself? The pro

I don't think this is a bad thing. ... This ought not be surprising: presumably, who better to say that Google is indeed Google than Google itself? The problem is that "connecting to a Google property" almost certainly includes their WiFi access points as well as other networking offerings. Which implies the ability to MiTM traffic encrypted from products not controlled by Google (other browsers, VPN clients, etc.). As stated in this Stackoverflow response[0]: Especially #2 is rather nasty, even if you pay for a highly trusted certificate, your site will not be in any way locked to that certificate, you have to trust all CAs in the client's browser since any of them can generate a fake cert for your site that is just as valid. It also does not require access to either the server or the client. I wouldn't be surprised if AMP is also in play for this type of MiTM, but do not know for certain. Android native apps, however, are definitely poised to be compromised. 0 - http://stackoverflow.com/a/14907718 http://stackoverflow.com/a/14907718

castillar76 10y ago
Google engineers have been very heavily involved in the CA/Browser Forum (https://cabforum.org https://cabforum.org), which sets issuance and trust rules for CAs. One of the things the CAB Forum is currently debating is a set of requirements mandating certificate transparency (CT) and obeying certificate authority authorization (CAA) records in DNS. If implemented for all of these roots (and I don't see why they wouldn't, given their push on it), CT would create an open, unalterable record of every cert published from all of these roots and their subordinates. CAA, as a complement, would create a method by which you as a domain owner could control which CAs are allowed to issue certs for your domain, removing the ability to man-in-the-middle your domain without your permission. The first step for both of these is making them mandatory for CAs (which Google is pushing hard on); once they're out there, it's possible to write plugins that will check CAA and CT records and fail closed if something looks wrong. It's a long way from perfect, but it's definitely a step in the right direction. Given Google's strong push for making those mandatory, I'm far more worried about a lot of the CAs already in my trust store than I am about these.
- hobarrera 10y ago
  For CAA to work, we need fully deployed DNSSEC. Not just the roots, and some resolver, but all local clients too. Otherwise, there's still weak links in the chain.
- AdieuToLogic 10y ago
  According to here[0], when you say: CT would create an open, unalterable record of every cert published from all of these roots and their subordinates. That provides no substantiation for Google's push to be a Certificate Authority (CA). It arguably makes a case for Google to be a "Log Server" (which has its own troubling implications as that could then (now?) hook Google into the verification process of every certificate issued[1]). But absolutely nothing about CT needs/implies/warrants Google to become a CA. Given Google's strong push for making those mandatory, I'm far more worried about a lot of the CAs already in my trust store than I am about these. The very authority to which you are appealing is precisely the one which is suspect. 0 - https://www.certificate-transparency.org/how-ct-works https://www.certificate-transparency.org/how-ct-works 1 - From [0]: During the TLS handshake, the TLS client receives the SSL certificate and the certificate’s SCT. As usual, the TLS client validates the certificate and its signature chain. In addition, the TLS client validates the log’s signature on the SCT ...

castillar76 10y ago

Google engineers have been very heavily involved in the CA/Browser Forum (https://cabforum.org https://cabforum.org), which sets issuance and trust rules for CAs. One of the things the CAB Forum is currently debating is a set of requirements mandating certificate transparency (CT) and obeying certificate authority authorization (CAA) records in DNS. If implemented for all of these roots (and I don't see why they wouldn't, given their push on it), CT would create an open, unalterable record of every cert published from all of these roots and their subordinates. CAA, as a complement, would create a method by which you as a domain owner could control which CAs are allowed to issue certs for your domain, removing the ability to man-in-the-middle your domain without your permission. The first step for both of these is making them mandatory for CAs (which Google is pushing hard on); once they're out there, it's possible to write plugins that will check CAA and CT records and fail closed if something looks wrong. It's a long way from perfect, but it's definitely a step in the right direction. Given Google's strong push for making those mandatory, I'm far more worried about a lot of the CAs already in my trust store than I am about these.

hobarrera 10y ago
For CAA to work, we need fully deployed DNSSEC. Not just the roots, and some resolver, but all local clients too. Otherwise, there's still weak links in the chain.
AdieuToLogic 10y ago
According to here[0], when you say: CT would create an open, unalterable record of every cert published from all of these roots and their subordinates. That provides no substantiation for Google's push to be a Certificate Authority (CA). It arguably makes a case for Google to be a "Log Server" (which has its own troubling implications as that could then (now?) hook Google into the verification process of every certificate issued[1]). But absolutely nothing about CT needs/implies/warrants Google to become a CA. Given Google's strong push for making those mandatory, I'm far more worried about a lot of the CAs already in my trust store than I am about these. The very authority to which you are appealing is precisely the one which is suspect. 0 - https://www.certificate-transparency.org/how-ct-works https://www.certificate-transparency.org/how-ct-works 1 - From [0]: During the TLS handshake, the TLS client receives the SSL certificate and the certificate’s SCT. As usual, the TLS client validates the certificate and its signature chain. In addition, the TLS client validates the log’s signature on the SCT ...