TLS information flow variables

[dave_pickard]

I'm having an issue accessing details of client certificate with a client authentication = true virtual host.

If I send the request via Postman, it looks like I can only access client certificate information using request.header.X-Apigee.tls.client.s.dn flow variable - the documented flow variables (e.g. tls.client.s.dn) aren't available. If I send the request via curl these 'header' variables aren't available but the documented flow variables are available. I'm struggling to see what the cause of this - both requests look identical and given it's an SSL connection thing I wouldn't expect anything in the request to affect this anyway. The virtual host is set up with clientProperties and connectionProperties both true under propogateTLSInformation.

Anyone else seen any issue? Anyone from Apigee got any clues?

[dchiesa1]

Let me look into this for you.

Sorry about the delay, I had been attending to other things for the past week and a half, and it looks like no one else picked up this question!

[dchiesa1 · Accepted solution]

Here's what I think.

There is a previously identified bug in Apigee Edge, ref: b/120288238 , which causes tls.* related flow variables to be unset in some cases. After investigating we found that this can occur when the client does not specify a TLS session.id . The implementation in Apigee Edge had assumed that all TLS sessions included a session id; this is not a valid assumption.

both requests look identical

@Kurt Googler Kanaskie did some testing with tcpdump and wireshark to compare curl and postman TLS handshaking. His findings:

- curl sends a Client Hello and receives a Server Hello with a session.id
- Postman does not send a Client Hello and does not receive a Server Hello or session.id.

Neither is wrong. Today I learned that the idea of Session ID was included in SSL 2.0 as a way to optimize the TLS handshake between a client and a server, and it continues in the current TLS implementations. But there is a superceding option, Session Tickets, which allows similar capability without the session ID data item. In short, there are different defaults in TLS-enabled clients, and that's all ok. And what looks identical in the HTTP layer is not actually identical at the TLS layer.

OK, so three things.

1. As of 2019 April 30, There is a bug in the current cloud version of Apigee Edge which prevents correct setting of the tls.* variables in some cases. Ref b/120288238 .
2. Is there an immediate workaround? Yes, and it is possibly suitable. If you can configure your TLS clients to negotiate a TLS session with a session id, then you'll avoid this bug in the Apigee Edge runtime, and your API proxies will "see" the tls.* context variables. I won't be able to elaborate on how to do this with various clients; that is left as an exercise for the reader.
3. Is there a fix? Yes, we've built and tested the fix and hope to release it soon, before the end of the month. The fix entails setting the documented tls.* context variables in all cases, whether there is a TLS session id or not. When this fix is released, keep in mind that the context variable storing the TLS Session id may be null or empty!

I'd advise you to not depend on the undocumented X-Apigee.tls header variables. Those will go away when we release the fix.

[kurtkanaskie]

Thanks @Dino-at-Google for explaining what I observed, I just chalked it up to Postman, but glad I understand the situation and we have a fix.

[dave_pickard]

Thanks @Dino-at-Google. At the moment I'm trying to read the flow variables and reverting to X-Apigee.tls headers if they're not available. I guess that will continue to work once the fix is in place - it'll just never end up reverting to the headers (and we can then tidy up the code).

[dchiesa1]

Thats a workable approach!

[shawkyfoda]

Hi Mr. Pickard,

Could You please suport, I'm not able to capture this info inspite of :

1- Configure the virtual host as :

"propagateTLSInformation": { "clientProperties": true, "connectionProperties": true },

2- Call the proxy using both postman and/or curl

Could You please provide your proxy bundle example demonestrating the capture of the TLS info. whether it is in the header or in the flow variable

[#8]

Hi Shawky,

The TLS information will be available in the flow variables in the proxy. You can see in the beginning of trace, all the cn and other information of the certificate there.

[shawkyfoda]

@Dino-at-Google

Thank You Priyadarshi Ajitav Jena

However, I'm still not able to capture these info

Virtual Host Configuration - with Client Auth Enabled

Curl Used to test the service :

curl --request POST 'https://api-trust-test.moj.gov.sa/v1/Tahseel/notifications/PaymentNotification' --header 'Authorization: Bearer *************' --cert /tmp/MOJETest-cert.pem:moj --key /tmp/MOJETest-key.pem -d '' -v

Your Support Will be Highly appreciated

[#10]

did you configure this in your virtualhost ?

"propagateTLSInformation": { "clientProperties": true, "connectionProperties": true },

Your virtualhost configuration should have

<VirtualHost name="secure">
    ....
    <SSLInfo>
        <Enabled>true</Enabled>
        # Enable two-way TLS.
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <IgnoreValidationErrors>false</IgnoreValidationErrors>
        <KeyAlias>ks-alias</KeyAlias>
        <KeyStore>ref://ks-ref</KeyStore>
        <TrustStore>ref://ts-ref</TrustStore>
    </SSLInfo>




    <PropagateTLSInformation>
        <ConnectionProperties>true</ConnectionProperties>
        <ClientProperties>true</ClientProperties>
    </PropagateTLSInformation>




</VirtualHost>

ref: https://docs.apigee.com/api-platform/system-administration/tls-vars

If the above part is configured, then only all tls information will be shown in the trace flow begining.

[shawkyfoda]

Yes, its configured and confirmed from Edge UI

[dchiesa1]

You may need to contact Apigee support to help you diagnose this.

[shawkyfoda]

Thanks @Dino-at-Google @Dino-at-Google

As we recently upgrate Apigee to 4.50 , should this upgrade fix the above bug ref: b/120288238 ?

[dchiesa1]

YES, OPDK 4.50 contains the fix for b/120288238 .