[
https://issues.apache.org/jira/browse/QPID-3514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13121059#comment-13121059
]
[email protected] commented on QPID-3514:
-----------------------------------------------------
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2206/#review2342
-----------------------------------------------------------
** 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.
- Andrew
On 2011-10-05 13:36:58, Gordon Sim wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/2206/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-10-05 13:36:58)
bq.
bq.
bq. Review request for Andrew Stitcher, michael goulish, Ted Ross, and Chug
Rolke.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. Allow SSL and non-SSL connections on the same port. Patch contributed by
Zane Bitter for use by the Matahari Project.
bq.
bq.
bq. This addresses bug QPID-3514.
bq. https://issues.apache.org/jira/browse/QPID-3514
bq.
bq.
bq. Diffs
bq. -----
bq.
bq. /trunk/qpid/cpp/src/qpid/sys/ssl/SslSocket.cpp 1179157
bq. /trunk/qpid/cpp/src/qpid/sys/ssl/SslIo.cpp 1179157
bq. /trunk/qpid/cpp/src/qpid/sys/ssl/SslSocket.h 1179157
bq. /trunk/qpid/cpp/src/qpid/sys/ssl/SslIo.h 1179157
bq. /trunk/qpid/cpp/src/qpid/sys/TCPIOPlugin.cpp 1179157
bq. /trunk/qpid/cpp/src/qpid/sys/Socket.h 1179157
bq. /trunk/qpid/cpp/src/qpid/sys/SslPlugin.cpp 1179157
bq.
bq. Diff: https://reviews.apache.org/r/2206/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. 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)
bq.
bq.
bq. Thanks,
bq.
bq. Gordon
bq.
bq.
> Allow SSL and non-SSL connections on the same port
> --------------------------------------------------
>
> Key: QPID-3514
> URL: https://issues.apache.org/jira/browse/QPID-3514
> Project: Qpid
> Issue Type: Improvement
> Components: C++ Broker
> Affects Versions: 0.12
> Reporter: Zane Bitter
> Attachments: ssl-mux.patch
>
>
> The Matahari Project (http:://matahariproject.org for the uninitiated) has
> run into an issue with our use of Qpid in that IANA policy is now to refuse
> to assign separate TCP ports for SSL/TLS-wrapped versions of protocols, which
> leaves us with only a single port assigned to Matahari.
> We would like to be able to accept both SSL and non-SSL connections on the
> same port.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
