Forum Discussion
CirrusCipher suite mismatch advertisement/warning
Martin182 So in iRule event CLIENTSSL_CLIENTHELLO is when the SSL ciphers are sent and then in CLIENTSSL_HANDSHAKE is when the SSL handshake finishes for an HTTPS connection. You would not be able to send any redirect or message until you reached the HTTP_REQUEST event occurs which is after the HTTPS connection establishes. If you cannot establish and HTTPS connection then you cannot send a message back to the client. This is the reason why I was stating that prior to your chipher change date you should have the website in question have a popup stating the cipher change and then a link to where they can go to validate the SSL ciphers that their browser supports.
MVPMartin182 Because the action you are looking for after SSL negotiation has completed this wouldn't be possible. Your better option would be to have a popup now that says you will be putting some SSL restrictions in place, define what the restriction is, and then send them a link to a URL that allows them to check their compatability with the ciphers in question.
- Martin182
Hi Paulius, thanks for your reply
So I guess at the balancing level there is no configuration that I can apply on the F5 that meets my goal?
- Paulius
Martin182 I'm not aware of a mechanism that would allow a user to attempt SSL handshake and then if it fails it would receive a redirect instead. This is an issue because in order to receive the redirect the client would have to complete the SSL handshake.
- Martin182
But in theory at the start of the ssl handshake, the client informs of the cipher suites it supports, therefore, it would not be possible to return the warning at that moment in case they are not those indicated in an iRule?
Obviously adding in that iRule only those supported by the server (those indicated in the ssl profile configured in the VS).
