Explicitly supress TLSv1.0, TLSv1.1 on Edge on public cloud instance, and allow only TLSv1.2 on incoming connections!

Not applicable

How to explicitly suppress TLSv1.0, TLSv1.1 on incoming connections on the Edge platform hosted on public cloud?

Need some guidance on that as there isn't a way of finding out the list of clients that are on these versions of TLS!

Solved Solved
0 3 308
1 ACCEPTED SOLUTION

You cannot set "ssl_protocols" in the Cloud, see docs here: https://docs.apigee.com/api-platform/fundamentals/virtual-host-property-reference

However, you can set the "ssl_ciphers" property of the VirtualHost, and if you set it to the complete list of TLSv1.2 ciphers from https://www.openssl.org/docs/man1.0.2/apps/ciphers.html you will see errors if you are not using TLSv1.2, at least that worked while testing with curl.

1. Update existing Virtual Host to use all of the TLS 1.2 ciphers.

...
"properties": {
        "property": [
            {
                "name": "ssl_ciphers",
                "value": "DHE-DSS-AES128-SHA256:DHE-DSS-AES128-GCM-SHA256:DHE-DSS-AES256-SHA256:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-GCM-SHA384:DH-DSS-AES128-SHA256:DH-DSS-AES128-GCM-SHA256:DH-DSS-AES256-SHA256:DH-DSS-AES256-GCM-SHA384:DH-RSA-AES128-SHA256:DH-RSA-AES128-GCM-SHA256:DH-RSA-AES256-SHA256:DH-RSA-AES256-GCM-SHA384:ADH-AES128-SHA256:ADH-AES128-GCM-SHA256:ADH-AES256-SHA256:ADH-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES128-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-ECDSA-AES256-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES128-SHA256:ECDH-RSA-AES128-GCM-SHA256:ECDH-RSA-AES256-SHA384:ECDH-RSA-AES256-GCM-SHA384:AES128-SHA256:AES128-GCM-SHA256:AES256-SHA256:AES256-GCM-SHA384:NULL-SHA256"
            }
        ]
    }, 
...

2. curl a request using --tlsv1.0 or --tlsv1.1 and then using --tlsv1.2

curl --tlsv1.1 https://{{ORG}}-{{ENV}}.apigee.net/pingstatus/v1/ping
curl: (35) error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

curl --tlsv1.2 https://{{ORG}}-{{ENV}}.apigee.net/pingstatus/v1/ping (valid error response from proxy)
{
    "code": "401.001",
    "message": "Invalid Access Token",
    "info": "https://developer.company.com/errors#401.001"
} 

So if a client is making a call using anything but TLSv1.2 they should see an error.

If there too many errors, just switch the Virtual Host back to not using any ciphers.

Hope that helps!

View solution in original post

3 REPLIES 3

The restriction would have to be defined in your Virtual Host Configuration.

<VirtualHost name="myTLSVHost">
    <HostAliases>
        <HostAlias>apiTLS.myCompany.com</HostAlias>
    </HostAliases>
    <Interfaces/>
    <Port>9006</Port>
    <SSLInfo>
        <Enabled>true</Enabled>
        <ClientAuthEnabled>false</ClientAuthEnabled>
        <KeyStore>ref://myTestKeystoreRef</KeyStore>
        <KeyAlias>myKeyAlias</KeyAlias>
    </SSLInfo>
    <Properties>
        <Property name="ssl_protocols">TLSv1.2</Property>  
    </Properties>
</VirtualHost>

Please note that based on the documentation at https://docs.apigee.com/api-platform/system-administration/creating-virtual-host#virtualhostconfigur... , this works only with 4.17.01 and later, so it will work with the public cloud.

Thanks @rmishra, I will ask our development team to try and post the output here.

You cannot set "ssl_protocols" in the Cloud, see docs here: https://docs.apigee.com/api-platform/fundamentals/virtual-host-property-reference

However, you can set the "ssl_ciphers" property of the VirtualHost, and if you set it to the complete list of TLSv1.2 ciphers from https://www.openssl.org/docs/man1.0.2/apps/ciphers.html you will see errors if you are not using TLSv1.2, at least that worked while testing with curl.

1. Update existing Virtual Host to use all of the TLS 1.2 ciphers.

...
"properties": {
        "property": [
            {
                "name": "ssl_ciphers",
                "value": "DHE-DSS-AES128-SHA256:DHE-DSS-AES128-GCM-SHA256:DHE-DSS-AES256-SHA256:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-GCM-SHA384:DH-DSS-AES128-SHA256:DH-DSS-AES128-GCM-SHA256:DH-DSS-AES256-SHA256:DH-DSS-AES256-GCM-SHA384:DH-RSA-AES128-SHA256:DH-RSA-AES128-GCM-SHA256:DH-RSA-AES256-SHA256:DH-RSA-AES256-GCM-SHA384:ADH-AES128-SHA256:ADH-AES128-GCM-SHA256:ADH-AES256-SHA256:ADH-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES128-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-ECDSA-AES256-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES128-SHA256:ECDH-RSA-AES128-GCM-SHA256:ECDH-RSA-AES256-SHA384:ECDH-RSA-AES256-GCM-SHA384:AES128-SHA256:AES128-GCM-SHA256:AES256-SHA256:AES256-GCM-SHA384:NULL-SHA256"
            }
        ]
    }, 
...

2. curl a request using --tlsv1.0 or --tlsv1.1 and then using --tlsv1.2

curl --tlsv1.1 https://{{ORG}}-{{ENV}}.apigee.net/pingstatus/v1/ping
curl: (35) error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

curl --tlsv1.2 https://{{ORG}}-{{ENV}}.apigee.net/pingstatus/v1/ping (valid error response from proxy)
{
    "code": "401.001",
    "message": "Invalid Access Token",
    "info": "https://developer.company.com/errors#401.001"
} 

So if a client is making a call using anything but TLSv1.2 they should see an error.

If there too many errors, just switch the Virtual Host back to not using any ciphers.

Hope that helps!