Certificates for signed exchanges should be allowed also for TLS connections. #420
Comments
|
Would it be possible to explain why it is desirable?
Cross-protocol attacks have caused a number of severe security issues - as
demonstrated by things as “simple” as between QUIC and TLS or TLS1.3 vs
TLS1.2. Just as these protocols admonish users to make use of separate keys
and identities, it seems there is no significant benefit, compared to the
significant risk it introduces to users.
Furthermore, ensuring key separation helps encourage better key hygiene for
the purposes being used. This is similar to the discussion of TLS Delegated
Credentials, in that separating online and offline key pairs, via distinct
technical capability, is highly desirable.
Finally, given that SXGs, as a general technology, come with new trade offs
and risks with respect to impersonation (if the key is compromised), the
explicit extension also serves to ensure direct and affirmative consent by
the site to use SXGs (e.g. via the CAA check)
As such, the use of the extension plays a critical and essential, perhaps
irreplaceable, role in the overall security of SXG. It would have to be
demonstrated a significant and serious benefit to consider removing, and
necessary to introduce comparable security measures. Perhaps the spec can
make it clearer why this is such an essential property, so that proposals
to remove it can be accompanied with the same thorough and thoughtful
security mitigations.
|
|
1: My stance on it, is that its up to the server administrator if they want to share keys should be able to do that. 2: I didn't say that the extension should be removed. What I said, is that the limitation where a certificate with said extension cannot be used as a TLS server certificate, should be removed. However, another solution is to extend the extension with the BOTH/NULL alternatives, so the ability of the certificate can be gated into "Only TLS", "BOTH" and "Only SGX", with accompanying CAA checks, so the server administrator can choose exactly how he wants to do it. |
|
On Tue, Apr 9, 2019 at 7:59 AM Sebastian Nielsen ***@***.***> wrote:
1: My stance on it, is that its up to the server administrator if they
want to share keys should be able to do that.
It’s unclear. Are you disagreeing that there are fundamental cryptographic
cross-protocol risks introduced by the reuse of keys in unrelated
protocols? It is basic cryptographic practice to ensure that unrelated
protocols should use unrelated keys. While significant effort has been made
to reduce the cross-protocol confusion, the prohibition serves as a
critical and essential safety margin.
Could you help explain the concern/motivation more? It’s unclear whether
this is motivated by a concern of simply obtaining an additional
certificate, or whether there is some other consideration at play.
|
|
No im not disagreeing with it. Yes I do understand there need to exist a safety margin, but the final authority of a domain, should be able to decide if that safety margin should be in effect or not. The advantage of being able to use the same certificate for more tasks, is multi-fold. |
|
On Tue, Apr 9, 2019 at 8:31 AM Sebastian Nielsen ***@***.***> wrote:
No im not disagreeing with it.
Yes I do understand there need to exist a safety margin, but the final
authority of a domain, should be able to decide if that safety margin
should be in effect or not.
Ultimately, the User Agent is responsible for ensuring the user’s security
needs are met, above and beyond what domain holders may wish.
This is why User Agents disable SHA-1 or 1024-but RSA keys, or denote
certain powerful features to HTTPS. Yes, a domain operator may be
interested in setting their security policies lower, but such desire is
counter to the security of users needs.
The advantage of being able to use the same certificate for more tasks, is
multi-fold.
First, by having lesser amount of keys and certificates in system, the
certificates and keys can be secured more, and lesser management overhead.
This does not seem to logically follow. Given that TLS keys are online,
while SXG keys are inherently offline, coupling these two functionally
reduces the security of the system and users. Every operation involving
such shared keys needs to fully consider both protocols, causing more
management overhead.
1: If its the same server serving both normal TLS content and SGX content,
theres no security gain in having 2 certificates and 2 keys on the same
machine.
This does not logically follow. With SXG, there is no technical need to
install keys on the server. Such a thing would seem counter to best
practice.
2: If you use a HSM or crypto accelerator that only supports one key and/or
chain, it would be preferable to be able to use that.
Are you aware of any such products? I have yet to encounter one in my
career. In general, HSMs are unable to be deployed for TLS at scale, as
modern HSMs and “accelerators” (more of a 90s concept) are unable to
perform signatures at the pace of modern large scale deployments. On the
other hand, SXGs, and their infrequent signatures, absolutely make these
technologies viable again for key protection.
3: If the CA charges for certificates, having 2 certificates would of
course incur additional costs than 1 certificate.
I agree that this is a possibility, but it’s not a technological concern.
You can choose CAs, for example, that do not charge for certificates at
all, or which charge for validations (which both types of certificates can
be issued from a single validation). I totally understand and appreciate
the concern here - it’s one introduced whenever anything involving
certificates is used - but it does not seem necessary to weaken the
cryptographic security in order to address. As demonstrated by current and
past CA practices, it also seems to be a practice going out of vogue and
more hypothetical?
… |
|
1: I agree about the user agent responsible for end user security, and of course it should restrict certain sensitive features to HTTPS. But in my opinion, the user agent should not put any restrictions on how the server operator may manage their keys and certificates. |
|
Do we agree that User Agents already place restrictions on how servers
manage their keys (e.g. no 1024-bit) and certificates (e.g. expiration
policies, weak signatures)? This does not seem to be a change from the
status quo.
We seem to be in agreement that an SXG key is more valuable than a TLS key,
due to the ability to mount off-path attacks, so it seems there’s clear
justification for putting stronger protection requirements on the SXG key.
Those requirements are incompatible with TLS, due to TLS requiring online
signing.
Assuming we had a technology which allowed a TLS key to be protected to
that same level, such as TLS Delegated Credentials proposes (moving the TLS
key offline, in favor of ephemeral assertions), then we also seem to be in
agreement that there are still fundamental cryptographic reasons to keep
key material separate, to defend against cross-protocol attacks.
I don’t mean to dismiss the feedback, but to walk through how the
conclusion was reached - which is that it is essential to the security of
end users to ensure a TLS server does not reuse an SXG key. While of course
such thing is possible by virtue of a CA issuing two certificates for the
same key - such a thing should be seen as a security vulnerability, rather
than an expected or accepted practice.
|
|
I don't agree with the assertion that SXG key is strictly more valuable than a TLS key. An attacker that has possession of a TLS key can perform a MITM attack that steals authentication credentials such as cookies, while an attacker in possession of an SXG certificate can only display arbitrary content as the site owner. In some respects, being able to MITM TLS is a more powerful attack. With that said, not all clients will implement the MUST NOT. This means that there will be a risk that a compromised SXG certificate can be used to MiTM a TLS connection, just not with Chrome. This puts all users of non-conforming browsers at risk. What is the point of adding this restriction to not allow TLS with the certificate if the extension is not marked critical? It seems to only protect users of conforming browsers while exposing other users to risk. I understand this has been discussed before (#238) but it's not clear the conclusions still hold given that a large percentage of user agents that will not be updated to respect this MUST NOT. In my opinion, this spec should be non-discriminatory and pick a side. Either SXG certificates should be permitted for use in TLS (maintaining the legacy browser behavior), or certificates should be forbidden to be used for TLS and the extension made critical (to protect the users of legacy browsers). I'm not swayed by the argument that just because some TLS clients use system PKI validators, that this extension should not be made critical. This is a big change to how the PKI is used and clients who want to support it should make correct validation of the certificate a requirement on platforms they run on. Fudging this with a MUST NOT that will only be used for a subset of clients does not improve the situation. |
In a web context, an attacker that can display arbitrary content as the site owner can, in turn, run arbitrary JS as the site owner. That allows them to read credentials for that origin, make credentialed requests as that origin, etc. |
|
I've been convinced that neither SXG keys nor TLS keys are strictly more powerful than the other, especially since we're talking in #376 and elsewhere of checking SXG contents against a live TLS connection. The difference in power is complicated and probably not too helpful in deciding this particular issue. I think @sebastiannielsen is right that many servers will put their SXG key on the same internet-facing server as their TLS key, unless we require it to be on a secure element, which I suspect will limit adoption too much. However, I'm also sympathetic to @sleevi's point that we want a buffer around the possibility of cross-protocol attacks. Especially since the SXG signed-message format is still evolving, I don't want to accidentally enable cross-protocol attacks in a future update, after we've allowed the keys to be used for TLS servers. On the other hand, it seems like it'll be easy to enable TLS use later, using the mechanism @sebastiannielsen suggests, once the format has settled down. On the third hand, @grittygrease is right that not all clients will implement the MUST NOT, and so we have to be careful about cross-protocol attacks during the SXG evolution anyway, so maybe we should make that explicit by allowing use for TLS. |
|
@sleevi Also the reason to drop SHA-1 certificates, is not about key management or security of a single website. Its more about the security of ALL websites. So even if one single website would be allowed to use SHA-1 certificates, it would hurt the security of all websites. That doesn't stand for TLS/SGX certificates. Even if I would publish the private key for my certificate to my website, it wouldn't hurt the security for any other website than mine. Thus any cross-protocol attacks, if found, would only affect those websites that do use the same certificate for TLS and SGX. Thus I stand my position on that the website administrator should be in full control of if a certificate should be allowed for either TLS, SGX or both. If you had both certificates combined into one, you would only need to submit everything once - and only pay once. Some CA's might then charge extra for a combined cert because they know you save on not having to get 2 certificates, and there should be some mechanism preventing this, possible in baseline requirements. |
|
Let's avoid the question of how much CAs charge for certificates here. |
|
On Fri, May 3, 2019 at 1:38 AM Sebastian Nielsen ***@***.***> wrote:
@sleevi <https://github.com/sleevi> Also the reason to drop SHA-1
certificates, is not about key management or security of a single website.
Its more about the security of ALL websites.
Because, a malicious actor could, with a valid SHA-1 certificate, be able
to generate another such, with hash collision, to be valid to for example
github.com or google.com
1024-bit certificates, then.
<http://google.com>
Thus I stand my position on that the website administrator should be in
full control of if a certificate should be allowed for either TLS, SGX or
both.
User agents priorities dictate that the user comes first. Poor security
practices by a website jeopardize user security. This is similar to UAs
having policies about which ciphersuites in TLS they support, which CAs
they support, or even requiring TLS at all for certain features.
Arguments in favor of web developers need to consider risks to users, both
from that of a single site and from an ecosystem perspective if all sites
adopted that.
The key management issues highlight a significant change, just as the work
proposed for Secondary Certificates would significantly alter the TLS key
risks.
|
|
@sleevi I'm mostly convinced by @grittygrease's argument that since we don't want to make the extension critical (doing so would prevent Chrome from adopting), any protocol confusion attacks put the users of non-adopting browsers at risk, and so we should allow use of SXG certs for TLS in order to make sure we pay attention to preventing protocol confusion attacks. How are you feeling about that argument? |
|
I don’t find it a particularly compelling argument for removing any
protections. I also don’t deny the current design is significantly weaker
than desirable, from a security POV.
During the design, we discussed other ways we could mitigate the risk. The
current design was chosen to favor the ease of adoption for CAs, but since
it seems there’s concern that it may not be sufficient, we should revisit
those designs.
For example, we discussed previously the use of EKUs, much in the same way
Code signing and TLS certificates are distinguished. This requires CAs
perform new issuance ceremonies for intermediates, before they can issue
SXG certificates, but also allows for reliable and interoperable
enforcement between SXG supporting clients and those that don’t.
|
|
The decision here was not based solely on Chrome. This is an issue
virtually every implementation will face.
|
|
Once the underlying PKIX packages on the OS are updated, this should no
longer be an issue, right? Or are you indicating that there is a broader
pattern that makes extensions that introduce new security risks difficult
to make critical?
…On Wed, May 29, 2019 at 9:35 AM sleevi ***@***.***> wrote:
The decision here was not based solely on Chrome. This is an issue
virtually every implementation will face.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#420?email_source=notifications&email_token=ABHDHZ3LLZNNARYQYSKJUIDPX2WFVA5CNFSM4HEOU6G2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWP5FLQ#issuecomment-497013422>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABHDHZ25U3OO7EPVXJMARYTPX2WFVANCNFSM4HEOU6GQ>
.
|
|
A design which forces the extension critical forces an implementation decision for UAs to either:
I think the comment in #420 (comment) is making an implicit, but unsupported, assumption that an SXG certificate is at greater risk of compromise than a TLS certificate, and that therefore disadvantages legacy clients if that key is compromised because it can be used in MITM. It's unsupported, because SXG-supporting clients would be at just as much (if not greater) risk of malicious SXGs, and thus the assumption that SXG would encourage laxer key hygiene isn't actually explained. It also ignores the other benefits of having the explicit extension and signal, and doesn't explain or justify why using it in TLS is desirable or useful, other than it would avoid having to think about key protection - which is exactly what the extension is trying to force contemplation of (among other things). |
I read this in the specification:
"Clients MUST NOT accept certificates with this extension in TLS connections (Section 4.4.2.2 of [RFC8446])."
I don't see any specific reason for this. I would suggest removing this completely from specification, and allowing content to be signed with the same certificate as for TLS connections. (provided the certificate is allowed for signed exchanges)
Since a signed exchange have a very specific format, I don't see any risk with for example an site-wide XSS becoming a signing oracle for signing exchanges, unless the administrator explicitly configures the page/server in that way for some specific application. (for example a timestamping service allowing signing of arbitary data which is then time-stamped)
Another way to improve on this, is to have a special magic value for the extension, that will allow dual usage, so if the extension, instead of having the null value ( 05 00 ), have the exact octet-binary value "BOTH" ( 04 42 4f 54 48 ), it will allow dual usage of the certificate.
Thus specification could be instead:
"A conforming CA MUST NOT issue certificates with this extension unless, for each dNSName in the subjectAltName extension of the certificate to be issued:
An “issue” or “issuewild” CAA property ([RFC6844]) exists that authorizes the CA to issue the certificate; and
The “cansignhttpexchanges” parameter (Section 4.2.1) is present on the property and is equal to “yes” or "both".
A conforming CA MUST NOT issue certificates with this extension set to "BOTH", unless "cansignhttpexchanges" is equal to "both".
Clients MUST NOT accept certificates with this extension in TLS connections, unless the extension has the exact octet-binary value BOTH ( 04 42 4f 54 48 ) (Section 4.4.2.2 of [RFC8446])."
For this, the cansignhttpexchanges CAA value must also be extended with a "both" option to allow certificates to be issued with the BOTH extension value. (if "yes", it will only allow NULL, but if "both", it will alllow both NULL and BOTH values)
I also read this:
"TLS server certificates must be accessible from online servers, so they’re easier to steal or use as signing oracles than an offline key. An exchange’s signing key doesn’t need to be online."
and this:
"Using an exchange-signing key in a TLS (or other directly-internet-facing) server increases the risk that an attacker can steal the private key, which will allow them to mint packages (similar to Section 6.4) until their theft is discovered."
This is very untrue, as most content-signing servers will of course be directly internet-facing. A majority of server operators will just configure their servers to sign static content when requested, or possibly with a client whitelist (like cloudflares IPs) to prevent it from signing content for others.
Thus their CanSignHttpExchanges certificate will in most cases, reside side-with-side with their TLS certificate in the same folder on the same machine.
Only more sensitive and advanced companies will make content-signing servers airgapped.
The only way to enforce secure usage of such a certificate and make sure its "airgapped", is to require it to be loaded on a secure element with presence validation. This is a requirement imposed by most CA's for sub-CA certificates.
The only risk I see with completely dropping the restriction, is that a stolen content-signing certificate could be used to host a TLS server used for example phishing attacks and such.
Thats why it might be good to instead use the proposed NULL and BOTH values, so theres 3 types of certificates:
1: Certificates ONLY valid for TLS connections.
2: Certificates valid for BOTH.
3: Certificates ONLY valid for Signed-exchanges.
thus a server operator is able to choose the security level that fits them best.
The text was updated successfully, but these errors were encountered: