Should Network Layer Protections be made server-side enforced?

[Filip Skokan]

Currently, the language in https://openid.net/specs/fapi-2_0-baseline-01.html#name-network-layer-protections and https://openid.net/specs/openid-financial-api-part-2-1_0.html#tls-considerations does not mention the party responsible for the cipher enforcement.

The FAPI certification suite currently fails clients that make a connection using a cipher that falls outside of the 4 allowed. But in its TLS configuration it does not rank the four allowed as the most preferred.

This means that a client which cannot control its allowed ciphersuite fails certification because it chooses a cipher that isn’t amongst the 4 allowed but ranks higher in preferrence by the certification server.

I thinks it’s unreasonable to assume that every client software is capable of controlling the allowed TLS ciphers and that this should be made a server-side requirement to enforce.

This affects both FAPI1 and FAPI2

[Joseph Heenan]

The current configuration for testing clients in the suite (which ends up using the apache/openssl default ciphers) is definitely not right; I believe the ordered preference list is:

‌

# openssl ciphers -v | grep TLSv1.2 | head -20 | awk '{print $1}'
ECDHE-ECDSA-AES256-GCM-SHA384 
ECDHE-RSA-AES256-GCM-SHA384 <-- FAPI
DHE-RSA-AES256-GCM-SHA384 <-- FAPI
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305
DHE-RSA-CHACHA20-POLY1305
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256 <-- FAPI
DHE-RSA-AES128-GCM-SHA256 <-- FAPI
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES256-SHA384
DHE-RSA-AES256-SHA256
ECDHE-ECDSA-AES128-SHA256
ECDHE-RSA-AES128-SHA256
DHE-RSA-AES128-SHA256
RSA-PSK-AES256-GCM-SHA384
DHE-PSK-AES256-GCM-SHA384
RSA-PSK-CHACHA20-POLY1305
DHE-PSK-CHACHA20-POLY1305
ECDHE-PSK-CHACHA20-POLY1305

In particular it makes no sense to have them in this order, the FAPI ones should really be first or last, depending what we’re trying to test. (We have a further check that the cipher that is negotiated is a FAPI one.)

The key question is the one Filip asks: Are clients expected to only support the 4 FAPI ciphers, or can they rely on the server limiting the cipher list? I’m not sure how vulnerable TLS 1.2 might be to person-in-the-middle cipher downgrade attacks.

[Filip Skokan]

We’ve agreed on today’s call to update the “Requirements for endpoints not used by web browsers” section. The update will say that server shall enforce the specific TLS1.2 ciphers and that clients are also recommended (or should) to do so.

[Filip Skokan]

https://bitbucket.org/openid/fapi/pull-requests/383/update-tls-12-cipher-suites-section

[Filip Skokan]

Resolved with https://bitbucket.org/openid/fapi/pull-requests/383 and https://bitbucket.org/openid/fapi/pull-requests/384

Certification suite change is also tracked.

[Joseph Heenan]

Ticket raised here to make sure this change is applied to the conformance suite: https://gitlab.com/openid/conformance-suite/-/issues/1321