My Authors
Read all threads
[Thread] We discovered the Palo Alto SAML vulnerability (CVE-2020-2012). There's lots of confusion about the role of the 'Disable cert validation' check box in this issue. TLDR; Having this turned off is standard, expected, and not bad practice. Patch your PA, and leave this off.
To understand this properly, we need to understand how SAML works, specifically the 'POST binding' mechanism mostly commonly used in SAML setups today. There are two parties in a SAML trust, the identity provider (IDP) and the service provider (SP).
The IDP job is to auth the user on behalf of an SP. It will then send an XML 'assertion' to the SP when a user logs in. This assertion contains information about the authentication event, including the identity of the user, and possibly other attributes related to authorization.
These assertions are sent via an untrusted medium - the client's browser. The IDP and SP don't communicate directly. So there must be some way for the SP to know that the assertion actually came from the IDP and has not been modified in transit.
SAML Assertions are XML documents, so the XML digital signature protocol is used to achieve this. The SAML specification mandates that all assertions delivered via the POST binding must contain an XML signature. So how does the SP know that this signature came from the IDP?
When an SP chooses to delegate authentication to an IDP, an exchange of metadata is required. The IDP needs to know the URL of the application (so it can send the assertion back to the SP via the client browser), and the SP needs to know the URL of the IDP
(so it can send users there to be authenticated), AND it also needs a copy of the public key that will be used to sign the assertion. All this is mandatory and you cannot turn any of this off. It is core to the SAML protocol. If you don't do this, you are not SAML compliant.
This digital signature validation process is what the CVE is about. These signatures are not being validated correctly. End of story.

Ok, so what's all this about 'disable certificate validation' then? And why am I not at risk if I have this turned on.
Well, for some reason, PA have added the option to *validate the signing certificate*. Think of this in SSL terms. This means checking things like 'is it from a trusted CA', 'has it been revoked', etc. Now for SSL, this is important.
We receive public keys from random web sites we visit, with no way to validate that it is legitimate, without having a 3rd party (a trusted root CA) vouch for us.
So we make sure the certificate has been issued by someone we trust, it's hostname matches the destination we are trying to connect to, and that it hasn't been revoked. We don't need to do this in SAML. We established out trust point out-of-band.
We've told our SP "only trust assertions signed with this cert". We don't need a 3rd party to validate that trust further. If the IDP keys were compromised, we wouldn't fix this by simply revoking the certificate. We need to go to each SP that trusts the IDP certificate and
change it to a new trusted one. If we were to revoke it, we'd just instantly break all our apps.

I'm sure there are others besides PA that do it, but having the digital signing certificate validated like an SSL certificate, is a little strange.
Most implementations don't offer the ability to turn this on, let alone turn it off. That is why the guidance from most setup guides calls for disabling this. It is standard practice for the IDP to self-sign it's own signing certificates, and that doesn't need to change.
In the SAML signing world, we really only care about the public and private keys a cert contains. You can think of the cert as just a nice, friendly container we can use to transport those keys around. It doesn't need to be treated like an SSL certificate.
The SAML specification mandates validation of the digital signature in the assertion, but does not mandate validation of the signing certificate itself. Instead it mandates that the signing certificate be provided out-of-band and explicitly trusted by the SP.
So, the final question is, why does having this 'feature' turned on stop the problem? It is likely that in this scenario, the process of validating the signing certificate fails before getting to the digital signature validation code, where the security bug resides.
So having this turned on stops the problem because it never gets to the vulnerable code. Having it turned OFF doesn't CAUSE the problem. People shouldn't feel like they NEED to turn certificate validation ON. It may not even be possible depending on your IDP, and that's OK.
You haven't made a bad decision by turning certificate validation off. You didn't do anything wrong. Your IDP vendor didn't mislead you with bad doco. Once patched, it's completely OK to leave certificate validation off. This is in fact, a more 'standard' behavior for a SAML SP.
Missing some Tweet in this thread? You can try to force a refresh.

Keep Current with Ryan Newington [MVP] 🇦🇺

Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Follow Us on Twitter!

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3.00/month or $30.00/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!