fix vulnerability for origin pool TLS cert checking

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.

  • Lewis Cole
  • Feb 5 2025
  • Attach files