microsoft / AzureManagedHsmTLSOffload

Azure Managed HSM SSL/TLS Offload Library for F5 and Nginx
MIT License
12 stars 1 forks source link

"%" in SPN Secret fails decoding between OpenSSL <> LIBP11 #3

Open sayandaw opened 1 year ago

sayandaw commented 1 year ago

"%" in SPN Secret fails decoding between OpenSSL <> LIBP11

Issue

Scenario:

The SPN's secret has a "%" Then when OpenSSL uses the LIBP11 library and calls the mHSM library, the "%" passed as headers is decoded and hence the OpenSSL connection fails with

Error: "error":"invalid_client","error_description":"AADSTS7000215: Invalid client secret provided. Ensure the secret being sent in the request is the client secret value, not the client secret ID, for a secret added to app 'XXXX'"

Explanation:

As per MS. please note that this behaviour is expected according to section 2.3. PKCS #11 URI Scheme Syntax of https://datatracker.ietf.org/doc/rfc7512/ .

When libp11 encounters a "%" character in any attribute value, it considers it as a percent-encoded character and attempts to decode it, thereby removes it. Therefore, if we have "%" in any attribute value, such as client secret, we should encode it. The value of option “-key” is PKCS#11 URI that OpenSSL forwards to libp11 to access the key stored in HSM.

It is worth noting that the OpenSSL library calls the libp11 library, which in turn calls our TLS offload library. The libp11 library provides a higher-level interface compared to the PKCS#11 library, and it is designed to integrate with applications that use OpenSSL.

Workaround

Don't use an SPN which has "%" in it's secret.

MukeshBharsakle commented 1 year ago

According to RFC 7512, which can be found at https://datatracker.ietf.org/doc/rfc7512/, this behaviour is expected.

Use of the "pin-value" attribute may have security-related consequences. Section 6 should be consulted before this attribute is ever used. Standard percent-encoding rules SHOULD be followed for the attribute value.