How to determine what protocol is being used by the clients while connecting to Edge ?
We would like to know what protocols (TLS 1.0, 1.1, or 1.2) are used by the clients while making API requests to Edge. Want to get data around how many clients are using TLS 1.0, 1.1 or 1.2. Is it possible to get this information through Analytics ?
Best Answer
After some investigation, I figured out the following information. We have two options:
Option #1: Logs on Elastic Load Balancer
- If we have Elastic Load Balancer (ELB) in front of the Apigee Router and the SSL termination happens on the ELB, then we can enable logs on the ELB.
- The logs contain the information about the Client IP address and also the Protocol being used to communicate with Apigee Edge.
- Refer to this link to understand the log entry format and what each of the fields represent to determine the Client IP and Protocol.
Option #2: Nginx Access Logs on Apigee Router
- If the SSL termination happens on the Apigee Router, then Nginx access logs has a field named "jsonPayload.ssl_protocol" which will contain the information of the protocol being used by the clients to communicate with Edge.
- For ex:
jsonPayload.ssl_protocol TLSv1.2
- For ex:
If your security requirements allow for it, there is a possible workaround.
You can terminate TLS at a load balancer infront of the Apigee Router (instead of the Apigee Routers), the load balancer can be configured to capture these TLS attributes and propagate them as HTTP headers.
Whether you can/should use this workaround depends on your InfoSec requirements, placement zone of Apigee Routers , etc.
Answer by Dino
·
Dec 20, 2017 at 08:41 PM
Amar, I think that information is not propagated from the router to the MP, when TLS is used.
This page describes the TLS variables. But I believe the doc is out of date. ( @Floyd Jones FYI ) When Apigee moved from the netty router to nginx, the nginx config did not reproduce the netty behavior in this respect. Variables for TLS info related to the client cert were no longer propagated. There is a bug: b/67884063 .
I think the analogous is also true when the connection uses 1way TLS: There is nothing about the protocol or cipher propagated to the MP.
