Edge doesn't validate the target's certificate?

Google Cloud Apigee
1

We have recently come across an issue where we realized that Edge doesn’t validate the backend’s certificate even when the IgnoreValidationErrors property is set to false.

To validate this issue we are using the https://expired.badssl.com. Also, our actual backend certificates are CA signed hence i assume that we need not to create the trust store.

Following is our target configuration:

    <HTTPTargetConnection>
        <SSLInfo>
            <Enabled>true</Enabled>
            <ClientAuthEnabled>false</ClientAuthEnabled>
            <IgnoreValidationErrors>false</IgnoreValidationErrors>
        </SSLInfo>
        <URL>https://expired.badssl.com</URL>
    </HTTPTargetConnection>

Can anyone please let me know if I am missing anything?

Thanks

3 Likes
2

@Dino

, @Anil Sagar Could you please help us with this ?

3

I have examined the problem and believe that Edge is falling victim to a bug in Java8 related to SNI.

See https://bugs.openjdk.java.net/browse/JDK-8144566

Some background. SNI is Server Name Indication, an extension to TLS that allows a TLS Server to deliver different certs to the client depending on the server host name the client has requested. This allows a single server to handle multiple endpoints, with different certs. This is really important for density - nobody wants to run a separate server for each different hostname that is available via https.

The sites at badssl.com use SNI. The problem is the Java HTTP client library does not properly handle SNI. Apigee Edge relies on Java, and as a result, the cert that Apigee Edge sees in your scenario, is not the cert associated to “expired.badssl.com”, but instead a fallback cert.

The cert for expired.badssl.com is actually expired (it has notAfter=Apr 12 23:59:59 2015 GMT) .

The fallback cert (CN = badssl-fallback-unknown-subdomain-or-no-sni) is not expired.

Therefore you are not seeing a rejection of the cert based on expiry, because in fact the cert Edge receives is not expired.

There is a second issue - and that is related to verification of the CN, or Common-Name. Your SSLInfo does not specify the CommonName element, and as a result, Edge is not verifying the CommonName.

To correct this, in all cases where you want to verify the names of certs, amend your SSLInfo so that it is like so:

<HTTPTargetConnection>
  <SSLInfo>
    <Enabled>true</Enabled>
    <ClientAuthEnabled>false</ClientAuthEnabled>
    <CommonName>COMMON-NAME-HERE</CommonName>
    <IgnoreValidationErrors>false</IgnoreValidationErrors>
  </SSLInfo>
  <URL>https://expired.badssl.com</URL>
</HTTPTargetConnection>

In fact if you insert “badssl-fallback-unknown-subdomain-or-no-sni” for the CommonName (do not include the quotes), you will see that the HTTPTargetConnection succeeds. If you insert “expired.badssl.com”, you will see an error: Common-Name mismatch. This, again, is a side effect of the fact that Edge is receiving the fallback cert, not the cert you would expect to see for expired.badssl.com .

OK, so… to sum up.

  1. Edge is not properly handling targets that rely on SNI. This is due to a Java bug.
  2. Edge will properly verify the notAfter attribute on certs, and will reject expired certs. You cannot test this using expired.badssl.com , because of item #1.

I believe Apigee can work around the Java bug, but it may be some time before we can engineer a fix and test it, and deliver it. So for now, I would advise you to avoid using SNI in targets. For your reference, the ticket number for this is APIRT-3770.

Oh, and @aagrawal , if you want Apigee Support to track progress on the issue, please open a support ticket with the support desk, and mention that ticket. You may wish to escalate the issue if you are particularly affected. Of course if the problem is only occurring in your tests related to badssl.com, then it may not be appropriate to escalate.

1 Like
4

Currently, if you don’t define a TrustStore in SSLInfo, MP will trust the target cert, whether expired or not, whether self signed or commercially signed.

5

True Fliu and it is an unacceptable behaviour. Proper handling of SSL certificate is the foundation of API security but Apigee doesn’t care. Not even the documentation mentions this thing.

6

I agree this should be documented.

In this case, security is 100% in user’s hand. Users that are most security conscious will use TrustStore to only trust their internal CA or their target cert, other may use TrustStore to trust some commercial CAs, yet others will trust everything, as long as there is SSL encrypted. It is debatable what should be the default behavior, but given current default has been there many many years, changing it will most definitely cause P1 to some users. Letting users decide what they want to do (via TrustStore) seems like best option for now, instead of making a decision for them.

1 Like
7

Thanks Fliu for considering this question and replying.

I still believe that a company like Apigee, (which is an API Management giant and also a part of google which always emphasize on security), shouldn’t make the API security optional by not implementing a basic stuff that all the API clients (eg: OS, browsers, curl, java…) not only uses but also updates regularly definitely for some good reason.

Please consider a case in which the edge customer who doesn’t manage the target’s infrastructure for some reason and to secure his APIs he configure a truststore, and now someday for some reason the target’s SSL certificate has got changed and in result edge would throw an error until the trustore is updated with the new certificate. Can Apigee justify the downtime in this scenario?

I understand that this bug (for me it is a bug only) has been there for long and it can lead to P1s. I am pretty sure that Apigee would have some process to deal with scenarios. Also, initially Apigee can make it an organization level variable to configure the default truststore.

With the current behaviour, considering fact that the big organizations in health, finance domain use Apigee Edge, it can lead to a big data breach if some malicious server is able to impersonate target.

I hope you understand my concern.

Thanks

8

The case you mentioned may be exactly the reason why Edge trusts all by default. Any other default behavior would cause a downtime, eg: if target cert changes from Godaddy signed to self signed, what do you think Apigee should do for you NOT to have downtime?

For your other example about big organizations, I would imagine they would prefer they use TrustStore to control what Apigee should trust rather than letting Apigee decide if/what cert to trust. Remember a few years ago some CA signed certificates got banned by Chrome while other browsers still trust for some longer time? Some Edge customers may want to immediately un-trust the CA so malicious server can’t impersonate target, while other Edge customers may want to keep trust a big longer since their target is signed by such CA. TrustStore can exactly offer such flexibility. I can’t think of a reason why big organizations wouldn’t use it if their top concern is security.

2 Likes
9

Hi @Dino

is there any news regarding this?

I would like to validate backend certificates without giving the concrete CommonName in the Proxy. That way you could validate certificates such as

*.my.server.com

Sadly the current documentation states:

  • The certificate presents a common name. If there is a common name, Edge does not validate that the common name matches the hostname specified in the URL.

Best regards,

Oscar Pinilla

10

You can use the CommonName element to validate the common name of the peer. See my example configuration above.