Last Modified: Sep 13, 2023
Known Affected Versions:
12.0.0, 12.0.0 HF1, 12.1.0 HF1, 12.0.0 HF2, 12.1.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.1 HF1, 12.1.1 HF2, 12.1.2 HF1, 12.1.2 HF2, 12.1.0, 12.1.1, 12.1.2, 12.1.3, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124
14.0.0, 126.96.36.199, 188.8.131.52
Opened: Feb 21, 2018 Severity: 2-Critical
SSL SNI mechanism creates a hash containing a mapping between SAN entries in a given profile's certificate and the profile. This hash is owned by the default SNI profile, however is held by the other profiles on the VIP without a reference. If a connection utilizes SNI to use a non-default SNI profile *and* the default SNI profile reinitializes its state for any reason, the prf->sni_certsn_hash can be cleared and freed, leaving the existing connection(s) with profiles that refer to the freed hash. If then the connection attempts a renegotiation that causes the hash to be used, the freed hash can cause a fault should it have been reused in the meantime (i.e. the contents are invalid). The fix: When the default SNI profile is initializing, and SSL handshake is searching SAN/COMMON cert from non-default SNI profile, stop the search and return NULL.
Traffic is disrupted while TMM restarts.
SNI configured with one default SNI profile, one or multiple SNI profiles. The default SNI profile is changed and renegotiation with SNI(with non-default SNI profile) is issued.
There is no workaround at this time.
When the default SNI profile is initializing, and SSL handshake is searching SAN/COMMON cert from non-default SNI profile, stop the search and return NULL.