[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.