Apigee accepts invalid server certificate (wrong.host.badssl.com/)

[guyhagemans]

Hi all,

For a client I needed to validate whether Apigee accepts or rejects server certs that are not properly configured.  

To test this I setup a target server to (URL Removed by Staff)

Whatever configuration I use in Apigee, it always accepts this host as valid and simply returns the response. Am I missing some configuration so that Apigee validated the server cert and returns an ssl error when it's invalid?

thank you and kind regards,
Guy

My config on the target endpoint:

    <HTTPTargetConnection>
        <LoadBalancer>
            <MaxFailures>0</MaxFailures>
            <RetryEnabled>true</RetryEnabled>
            <Server name="badssl-test">
                <IsEnabled>true</IsEnabled>
                <IsFallback>false</IsFallback>
                <Weight>1</Weight>
            </Server>
            <TargetDisableSecs>300</TargetDisableSecs>
        </LoadBalancer>
        <SSLInfo>
            <Ciphers/>
            <ClientAuthEnabled>false</ClientAuthEnabled>
            <Enabled>true</Enabled>
            <IgnoreValidationErrors>false</IgnoreValidationErrors>
            <Protocols/>
        </SSLInfo>
        <Properties/>
    </HTTPTargetConnection>

The target server points to 'wrong.host.badssl.com'. I tried with SSL enabled (and disabled). When enabled I also loaded the root cert of this address as a truststore, but it makes no difference. 

[dchiesa1]

I think you have a faulty assumption there. You're thinking the SSLInfo you specified in the HTTPTargetConnection applies to the targets in the Load Balancer. That's not so. 

Each targetserver you configure should have its own SSLInfo configured.  And the SSLInfo under HttpTargetConnection is ignored. I will update apigeelint to make sure it flags this error. (Edit: I checked - the existing Apigeelint already flags this as an error)

When I try this, with SSLInfo configured in the right place, it works for me. 

$ curl -i $apigee/badssl-test/via-target-server
HTTP/2 503 
content-type: application/json
apiproxy: badssl-test r2
x-request-id: 8b554e2a-00de-49b8-a936-d8548d7cd6ab
content-length: 232
date: Thu, 13 Jun 2024 17:23:47 GMT
via: 1.1 google
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000

{"fault":{"faultstring":"SSL Handshake failed java.security.cert.CertificateException: No subject alternative DNS name matching wrong.host.badssl.com found.","detail":{"errorcode":"messaging.adaptors.http.flow.SslHandshakeFailed"}}}                                         

My targetserver is like this: 

{
  "name": "badssl-wronghost",
  "description": "none",
  "host": "wrong.host.badssl.com",
  "port": 443,
  "isEnabled": true,
  "sSLInfo": {
    "enabled": true
  },
  "protocol": "HTTP"
}

and my targetendpoint is like this: 

<TargetEndpoint name="target-via-targetserver-1">
  ...
  <HTTPTargetConnection>
    <LoadBalancer>
      <MaxFailures>0</MaxFailures>
      <RetryEnabled>true</RetryEnabled>
      <Server name="badssl-wronghost">
        <IsEnabled>true</IsEnabled>
        <IsFallback>false</IsFallback>
        <Weight>1</Weight>
      </Server>
      <TargetDisableSecs>300</TargetDisableSecs>
    </LoadBalancer>
    <Properties>
      <Property name="success.codes">1xx,2xx,3xx</Property>
    </Properties>
  </HTTPTargetConnection>
</TargetEndpoint>

[guyhagemans]

hi Dino,

thank you for your response! I tried your setup, but it is still resulting in the same result unfortunately. Could it be because we're using Apigee Edge and not X?

 My target server config is;

The target endpoint now is;

    <HTTPTargetConnection>
        <LoadBalancer>
            <MaxFailures>0</MaxFailures>
            <RetryEnabled>true</RetryEnabled>
            <Server name="badssl-test">
                <IsEnabled>true</IsEnabled>
                <IsFallback>false</IsFallback>
                <Weight>1</Weight>
            </Server>
            <TargetDisableSecs>300</TargetDisableSecs>
        </LoadBalancer>
        <Properties>
            <Property name="success.codes">1xx,2xx,3xx</Property>
        </Properties>
    </HTTPTargetConnection>
