Skip to content
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

Open
avalchev opened this issue Aug 8, 2016 · 7 comments
Open

SSL Handshake Timeout #40

avalchev opened this issue Aug 8, 2016 · 7 comments

Comments

@avalchev
Copy link

avalchev commented Aug 8, 2016

SSL handshake timeout should be configurable.

@vinipsmaker
Copy link
Member

Sorry, I'm not fully certain of the requested feature. Care to elaborate more?

@avalchev
Copy link
Author

avalchev commented Aug 8, 2016

Accepting SSL sockets requires additional handshake.

Consider the following code snippet (a modified sample from boost asio examples) :

  auto socket = make_shared<ssl::stream<ip::tcp::socket>>(*_io_service, *_ssl_context));
  _acceptor->async_accept(socket->lowest_layer(),
                          [this, socket] (const error_code &error)
                          {
                          // some error handling, etc...

                           // Negotiate algorithm. Call to low level OpenSSL stuff.
                            socket->lowest_layer().
                            async_handshake(
                                                ssl::stream_base::server,
                                                [this, socket] (const error_code &error)
                                                {
                                                  on_accept(error, socket);
                                                })
                          });

async_handshake is negotiating the encryption algorithm and after that method finishes successfully, you can consider that SSL connection is establish. Without invoking async_handshake it's just a plain socket connection.

Without timeout, library is going to be vulnerable to DDoS, beacause async_handshake waits for client confirmation forever.

@vinipsmaker
Copy link
Member

The lower-level socket (be it TCP/SSL/...) is exposed through the next_layer() member-function and you're in control of the SSL handshake.

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.

@vinipsmaker
Copy link
Member

And thanks for spending time reviewing Boost.Http design on topics that may prevent its use.

@sosroz
Copy link

sosroz commented Sep 3, 2020

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".

@vinipsmaker
Copy link
Member

@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.

@vinipsmaker
Copy link
Member

Was the ability to specify a timeout for the aync_handshake call on the server side ever addressed?

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants