IETF community members, has announced technical specifications for
a new cryptographic protocol called “Delegated Credentials for
TLS.”
Delegated Credentials for TLS is a new simplified way to
implement “short-lived” certificates without sacrificing the
reliability of secure connections.
In short, the new TLS protocol extension aims to effectively
prevent the misuse of stolen certificates by reducing their maximum
validity period to a very short span of time, such as a few days or
even hours.
Before jumping into how Delegated Credentials for TLS works, you
need to understand the current TLS infrastructure, and of course,
about the core problem in it because of which we need Delegated
Credentials for TLS.
The Current TLS Infrastructure
More than 70% of all websites on the Internet today use TLS
certificates to establish a secure line of HTTPS communication
between their servers and visitors, ensuring the confidentiality
and integrity of every bit and byte of data being exchanged.
Websites obtain a TLS certificate from a Certificate Authority
(CA) that must be trusted by all major web browsers. CA
organization digitally signs a certificate that remains only valid
for a specific period, typically for a year or two.
When you connect to an HTTPS-protected website, the server provides
its TLS certificate to your web browser for confirming its identity
before exchanging any information that could include your passwords
and other sensitive data.
Ideally, certificates are expected to be used for their entire
validity period, but unfortunately, a certificate can go bad before
its expiration date for many reasons.
For example, the secret private key corresponding to a certificate can be
stolen[1], or the certificate can
be issued
fraudulently[2], allowing an attacker to
impersonate a targeted server or spy on encrypted connections
through a man-in-the-middle attack.
Moreover, big tech companies like Facebook, Google, and
Cloudflare offer their services from thousands of servers
implemented worldwide. They distribute private certificate keys to
each one of them, a process where the risk of compromise is higher
than usual.
Problem: Why We Need Delegated Credentials For TLS?
If a certificate gets compromised before its expiration date, the
only option a website operator currently has is to request the
certificate authority to revoke the stolen certificate and reissue
a new one with a different private key.
However, unfortunately, the current revocation mechanisms are
also broken in practice.
Ideally, browsers should be able to promptly detect
no-longer-trusted certificates to proactively prevent their users
from further connecting to a compromised server until it gets back
online with a new valid certificate.
But since frequently querying a CA server imposes a massive
performance penalty on the web traffic, modern browsers either use
cached validation status of a certificate for some time or assume
that it is still valid in case the browser doesn’t receive a
response from the CA on time or encounter any connection error.
That means that an attacker can launch cyberattacks against a
targeted website only in the time frame between the revocation of
its stolen certificate and when the browsers learn about it and
block it.
In an attempt to further reduce this sensitive time frame, some
companies have started experimenting with certificates with a
shorter validation period, after which browsers itself reject them
instead of waiting for the revocation signal.
Facebook is also among those companies that use this approach,
as the company explains[3]:
“The shorter the certificate lifetime, the less likely a
certificate will need to be revoked before it expires. We have
shortened the validity lifetime of our certificates from the
current industry standard of one year to just a few months.”
“This boosts our security by reducing the period during which a
potential attacker could use a compromised certificate.”
would need to fetch new certificates from them much more
frequently, there is no reliable way available for the companies to
continuously rotate certificates after every few hours or days.
“However, constant communication with an external CA to obtain
short-lived certificates could result in poor performance or even
worse, lack of access to a service entirely,” Firefox
warned[4].
“To mitigate this risk, services like ours [Facebook] generally opt
for longer expiration time, so there is time to recover from any
failures,” Facebook said.
Solution: How Does ‘Delegated Credentials for TLS’ Work?
Finally, let’s talk about the solution.
To solve the issues mentioned above, IETF community members have
now proposed Delegated Credentials for TLS, a new cryptographic
protocol that balances the trade-off between lifetime and
reliability.
control over the process of signing new certificates for
themselves—with a validity period of no longer than 7 days and
without entirely relying on the certificate authority.
“Delegated Credentials permit holders of specially-enrolled
certificates to use those certs as a kind of sub-sub-CA to
construct sub-certificates whose authority is delegated by the
actual end-entity cert,” said J.C. Jones[5], cryptography
engineering lead at Mozilla.
“These delegated certificates are particularly useful when needing
to act on behalf of the end-entity in lower-trust environments,
like those sometimes found in CDN edge networks.”
from its certificate authority, using which it can then generate
and sign a delegated credential with an expiration time as little
as a few hours.
On the client-side, browsers and software supporting the new
protocol would use the public key of the short-lived delegated
credential of a website to establish a secure TLS connection with
its server.
So instead of deploying the actual private key associated with the
certificate to all servers, companies can now internally create,
deploy, and issue delegated credentials.
“It is much easier for a service to create delegated credential
than a certificate signed by a CA,” IETF draft[6] says.
“Operators can issue each of their servers a separate delegated
credential with a short validity time, instead of the real
certificate private key, to add defense-in-depth,” Facebook said.
When you connect to a website with a browser that supports
delegated credentials, then instead of using the regular TLS
certificate, the server provides a short-lived token to your
browser for authentication, which satisfies the chain of trust
because delegated credentials are still signed by the certificate
obtained from the CA.
“Since the delegated credential has its own public key, a server
can also experiment with new public key algorithms for TLS
(including Ed25519 public keys) even before CAs support it,”
Facebook said.
“A fresh delegated credential can be created and pushed out to TLS
servers long before the previous credential expires. Momentary
blips in availability will not lead to broken handshakes for
clients that support delegated credentials,” Cloudflare[7] said.
Support for Delegated Credentials
Facebook has already added support for Delegated Credentials in
Fizz
library[8], its open source
implementation of TLS 1.3 designed for performance and security.
Google’s open source fork of OpenSSL, BoringSSL[9], also supports Delegated
Credentials for TLS protocol.
As one of the partners in standardizing the protocol, the
Mozilla web browser now supports Delegated Credentials in the
latest version of Firefox.
can turn it on by navigating to about:config → search for the
“security.tls.enable_delegated_credentials” preference →
double click on it to set its value to true.
To test if your browser supports Delegated Credentials for TLS,
you can visit the following sites:
References
- ^
certificate can be stolen
(thehackernews.com) - ^
issued fraudulently
(thehackernews.com) - ^
explains
(engineering.fb.com) - ^
Firefox warned
(blog.mozilla.org) - ^
J.C. Jones
(bugzilla.mozilla.org) - ^
IETF draft
(tools.ietf.org) - ^
Cloudflare
(blog.cloudflare.com) - ^
Fizz library
(thehackernews.com) - ^
BoringSSL
(boringssl.googlesource.com)
Read more http://feedproxy.google.com/~r/TheHackersNews/~3/6qT_m1ePtxc/delegated-credentials-for-tls.html