Finally we have decided to leave only ECDHE ciphers. As I said, maybe it is too restrictive and non-technical users who try to access the service but use a browser not compatible with the cipher suites, we want them to be informed that they should update their browser or receive a message they can understand.
In short, the idea is to know if there is any way that in the case that the client cannot negotiate any cipher suite, an error message can be displayed by means of an iRule or similar.
@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.
@Martin182 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 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.
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).
@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.
