Allow SSL and non-SSL connections on the same port
Review Request #2206 - Created Oct. 5, 2011 and submitted
Allow SSL and non-SSL connections on the same port. Patch contributed by Zane Bitter for use by the Matahari Project.
make check passes; tested with and without the multiplexing; tested client authentication; tested SASL EXTERNAL (requires reverting a recent change unrelated to this, see QPID-3522)
Posted (Oct. 5, 2011, 1:36 p.m.)
Patch looks fine to me in general. Only comment is the use of a dummy option to communicate between SSL and TCP transports seems a little odd. However there isn't really any better mechanism as yet and changes to allow a 'nicer' approach - i.e. richer configuration of transports - are probably better done as a separate patch anyway.
Posted (Oct. 5, 2011, 3:39 p.m.)
** We can't accept this as it stands as it will break IPv6 support if turned on. ** On the whole I think it is moving in the correct direction, but it is only partly formed: * This works in effect by adding in *another* transport type - the muxed SSL transport. We are trying to reduce and simplify the number of transports not increase them, this will make the code harder to maintain over all. * It's not clear to me why we wouldn't want this always turned on if we have the capability. In other words what is the benefit of ever turning it off. When we can do this switch then we should have it on for all listening sockets, the only option should be to allow a port to only accept encrypted connections. * This code is tactical, not strategic in that it works for this particular case, but as far as I can tell won't help in the upcoming amqp 1.0 case where we would need to switch to TLS processing sometime during the amqp protocol processing. * The code that selects between encrypted and non encrypted code paths should be unified with the code that checks the protocol version, currently the accept code does this and blocks whilst reading some bytes from the connection. I really don't like this approach. - Actually this code makes me wonder if we should change the architecture of the socket code to have an explicit piece of code which is run just after accepting a socket to select which bits of code get run next.