If a TLS error occurs, it could end up in a situation where the network handler code did not want to
read or write because it only had the error flag set. However, this was not handled, which left the
socket triggering in the event loop - but nothing was done to handle it.
This can easily cause a 100% cpu situation - the hub is still functioning though while this is
happening.
uhub has the ability to disconnect a 'ghost' user, e.g. if a user
reconnects then uhub will kick the existing user if it is still there.
However, this could also be triggered abusively by having two "tabs" or windows
connect at the same time from the same client. The process of connecting a new
client is rather expensive because it triggers a lot of updates on all connections.
With this change, uhub will only attempt to disconnect the existing client if
it is marked with the "flag_choke" flag, which indicates that messages must be
dropped simply because the client is not accepting data fast enough. This will
cause the new connection to fail because the user is already logged in.
This can be further improved by adding a timestamp for when the connection
previously was provable working. Which is possibly a better and more reliable
way of detecting ghost users.
This used to be a linear search O(n), but is now done
as a red-black tree O(log n) instead.
These operations can be further opimized with a hash-table
which would acheive near constant time lookups.
- Added a list_remove_first() which is generally better than list_remove()
provided you want to remove the first element.
- Added a list_append_list() to append and move all nodes from one list to
another.
Previously you would have to do something like this:
for (type foo = (type) list_get_first(list); foo; foo = (type) list_get_next(list)
{
/* code */
}
Now, you can instead write this as:
LIST_FOREACH(type, foo, list,
{
/* code */
})
Basically, boilerplate stuff including the casting is gone.
uhub did not have this security bug since the hub did not advertise support for the
UCMD extension, but the message was still correctly relayed as specified in the
protocol specification.
However, this commit adds support for the UCMD extension, but only to the extent
that uhub will advertise it and uhub will also drop any such CMD message
generated by a client and will (currently) never issues a CMD message by itself.
GnuTLS sends a handshake with SSL 3.0 (0x0300) in the outer packet, but
mentions TLS 1.2 (0x0303) in the Client Hello. There's no real need for
uhub to validate these fields, as OpenSSL should do that itself already.
Just use the version mentioned in Client Hello for logging output.
