Summary:
Fix vulnerability for origin pool TLS cert checking. There should be the option to validate the SAN entry of the origin certificate against request or SNI.
It's best if I point to the expected client behaviour when using the
TLS mode "server authentication with an unauthenticated client".
These links may be helpful:
https://datatracker.ietf.org/doc/html/rfc5246
This document specifies Version 1.2 of the Transport Layer Security
(TLS) protocol. The TLS protocol provides communications security
over the Internet. The protocol allows client/server applications to
communicate in a way that is designed to prevent eavesdropping,
tampering, or message forgery.
https://datatracker.ietf.org/doc/html/rfc5246#appendix-F.1.1
Authentication and Key Exchange
TLS supports three authentication modes: authentication of both
parties, server authentication with an unauthenticated client, and
total anonymity. Whenever the server is authenticated, the channel
is secure against man-in-the-middle attacks, but completely anonymous
sessions are inherently vulnerable to such attacks. Anonymous
servers cannot authenticate clients. If the server is authenticated,
its certificate message must provide a valid certificate chain
leading to an acceptable certificate authority. Similarly,
authenticated clients must supply an acceptable certificate to the
server. Each party is responsible for verifying that the other's
certificate is valid and has not expired or been revoked.
https://datatracker.ietf.org/doc/html/rfc5246#appendix-D.2
https://datatracker.ietf.org/doc/html/rfc6125#section-6
Representation and Verification of Domain-Based Application Service
Identity within Internet Public Key Infrastructure Using X.509 (PKIX)
Certificates in the Context of Transport Layer Security (TLS)
https://datatracker.ietf.org/doc/html/rfc6125#section-6.6.4
Fallback
Otherwise, if the client is an automated application not directly
controlled by a human user, then it SHOULD terminate the
communication attempt with a bad certificate error and log the error
appropriately. An automated application MAY provide a configuration
setting that disables this behaviour, but MUST enable the behaviour by
default.
The client should validate the TLS destination
server certificate by:
- SAN matches TLS/host destination as configured in XC Console
- Server certificate is current
- Server certificate or chain or root has not been revoked
- Server certificate is signed by trusted CA
If not the connection should be terminated.
In summary the current implementation does not meet the TLS 1.2 spec.
Similar behaviour can be achieved in a browser by clicking through the
security running or with curl using the "-k" flag. The client should not default to unsecure mode under TLS1.2 spec.