I am trying to understand RFC 6797.
In today’s Chrome browser the page with pseudo URL “chrome://net-internals/#hsts” begins:
I am already at a loss.
Why cannot the server merely refuse to provide http?
Why do we need an RFC for that?
Further quote:
Jackson and Barth proposed an approach, in [ForceHTTPS], to enable web resources to declare that any interactions by UAs with the web resource must be conducted securely and that any issues with establishing a secure transport session are to be treated as fatal and without direct user recourse.
The aim is to prevent click-through insecurity and address other potential threats.
It seems to me that the simpler solution is for the UA to negotiate a secure session despite lack of proper authentication.
I.E. for the UA to pretend that the certs had been seen as valid but only with the user’s explicit permission.
On page 4 of RFC:
UAs typically announce to their users any issues with secure connection establishment, such as being unable to validate a TLS server certificate trust chain, or if a TLS server certificate is expired, or if a TLS host's domain name appears incorrectly in the TLS server certificate (see Section 3.1 of [RFC2818]).
Often, UAs enable users to elect to continue to interact with a web resource's host in the face of such issues. This behavior is sometimes referred to as "click(ing) through" security [GoodDhamijaEtAl05] [SunshineEgelmanEtAl09]; thus, it can be described as "click-through insecurity".
My browsers increasingly announce such troubles to me because I have chosen not to trust certificate authorities that I have no reason to trust.
While I could temporarily mark the CA chosen by the site as trusted, but that is costly and error prone and likely to leave me vulnerable to that CA when I do my banking.
I had presumed that “clicking thru” gave me an encrypted session despite the certificate problem.
In such cases the browser speaks of “my expectations of an authentic site”.
I have no such expectations; I don’t know what “authentic” means when I have never heard of the site.
That they have convinced some CA to issue them a cert is no reason for trust.
Here is the use case I had hoped to support with this feature.
When I go to my bank’s site, I know my bank and my bank knows me.
Before I enter my password I want to know that it will be received only by my bank and not some site that has both:
- Interfered somehow with packet routing.
- Acquired a certificate issued by some suborned or subverted certificate authority that allows the site to masquerade as my bank.
I had hoped that it was possible to make an entry using the #hsts page of my bank’s root domain name and the fingerprint of the public key of the CA selected
by my bank.
I had hoped that that entry would cause my browser to block any TLS authentication of any subdomain of the bank except as authorized by that particular public key.
I would thus become invulnerable to other CA's that I have had to trust for practical reasons.
Quote from Adam Langley:We are not aware of any other root stores that include the India CCA certificates, thus Chrome on other operating systems, Chrome OS, Android, iOS and OS X are not affected. Additionally, Chrome on Windows would not have accepted the certificates for Google sites because of public-key pinning, although misissued certificates for other sites may exist.
Perhaps Langley shares my misunderstanding.
It is notes like these that led me to think that an entry such as created on the #hsts page, would block building TLS sessions to specified domains, except via the indicated public key.
What I Want
Let me be as clear as I can about how I thought that the feature controlled by the #hsts page worked.
That page allows the user of the browser to maintain a set of ordered pairs, {(root domain name, list of public key fingerprints)}.
Any time an URL is used to access a web page (perhaps any establishment of a TLS session) this set is searched to see if the domain name is a sub-name of any of the domain roots in the list.
If there is such a member then the list of fingerprints entirely supplants the normal list of “trusted certificate authorities” otherwise consulted while considering the certificate chain presented by the host.
This allows me to make certain critical web sites, with which I do have critical secrets to keep, such as bank passwords, safe from compromised CAs that I have never heard of.
Perhaps this breaks the intent that caused the creation of the set controlled by page #hsts; I don’t understand that intent.