Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925
edits
Security/Features/CA pinning functionality: Difference between revisions
Jump to navigation
Jump to search
Security/Features/CA pinning functionality (view source)
Revision as of 15:06, 17 February 2012
, 17 February 2012no edit summary
No edit summary |
No edit summary |
||
| Line 8: | Line 8: | ||
|Feature security lead=Curtis Koenig | |Feature security lead=Curtis Koenig | ||
|Feature privacy lead=Sid Stamm | |Feature privacy lead=Sid Stamm | ||
|Feature additional members=Gervase Markham | |||
}} | }} | ||
{{FeaturePageBody | {{FeaturePageBody | ||
|Feature overview= | |Feature overview=Now they can require HTTPS connections (via HSTS), sites may want to also restrict the CAs who can issue certificates for their domain to a small number (> 1) that they trust. This can be accomplished via providing a list of certificate fingerprints, at least one of which must be present in any chain considered valid for the domain. This is rather like what Chrome has done [http://www.imperialviolet.org/2011/05/04/pinning.html] except we would not be managing a static list of anchors. | ||
|Feature users and use cases=CA | |Feature users and use cases=CA Foo is compromised and grants a certificate for example.com to an attacker. The owners of example.com have their site pinned to certificates from CAs Bar and Baz, so when the attacker attempts to use the certificate from CA Foo, he fails to satisfy the pinning requirement. Any users presented with his certificate will not have access to the fraudulent connection (hard fail). | ||
|Feature dependencies=HSTS. | |||
|Feature requirements=See https://tools.ietf.org/html/draft-evans-palmer-hsts-pinning | |Feature requirements=See https://tools.ietf.org/html/draft-evans-palmer-hsts-pinning | ||
Google has had CA pinning for a while; we should talk to them about their experience and any risks/problems with current proposals. | Google has had CA pinning for a while; we should talk to them about their experience and any risks/problems with current proposals. (We need to separate issues with having a hard-coded list, which we aren't planning to do, from issues with the idea of pinning itself.) | ||
|Feature non-goals=* | |Feature non-goals=* Replacing the existing x.509 PKI infrastructure. (This is a refinement.) | ||
* Enabling pinning without also requiring HTTPS (see section 6.5 of spec) | |||
|Feature functional spec=See https://tools.ietf.org/html/draft-evans-palmer-hsts-pinning-00 . | |||
As the draft suggests (but does not require) in 6.1, we should require 2 or more pins, 1 of which is not used in the currently-served chain. This reduces the ability of people to shoot themselves in the foot and will preserve the good reputation of the technology. | |||
We should also consider _requiring_ a breakv code, and talk to the authors about making that a spec requirement. | |||
|Feature ux design=The draft recommends that users have ways of querying which domains are pinned. We need to consider whether we think this is necessary and, if so, how to do it. (Perhaps integrated with the history view?) | |||
If site access is denied, we will need a screen explaining why. (There will be no override, as per spec.) | |||
We should already have mechanisms for clearing stored HSTS information when the user clears their history; pin information should go with it. | |||
}} | }} | ||
{{FeatureInfo | {{FeatureInfo | ||