Provide means to restrict TLS cipher suites or means to access cipher suite information
Provide (1) means to restrict TLS cipher suites that are used in TLS communication between Azure API Management and API callers or (2) means for developers to access detailed information about the cipher suite used in the TLS connection from within API implementations.
We are investigating whether Azure API Management can be used for Financial-grade API (https://openid.net/wg/fapi/).
Financial-grade API, also known as FAPI, is a set of standard specifications that are built on top of OAuth 2.0 and OpenID Connect. UK Open Banking (https://www.openbanking.org.uk/) has officially adopted FAPI and built Open Banking Profile (OBP) on top of FAPI.
The FAPI specification set consists of 5 parts. The first two describe security requirements for Read-Only API (Part 1) and Read-Write API (Part 2), respectively. You can find the latest snapshot of them here:
Financial-grade API - Part 1: Read-Only API Security Profile
Financial-grade API - Part 2: Read and Write API Security Profile
In "8.5 TLS considerations" of Part 2, there is a requirement as follows:
Only the following 4 cipher suites shall be permitted:
Other weak cipher suites has to be rejected when an authorization request is made for FAPI Read-Write APIs.
To make a FAPI-compliant system on top of Azure API Management, either of the following means is necessary.
(1) Means to restrict cipher suites.
(2) Means for developers to access detailed information about the cipher suite used in the TLS connection so that API implementations can judge whether the connection should be rejected or not with the information.
Bruno DEMEYERE commented
In a general way, a way to access (in gateway logs for example) to client side transport security protocol (TLS 1.0 , 1.1 ...) would be great to be able to better plan our TLS security updates.
One option would be to put an Application Gateway in front of the APIM and making it internal. The cipher suites can be customised using a SSL Policy.