22-Sep-2023 05:30 - edited 22-Sep-2023 05:36
Hi, this issue is linked to:
https://community.f5.com/t5/technical-forum/cipher-suites-supported-12-1-5-3/m-p/321291#M271493
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.
Thank you,
Best regards
Solved! Go to Solution.
23-Sep-2023 13:25
@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.
22-Sep-2023 06:20
@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.
22-Sep-2023 09:57
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?
22-Sep-2023 21:34
@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.
23-Sep-2023 10:31 - edited 23-Sep-2023 10:32
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).
23-Sep-2023 13:25
@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.
23-Sep-2023 13:49 - edited 23-Sep-2023 13:49
Okay, understood, thank you
25-Sep-2023 21:47
Thanks for following up and marking the solution @Martin182 - that really helps future-community-selves.
Welcome and thanks for being a part of our community.
25-Sep-2023 23:14
Thanks to you Lief, this is a fantastic community and it's helping me a lot. I am very new to F5 equipment yet.