-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SSL Handshake Timeout #40
Comments
Sorry, I'm not fully certain of the requested feature. Care to elaborate more? |
Accepting SSL sockets requires additional handshake. Consider the following code snippet (a modified sample from boost asio examples) :
Without timeout, library is going to be vulnerable to DDoS, beacause |
I'm going to leave the issue open while I think about what to do here. Not sure if asio already provides a SSL handshake with a timeout. Maybe I could provide one. It'd be good to have a page just related to security too. Feel free to give suggestions if you have anything in mind. |
And thanks for spending time reviewing Boost.Http design on topics that may prevent its use. |
Was the ability to specify a timeout for the aync_handshake call on the server side ever addressed? What I had done to work around this in the past is to keep track of connections that have been accepted (along with time of acceptance) and are awaiting the aync_handshake callback to be called. Then in my async_accept callback which is called when a future connection comes in, I check if any of the outstanding ones have been outstanding longer than a given time and any that have, I call lowest_layer()->cancel() on my boost::asio::ssl::streamboost::asio::ip::tcp::socket boost socket to cancel them. This of course does not clean them up until a subsequent connection comes in after my "timeout". |
@sosroz, I'll be busy reviewing Boost.JSON for the next two weeks. I'll give proper attention to your message when I'm back. Thanks. |
@sosroz, no, it wasn't. The socket types are layerable. Just as you can layer a HTTP socket on top of a TLS socket, you can also layer this next-layer socket below a socket type to implement the timeout behaviour. You can explicitly opt-in, but if the feature was baked in, you would always pay the cost. So I personally think the way to go is to let the user to pull in the timeout behaviour himself. This is valid not only to this library, but any library built on top of Boost.Asio. |
SSL handshake timeout should be configurable.
The text was updated successfully, but these errors were encountered: