|
I suppose one could abuse SSL_set_msg_callback() to create a filter that rewrites the initial re-handshake message into something innocuous. Though I doubt that would work,
once the client starts a handshake, it expects a response from the server, and may well time out and close if it does not get one. The way TLS works, it is always the client starting a renegotiation. The server can send a message asking the client to renegotiate,
but the client can ignore that. I don’t believe the opposite is true. From: openssl-users [mailto:openssl-users-bounces@xxxxxxxxxxx]
On Behalf Of Sashank Mullapudi (samullap) Resending this hoping for a response from someone who has information on disabling TLS renegotiation from the Client side. Thanks, Sashank From:
samullap <samullap@xxxxxxxxx> Hi, As part of securing our web interfaces, we wanted to disable client-initiated TLS renegotiation. The reasoning for this requirement is as follows- Generally,
renegotiation of TLS sessions is much more resource-intensive for the server than the client, and should therefore not be performed at will to avoid degrading performance. Disabling client from renegotiating secures the server from undergoing a DoS attack
due to continuous renegotiation requests. I see that there is an option SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION,
but that is to secure the renegotiation, not disable it. I wanted to check if there is a patch or flag available to disable any negotiation initiated from the client side. Thanks and Regards, Sashank |
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
