3 ms·

A lot do, but without knowing it. Chrome uses an 'expect-CT' header, which means the sites TLS cert should chain to a root CA, with both stored in a CTL.

tialaramex 5y ago
I don't think that's what your parent post meant, but, Chrome actually mechanically requires CT logging in order to trust a site, the expect-CT header doesn't come into it. Safari has the same policy, and Mozilla intends to some day do likewise in Firefox but the politics of the exact rules are tricky for reasons we could get into if somebody cares. When your Chrome connects to a TLS server, the server has to provide a certificate, and Chrome examines that certificate before any HTTP traffic happens (and thus before you could send an HTTP header like Expect-CT anywhere) unless you've got Group Policy or similar rules saying otherwise: - The certificate must have proof it was logged in the form of SCTs. For most sites the SCTs are baked into the certificate when they got it, they're all that incomprehensible gibberish near the end of your certificate if you've read it. - The certificate must have been issued relatively recently (825 days or less previously) and it must expire within 825 days of issuance or if it was issued since some time in 2020 when Apple's policy change happened, 398 days. - The certificate says it is for TLS Servers (in most cases certificates say they're also for TLS Clients, and sometimes other things too, but Chrome checks it says specifically TLS Servers here) - The certificate has a Subject Alternative Name matching the DNS name of the server, or, if the URL we're resolving is for a numeric IP address, a SAN matches that IP Address. SANs are typed, and are not free human text, so a DNS SAN and an IP address SAN are distinguishable even if 10.20.30.40 was a valid DNS name, which it is not. Old-fashioned "Common" names are disregarded. - The certificate must be signed by a trusted CA (or by an intermediate which in turn was trusted, and so on recursively). I think I hit the big ticket items, there might be some others.

tialaramex 5y ago

I don't think that's what your parent post meant, but, Chrome actually mechanically requires CT logging in order to trust a site, the expect-CT header doesn't come into it. Safari has the same policy, and Mozilla intends to some day do likewise in Firefox but the politics of the exact rules are tricky for reasons we could get into if somebody cares. When your Chrome connects to a TLS server, the server has to provide a certificate, and Chrome examines that certificate before any HTTP traffic happens (and thus before you could send an HTTP header like Expect-CT anywhere) unless you've got Group Policy or similar rules saying otherwise: - The certificate must have proof it was logged in the form of SCTs. For most sites the SCTs are baked into the certificate when they got it, they're all that incomprehensible gibberish near the end of your certificate if you've read it. - The certificate must have been issued relatively recently (825 days or less previously) and it must expire within 825 days of issuance or if it was issued since some time in 2020 when Apple's policy change happened, 398 days. - The certificate says it is for TLS Servers (in most cases certificates say they're also for TLS Clients, and sometimes other things too, but Chrome checks it says specifically TLS Servers here) - The certificate has a Subject Alternative Name matching the DNS name of the server, or, if the URL we're resolving is for a numeric IP address, a SAN matches that IP Address. SANs are typed, and are not free human text, so a DNS SAN and an IP address SAN are distinguishable even if 10.20.30.40 was a valid DNS name, which it is not. Old-fashioned "Common" names are disregarded. - The certificate must be signed by a trusted CA (or by an intermediate which in turn was trusted, and so on recursively). I think I hit the big ticket items, there might be some others.