From the articles I read - The high risk vulnerability is affected on Openssl 1.1.1 & 1.0.2 versions. F5 v15 is running on 1.0.2, so yes this version might be affected.
Fixed in 1.1.1l.
We should wait for an official confirmation on this.
We did open a support case 6 weeks ago now. The F5 answer was they are evaluating it and we should just keep checking for HotFixes or other content to see if there will be a change. My security folks are not very pleased with that answer so I hope this is reviewed faster. We just pinged the case again yesterday but they are itching to close it since they have no response.
I would settle for a workaround but I believe doing anything in an iRule would be too late in the process when using TLS in the BIG-IP.
I believe dealing with CRLs has more to do with what the functions was supposed to do. Looking at the description (and the code for the openssl fix), it would seem a mitigation would be to compare the type before the TLS session is created. I was thinking that an iRule with code handling the CLIENTSSL_CLIENTHELLO
event could use SSL::extensions to check if both GENERAL_NAMEs contain an EDIPARTYNAME (which is what triggers the error).
I do not know enough yet on how to dig into the type to check it yet. I also do not know for certain doing this in an iRule catches it early enough.
Obviously the best solution is for F5 to adopt the OpenSSL fix in OpenSSL 1.1.1i or OpenSSL 1.0.2x.
