listen(server_socket,queue_size);
some loop {
select(...); // listen for ready sockets to perform accept on
client_socket = accept(server_socket);
threadbegin(tls_accept, &client_socket); //start tls accept thread
}
void tls_accept(void * param) {
SOCKET socket = param;
int timeout = 15000;
int rc;
// Allocate SSL Context to ssl_con
setsockopt(socket, SOL_SOCKET, SO_RCVTIMEO, &timeout, sizeof(int));
SSL_set_fd(ssl_con, socket);
if (SSL_accept(ssl_con) <= 0) {
// Handle error ....
} else {
// Begin serving client ...
}
}
Jasper Spit wrote:
Bericht Don't know if this is appropriate for you, but if you're using a multithreaded app, make sure the SSL_accept call takes place in a seperate thread (dedicated for that client). That way if the connecting party never initiates or completes a handshake, your application will still be able to serve other clients.BTW, there's no need for non-blocking I/O if you use a multithreaded server. You can build your own timeout mechanism using e.g. select() prior to each read or write. This works fine for me, and is platform independent.-----Oorspronkelijk bericht-----
Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Namens Skip Rhudy
Verzonden: vrijdag 24 januari 2003 21:43
Aan: [EMAIL PROTECTED]
Onderwerp: SSL_accept hang
Hello all,
Recently we encountered behavior with SSL_accept() that can be exploited as a DOS attack. I’ve noticed a similar thread posted, but it focuses on Apache (Slapper denial-of-service problem – why isn’t this fixed?)
We use OpenSSL on in a Win2k environment. The latest code we have is 0.9.6h.
If SSL_accept is called in blocking i/o mode, and the client on the other end never initiates a handshake, or never sends any data at all, the SSL_accept() call never returns.
In the case of the particular server we are using, once that happens, further TCP accepts are blocked and so once the Winsock accept queue is full, the server stops responding.
This can be confirmed using telnet to the SSL listen port. If telnet sends no data, the SSL library doesn’t seem to timeout. Is there a timeout for handshake begin on the SSL_accept side? Is this a known issue? It sounds the same as the Slapper denial-of-service problem.
Regards,
Skip
There are traders and there are CyberTraders.~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CyberTrader does not accept buy or sell orders or cancels
through this medium and is not responsible for any orders
so placed. The information transmitted is intended only
for the person or entity to which it is addressed and
may contain confidential and/or privileged material.
Any review, retransmission, dissemination or other use
of, or taking of any action in reliance upon, this
information by persons or entities other than the
intended recipient is prohibited. If you received this
in error, please contact the sender and delete the material
from any computer.
WARNING: All email sent to or from this address will be
received or otherwise recorded by the Charles Schwab
corporate email system and is subject to archival,
monitoring or review by, and / or disclosure to, someone
other than the recipient.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
