Implications of ROBOT TLS vulnerability
Late in 2017, a group of researchers identified a TLS implementation
vulnerability they termed "ROBOT" . It involves flaws in the
implementation of TLS cipher suites that rely on RSA for encryption.
Most modern TLS deployments encourage and sometimes require the use
of newer cipher suites that utilize more modern encryption algorithms
even when an RSA public/private key pair is used. The researchers found
that many implementations supporting the older ciphers contained bugs that
can undermine the confidentiality of the channel.
While this obviously has the potential to impact any secure web
site, a more subtle consequence of this flaw is that it can sometimes
allow for a signature over arbitrary data to be forged under the web
server's private key.
In the context of SAML and Shibboleth, this becomes a much more
significant concern because of the conflation in the metadata between
"signing" and TLS. There are various equivalencies drawn such that
an IdP that supports both the HTTP-POST and HTTP-Artifact bindings
(with either SAML 1 or SAML 2) will generally be advertising the
TLS key it uses to host its ArtifactResolutionService endpoint
as equivalent to the key it uses to sign its POST-carried responses
In such a case, the TLS key affected by this vulnerability could
potentially be used as the basis for an attack that could result in
the forgery of SAML responses that could impersonate users from that
Identity Provider to virtually any service.
It was particularly common with older deployments to find the same
key used for both purposes, with the signing key used as a TLS key
on a dedicated virtual host or back-channel port such as 8443. This
has long been recognized as a bad idea (think Heartbleed, and other TLS
vulnerabilities that actually led to key exposure), so much so that
Shibboleth IdP V3 began to explicitly default to generating a dedicated
"back channel" key during installation.
However, sharing the key is not a precondition for this attack because
any key in the metadata role used for Browser SSO when Artifacts are
used can be transparently misused as a signing key with metadata-
compliant software, Shibboleth included.
The other common use case for the back-channel with older Shibboleth
deployments was to support SAML Attribute Queries. Because queries
involve a separate metadata role from SSO, one would have to reuse the
key in that case to be subject to the same degree of risk.
There are lower-probability attacks possible if a vulnerable key
is present solely in other role elements, such as an
<AttributeAuthorityDescriptor>, or in an SP's metadata. These attacks
would typically require a more active attacker along a network path
between IdP and SP, and a more limited timing window.
Attacks involving an SP's key are inherently more limited in scope
(since they tend to involve just one service) and would tend to be of
the information disclosure variety more traditionally associated with
the ROBOT vulnerability. As an example, forging queries or artifact
resolution requests under an SP's key could in theory result in
disclosure of user data by an IdP under the misapprehension that it
was responding to a legitimate request from that SP.
This issue is orthogonal to the IdP and SP software and depends on the
software used to host the IdP or SP. The ROBOT site has some tools
available that can assess the status of a system.
While many of the common TLS assessment sites have been updated to
account for the issue, it is not uncommon for them to be limited to
scanning port 443, which may impact the ability to effectively assess
a back channel port. If the same software/configuration is used on port
443, that may be sufficient to assess a system's posture.
To be most seriously impacted, an IdP key within the <IDPSSODescriptor>
metadata role element that is marked with use="signing" or no use
attribute must be used as a TLS private key on a ROBOT-vulnerable
Other attacks are possible if a key on a ROBOT-vulnerable endpoint is
present in metadata in any form, but the forging of authentication
responses is the most serious threat.
Note that one must also take into consideration any sharing of an
at-risk key through means other than SAML metadata, such as by manually
configuring it with relying party systems.
1. Be aware of which keys you include in the metadata you advertise
and whether they are used for TLS, and remove any unnecessary keys
2. Ensure any unused/unsupported SAML features (e.g. Artifact support)
are omitted from the metadata you advertise.
3. Ensure that your TLS software is patched, well-maintained, and
carefully configured in accordance with modern best practice (which
is itself a moving target needing periodic review).
-----END PGP SIGNATURE-----
To unsubscribe from this list send an email to [hidden email]