mirror of
https://github.com/klzgrad/naiveproxy.git
synced 2024-12-01 01:36:09 +03:00
204 lines
10 KiB
Markdown
204 lines
10 KiB
Markdown
# Certificate Transparency
|
|
|
|
## Overview
|
|
|
|
[Certificate Transparency](http://www.certificate-transparency.org/) (CT) is a
|
|
protocol designed to fix several structural flaws in the SSL/TLS certificate
|
|
ecosystem. Described by [RFC 6962](https://tools.ietf.org/html/rfc6962) and
|
|
the ongoing work in [RFC 6962-bis](https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/),
|
|
it provides a means of providing a public, append-only data structure that
|
|
can log certificates issued by [certificate authorities](https://en.wikipedia.org/wiki/Certificate_authority) (CAs).
|
|
By logging these certificates, it becomes possible for site operators to
|
|
detect when a certificate may have been issued for their domain without their
|
|
approval, and allows browsers and the wider ecosystem to verify that CAs are
|
|
following their expected and disclosed practices.
|
|
|
|
## Certificate Transparency Basics
|
|
|
|
Broadly speaking, the goal of supporting Certificate Transparency is to ensure
|
|
that certificates an application trusts will be publicly disclosed in a way
|
|
sufficient for site operators and application developers to ensure that
|
|
nothing is wrong.
|
|
|
|
At the most basic level, it's possible to simply introduce Certificate
|
|
Transparency logs as trusted third parties, much like CAs are trusted third
|
|
parties. If the logs are operated by CAs, this may not be much of a security
|
|
improvement, but if the logs are operated by non-CA entities, this might serve
|
|
as a sufficient counter-balance to the risks.
|
|
|
|
However, with more work, it's possible to minimize the trust afforded to
|
|
Certificate Transparency logs, and to automatically and cryptographically
|
|
verify they're complying with their stated policies. This can provide even
|
|
greater assurance to application developers, site operators, and their users,
|
|
that the security expected from certificates is actually being provided.
|
|
|
|
For a more thorough threat analysis, see
|
|
https://datatracker.ietf.org/doc/draft-ietf-trans-threat-analysis/ that
|
|
discusses the different risks in Certificate Transparency, and how the
|
|
protocol addresses them.
|
|
|
|
## Certificate Transparency in `//net`
|
|
|
|
A goal of `//net` is to try to ensure that code is 'safe by default' when
|
|
used. As part of serving that goal, in order to make a TLS or QUIC connection
|
|
using code in `//net`, it's necessary for the `//net` embedder to make
|
|
a decision about Certificate Transparency, much like it is necessary to
|
|
provide a [`CertVerifier`](/net/cert/cert_verifier.h) that describes how to
|
|
verify the server's certificate.
|
|
|
|
Because this is necessary to make a TLS or QUIC connection, this requirement
|
|
surfaces upwards through each layer in the stack - applying to things like
|
|
[`HttpNetworkSession`](/net/http/http_network_session.h) and upwards to
|
|
[`URLRequestContext`](/net/url_request/url_request_context.h).
|
|
|
|
This requirement is expressed by requiring two separate, but related, objects
|
|
to be supplied: [`CTVerifier`](/net/cert/ct_verifier.h) and
|
|
[`CTPolicyEnforcer`](/net/cert/ct_policy_enforcer.h), which together can be used
|
|
to express an application's policies with respect to Certificate Transparency.
|
|
|
|
As part of the goal of ensuring 'safe by default', `//net` also has various
|
|
policies related to certificates issued by particular CAs whose past actions
|
|
have created unnecessary security risk for TLS connections, and as a
|
|
consequence, are required to have their certificates disclosed using
|
|
Certificate Transparency in order to ensure that the security provided by
|
|
these CAs matches the level of security and assurance that other CAs provide.
|
|
These policies are implemented in
|
|
[`TransportSecurityState`](/net/http/transport_security_state.cc), via the
|
|
`ShouldRequireCT` method.
|
|
|
|
### CTVerifier
|
|
|
|
`CTVerifier` is the core interface for parsing and validating the structures
|
|
defined in RFC6962 (or future versions), and for providing basic information
|
|
about the [`SignedCertificateTimestamps`](https://tools.ietf.org/html/rfc6962#section-3.2)
|
|
present within the connection.
|
|
|
|
### CTPolicyEnforcer
|
|
|
|
`CTPolicyEnforcer` is the core class for expressing an application's policies
|
|
around how it expects Certificate Transparency to be used by the certificates
|
|
it trusts and the CAs that issue these certificates.
|
|
|
|
`CTPolicyEnforcer` currently expresses two policies:
|
|
* How to treat [Extended Validation](https://cabforum.org/extended-validation-2/)
|
|
certificates (those for which a [`CertVerifier`](/net/cert/cert_verifier.h)
|
|
returned `CERT_STATUS_IS_EV`).
|
|
* How to treat all certificates, regardless of EV status.
|
|
|
|
### TransportSecurityState
|
|
|
|
The `TransportSecurityState::ShouldRequireCT` method implements the core logic
|
|
for determining whether or not a connection attempt should be rejected if it
|
|
does not comply with an application's Certificate Transparency policy.
|
|
|
|
The implementation in `//net` provides a default implementation that tries to
|
|
ensure maximum security, by failing connections that do not abide by an
|
|
application's Certificate Transparency policy and are from CAs known to have
|
|
security issues in the past.
|
|
|
|
Embedders can customize or override this by providing a
|
|
`TransportSecurityState::RequireCTDelegate` implementation, which allows
|
|
applications to inspect the connection information and determine whether
|
|
Certificate Transparency should be required, should not be required, or
|
|
whether the default logic in `//net` should be used.
|
|
|
|
## Certificate Transparency in Chromium
|
|
|
|
As part of the open-source implementation of Chrome, the policies related to
|
|
how Chromium code treats Certificate Transparency are documented at
|
|
https://www.chromium.org/Home/chromium-security/certificate-transparency . This
|
|
page includes the policies for how Chromium determines an acceptable set of
|
|
Certificate Transparency logs and what Certificate Transparency-related
|
|
information is expected to accompany certificates, both for EV and non-EV.
|
|
|
|
The implementation of these policies lives within [`//net/cert`](/net/cert), and
|
|
includes:
|
|
* [`ct_known_logs.h`](/net/cert/ct_known_logs.h): The set of Certificate
|
|
Transparency logs known and qualified according to Chromium's
|
|
[Certificate Transparency Log Policy](https://www.chromium.org/Home/chromium-security/certificate-transparency/log-policy).
|
|
* [`multi_log_ct_verifier.h`](/net/cert/multi_log_ct_verifier.h): Capable of
|
|
parsing `SignedCertificateTimestamps` from a variety of logs and
|
|
validating their signatures, using the keys and information provided by
|
|
`ct_known_logs.h`.
|
|
* [`ct_policy_enforcer.h`](/net/cert/ct_policy_enforcer.h): A base class that
|
|
implements the Certificate Transparency in Chrome Policy, for both EV and
|
|
non-EV certificates.
|
|
|
|
## Certificate Transparency for `//net` Consumers
|
|
|
|
This section is intended for code that is open-sourced as part of the
|
|
Chromium projects, intended to be included within Google Chrome, and which
|
|
uses the `//net` APIs for purposes other than loading and rendering web
|
|
content. Particularly, consumers of `//net` APIs that are communicating with
|
|
a limited or defined set of endpoints and which don't use certificates issued
|
|
by CAs. This may also include testing tools and utilities, as these are not
|
|
generally shipped to users as part of Chrome.
|
|
|
|
Not every TLS connection may need the security assurances that
|
|
Certificate Transparency aims to provide. For example, some consumers of
|
|
`//net` APIs in Chromium use mutual authentication with self-signed
|
|
certificates and which are authenticated out-of-band. For these connections,
|
|
Certificate Transparency is not relevant, and it's not necessary to parse
|
|
or enforce Certificate Transparency related information.
|
|
|
|
For these cases, the approach is:
|
|
* [`do_nothing_ct_verifier.h`](/net/cert/do_nothing_ct_verifier.h): A no-op
|
|
CTVerifier that does not parse or verify Certificate Transparency-related
|
|
information.
|
|
* A derived `CTPolicyEnforcer` implementation that indicates all
|
|
certificates comply with its policies.
|
|
|
|
**TODO(rsleevi):** Provide a `DoNothingCTPolicyEnforcer`
|
|
|
|
As documented in these classes, care should be taken before using these, as
|
|
they provide much weaker security guarantees. In general, emailing
|
|
[net-dev@chromium.org](mailto:net-dev@chromium.org) or discussing it during a
|
|
security review is the right answer, and documenting at the instantiation
|
|
points why it is safe and acceptable to use these classes.
|
|
|
|
## Certificate Transparency for `//net` Embedders
|
|
|
|
This section is intended for code that is used in other open-source Chromium
|
|
based projects, but are not included in Google Chrome or related. This
|
|
includes projects based on `//net`, such as
|
|
[`//components/cronet`](/components/cronet) or other
|
|
[`//content`](/content) embedders.
|
|
|
|
For projects and third party products that embed `//net`, the policies
|
|
that are included as part of the open-source repository may not be
|
|
appropriate. This is because the implementations may rely implicitly
|
|
or explicitly on several key guarantees that come from Google-branded
|
|
distributions and products, and may not be appropriate for other cases.
|
|
|
|
These key expectations are:
|
|
* A release cycle aligned with Chrome releases; that is, every six weeks,
|
|
and on the same versions as Chrome releases.
|
|
* Widespread support for automatic updates.
|
|
* That [`base::GetBuildTime()`](/base/build_time.h) will reflect, to
|
|
some degree, when the tree was branched and/or released, and will not
|
|
be re-generated on recompilation. That is, this implies is_official_build
|
|
for binaries released to end-users, but is not enforced in code so that
|
|
developers can accurately test release behavior.
|
|
* Support for dynamic [`base::FieldTrial`](/base/metrics/field_trial.h)
|
|
configurations.
|
|
|
|
For projects that don't support automatic updates, or which measure 'stable'
|
|
on the order of months to years, or which don't have tools suitable to
|
|
respond to changes in the Certificate Authority and Certificate Transparency
|
|
ecosystem, it may not be appropriate to enable Certificate Transparency
|
|
support yet.
|
|
|
|
These issues are not unique or particular to Certificate Transparency - in
|
|
many ways, they're similar to issues already faced with determining which
|
|
CAs are trusted and how to successfully validate a TLS server's certificate.
|
|
However, as the Certificate Transparency ecosystem is still growing, it may be
|
|
suitable to disable support until some of the solutions to these challenges
|
|
stablize.
|
|
|
|
To opt-out of enforcing Certificate Transparency, using the `DoNothing`
|
|
variants discussed above provides a suitable implementation that will opt to
|
|
'fail open' instead. This may provide less security, but provides greater
|
|
stability, and minimizes the risk that these `//net` embedding clients
|
|
might cause to the Certificate Transparency ecosystem or receive from enabling
|
|
Certificate Transparency.
|