Failed SSL handshake causes bip to write to a random socket, and never close the connection
Lately, I've occasionally received errors in my client saying "Unknown message '28126:error:1407609C:SSL', The IRC server received a message it did not understand.", typing 'lsof -i' on the machine bip is running on would then show there was an incoming connection from a weird, foreign IP address to bip, which ended up in CLOSED_WAIT state.
My theory on why this happens is this: when using SSL (client_side_ssl = true), bip will write an error to stderr when the SSL handshake fails. However, if it is running as a daemon, stderr will have been closed. This means that it is likely that this file descriptor is now used as a connection to a server or client. So when something connects and tries to send something that isn't a valid SSL handshake, bip will print an error to the server, which then responds that it doesn't understand that message. This could even allow an attacker to, for example, cause bip to send a lot of malformed messages and get disconnected from the server.
This happens because there is a BIO* struct created that is initialized with stderr (src/connection.c:1206) for handling SSL errors. It would be better if this were printed to the global log file.
Also, when an SSL handshake error occurs, a socket is never closed, but remains in CLOSE_WAIT state forever. This happens because a socket that is set to have an error will never be closed (src/connection.c:57).
I'm attaching a patch that fixed both of these problems.