At substantial risk of beating the proverbial already-dead horse, here're some questions I have:
- is legitimate Web-client-issued renegotiation observed in real world ? In other words, do the web browsers of today issue legitimate renegotiation requests ? Some of such "legitimate" reasons could include desire to refresh keys etc after a connection been active for a while and/or significant amt of data has been exchanged. - having look at some open source code, it seems most of them treat renegotiation attempts as grounds for connection termination. Most use flags of sorts to trap SSL_ERROR_WANT_READ|WRITE returns from SSL_write() and SSL_read(), respectively, after the initial handshake/negotiation occurred and react to it as a renegotiation attempt. - what is the proper way to tell clients to NOT attempt renegotiation ? Will doing so have adverse effect on any legitimate uses of renegotiation ? - there seem to be a significant fear of illegitimate use of renegotiation as a DOS tool and outside of the well publicized and long-since-fixed exploit, that is the main reason developers are paranoid about allowing renegotiations ? - a way to tackle the above could be limiting SSL connections to a sane number of renegotiations - say a few, over some time interval, to allow for legitimate use of renegotiation yet limit potential of DOS attack.