</TargetEndpoint>

and the response is;

[guyhagemans]

I just had another good look. It seems there is a difference in behavior between Apigee X and Apigee Edge.

In X it is working as expected; the SSL Handshake failed error is shown for the bad host with the previously posted setup. 

However in Apigee Edge, the only way I can get this error to show, is by creating a trust store and adding a root certificate that does not belong to the host I'm sending my API request to. Only then Edge is throwing the SSL Handshake failed error. Which makes sense, because the server certificate does not belong to the root certificate, but this was just a test of course. I would expect Apigee to also validate the validity of the server certificate?

Why does this difference exist between X and Edge? 

[dchiesa1]

I would expect Apigee to also validate the validity of the server certificate?

Hmm

Can you try this?

  <SSLInfo>
      <Enabled>true</Enabled>
      <TrustStore>ref://mytruststoreref</TrustStore>
      <CommonName>*.example.com</CommonName>
  </SSLInfo>
  <URL>https://my.example.com/</URL>
  ...

https://cloud.google.com/apigee/docs/security-bulletins/security-bulletins#gcp-2024-006

or this?

  <SSLInfo>
      <Enabled>true</Enabled>
      <TrustStore>ref://mytruststoreref</TrustStore>
      <Enforce>true</Enforce>
  </SSLInfo>
  <URL>https://my.example.com/</URL>
  ...

I am not sure if the Enforce flag is supported in Edge.

Why does this difference exist between X and Edge?

If I recall correctly, when implementing X the product team decided to improve the enforcement of TLS validation.  (make the defaults more strict).  

[guyhagemans]

Thank you so much again, Dino!

Tested a bunch of scenarios. I see the following behavior:

1. When configuring the CommonName property, I get a 'Common-Name mismatch' error, so that's nice.
2. The Enforce configuration option does not seem to do anything in Edge.
3. Apigee Edge seems to happily connect to any host (wrong host, expired, revoked etc) when no trust store is configured.
4. When I configure a trust store with the root certificate of the host I'm connecting to, all the scenarios are marked as sslhandshakefailed except the wrong host. For that we have the CommonName property, so we're good.

Just one last question; when we set features.strictSSLEnforcement flag to true, and we connect to a backend with SAN names and we don't configure a truststore, what would happen? Does Edge check the SAN names and properly enfore SSL? 

[dchiesa1 · Accepted solution]

I'm glad to hear you got to a reasonably good place with this.

---

@guyhagemans wrote:

and we connect to a backend with SAN names and we don't configure a truststore, what would happen? Does Edge check the SAN names and properly enfore SSL? 

---

Dangit it sure should properly enforce, and if it doesn't, please raise a bug. Edge is documented as supporting SNI and SAN during the handshake and it should do the right thing. 

Here's the thing though, I just don't like it when people don't configure a TrustStore.  That feels like poor hygiene to me.  When I was on the product team I advocated that we stop supporting that scenario - in other words, refuse to deploy proxies that use an https TargetEndpoint that doesn't have a Truststore configured.  But I was overruled on that. Effectively Edge backs off to a "default truststore" , the contents of which, afaik, are not clearly documented.   If I were an API product manager using Apigee, or a security architect overseeing usage of Apigee, there's no way I would be ok with "oh, just use whatever truststore , it doesn't matter."   The apigeelint tool will flag this as an error. But ... that's an external tool, not part of the Apigee product. Anyway I'd advise against "not specifying a Truststore." or said in a less tortuous manner, I advise everyone to explicitly specify a TrustStore, and explicitly manage the certs in that TrustStore.  Principle of least Privilege and all that.

Of course what you are asking about is slightly different - you're saying when there's no explicit trustsstore, does Edge perform the TLS enforcement correctly?  that means, check the trustchain, check ciphers, check key strength, check validity dates, check CN or SAN agreement, etc.