“Perhaps the intent is that a broker could at least avoid sending TCP-level redirects to a WebSocket client, allowing us to define a secure-by-default
scenario where TCP transport information in the REDIRECT frame is not transmitted through the intermediary, and internal network information is therefore not leaked across a trust boundary?”
Yes – that would be the simplest use case… The server will be aware that it doesn’t know how to handle this scheme and thus it should not send redirects since there is an unknown intermediary.
Potentially a server could be aware of external (to the server) actors which handle these “unknown” schemes… and based on configuration for the server (e.g. a lookup table) could generate a correct redirect URL without actually understanding
this URL – I don’t see this as a likely use case though
-- Rob
From: John Fallows [mailto:john.fallows@kaazing.com]
Sent: Sunday, December 13, 2015 10:39 PM
To: Godfrey, Robert X; amqp-bindmap@lists.oasis-open.org
Subject: Re: [amqp-bindmap] AMQP 1.0 Redirect with WebSockets
Folks,
I've updated the info map definitions for amqp:connection:redirect and amqp:link:redirect when used with WebSocket AMQP 1.0 binding based on our discussion here, and also recommended we support redirect of ws to wss, but not wss to ws for
security reasons.
SASL behavior during redirect remains unspecified, as the desired behavior is not clear and also not required to support functional redirect semantics for the WebSocket AMQP 1.0 binding.
There is an outstanding action item regarding the recommendation to include something like a "scheme" in the AMQP connection OPEN frame to indicate that the WebSocket binding is in use and therefore assist with the broker's generation of
redirect URLs to the client in the case where a websockets-to-tcp dumb intermediary is in place between the WebSocket client and the TCP broker.
However, if the broker is truly unaware of the WebSocket client without this extra information in the AMQP connection OPEN frame, then it is not at all clear how the broker could generate a meaningful AMQP connection or link REDIRECT frame
to be transmitted through the intermediary without modification and followed by the WebSocket client.
Perhaps the intent is that a broker could at least avoid sending TCP-level redirects to a WebSocket client, allowing us to define a secure-by-default scenario where TCP transport information in the REDIRECT frame is not transmitted through
the intermediary, and internal network information is therefore not leaked across a trust boundary?
Okay, finally had some cycles to look at this again.
Define some additional fields for both the amqp:connection:redirect and amqp:link:redirect types, mostly useful for our WebSockets case but potentially generic for any URL-based
AMQP 1.0 transport.
-
scheme : interpreted as same scheme if unspecified on "tcp", "tls" or "sasl" connection
-
path : must begin with leading "/" when required (based on scheme)
In combination with existing fields in those types...
-
hostname : the hostname of the container
-
network-host : DNS hostname or IP address of machine hosting the container
-
port : the port number on the machine hosting the container
-
address : the address of the terminus at the container (amqp:link:redirect only)
...we can construct a URL to follow the AMQP 1.0 redirect as follows:
...and then initiate connectivity to begin the handshake.
Should we use hostname as a default hostname in the WebSocket URL if network-host is omitted? (perhaps this is a required behavior)
Also modify HTTP header definition as follows:
Host HTTP header : this value MAY be used to identify the hostname of the AMQP container if the hostname field is omitted from the open frame during the AMQP handshake.
Should the additional field names and types for both amqp:connection:redirect and amqp:link:redirect be specified in AMQP 1.0 itself?
That would allow AMQP 1.0 specification to tighten up the behavior for redirected "tls" and "sasl" connections to explicitly re-use the same transport. (if that is the desired behavior)
The AMQP 1.0 WebSocket Binding could then define additional values for the scheme, namely "ws" and "wss", as well as define how the remaining fields should be interpreted by a WebSocket client. (as described
above)
Let's try to get as close as we can to a final decision on this during tomorrow's call.
[also see responses inline below for more detailed analysis]
Thanks Rob, I've been consumed by multiple weeks of travel spanning Asia and Europe but will review your response and follow up upon my return to normalcy next week.
My apologies to the group, I will be unable to attend our OASIS meeting today due to a conflicting customer appointment.
Hi John,
Apologies for the delay in responding to this…
>
Okay, getting closer... :-)
>
So, one possibility then would be to define some additional fields for both the amqp:connection:redirect
>
and amqp:link:redirect types, mostly useful for our WebSockets case but potentially generic for any
>
URL-based AMQP 1.0 transport.
>
> *
scheme : interpreted as "tcp" if unspecified
> *
path : interpreted as empty if unspecified
>
>
In combination with existing fields in those types...
>
> *
hostname : the hostname of the container
> *
network-host : DNS hostname or IP address of machine hosting the container
> *
port : the port number on the machine hosting the container
> *
address : the address of the terminus at the container (amqp:link:redirect only)
>
...we can construct a URL to follow the AMQP 1.0 redirect as follows:
>
>
>
...and then initiate network connectivity to "network-host" to begin the handshake.
So, I think the correct interpretation is scheme://network-host:port[/path]
That is in the URL the network-host should be used (rather than the AMQP container “hostname”, and
the path does need a mandatory leading slash.
Agreed - when required for a given scheme like ws, the path should include a leading slash.
>
However, browser environments do not allow such direct access to the network for sandboxed security reasons.
>
The network-host would have no meaning in that environment because the physical connectivity would typically
>
be determined by resolving the "hostname" in the WebSocket URL via DNS (in other scenarios a proxy may be
>
the first physical hop).
>
> Note: using the term "scheme" here rather than protocol since "wss" is not really a protocol, it is a scheme
>
that unpacks to ws protocol over http protocol (during-handshake) over tls protocol, etc. The
>
URL Wikipedia article makes the same point stating that the "mailto" URL scheme is not a protocol.
>
Perhaps we should also consider using "network-host" in the constructed WebSocket URL for redirect?
>
>
>
This may be more consistent with the TCP approach, given that there appears to be no requirement for the DNS
>
name of the machine hosting the container to match the logical AMQP 1.0 hostname used in OPEN.
>
>
This distinction between hostname and network-host is a key point that will potentially influence how we
>
proceed on the OPEN frame.
In general the idea is that hostname and network-host should be the same. Allowing hostname to be
set separately does potentially allow for the case where the proxy has a different address to the actual AMQP service (or simply where the AMQP service offers many more “virtual hosts” than DNS names :) ).
> Yes, this is a definite possibility, similar in spirit to the HTTP Host header that travels across any number
of TCP intermediaries
> before arriving at the target server HTTP endpoint.
> Perhaps something like "location" with value equivalent to "ws://example.com/amqp10"
would be a reasonable connection property to add in the OPEN frame from the client?
AMQP already carries a “host” in the open frame which sort of fulfils this purpose, however it does
not carry the protocol being used to connect (i.e. it would say only “example.com” or maybe “example.com/amqp10”)
– actually do we talk in the binding document about what value should be placed in the open frame here? My suggestion is that we additionally carry some property which conveys the protocol over which the initial connection was made.
>
In the binding document, we currently specify that the HTTP Host header in the WebSocket handshake should
>
identify the hostname of the AMQP 1.0 container and should match the hostname in the OPEN frame sent later
>
over the same connection after the WebSocket handshake is completed.
>
IMHO, the (optional) hostname concept in the OPEN frame is part of the AMQP 1.0 domain, whereas the HTTP
>
hostname in a WebSockets URL is part of the AMQP 1.0 transport and is not always required to match.
It’s certainly not required to match – I’m not sure what that sentence adds to the binding document,
the details of websockets as a transport should not really be relevant here
>
This interpretation seems consistent with the existing TCP semantics. For example, after following an
>
amqp:connection:redirect using TCP transport, the OPEN hostname may no longer match the DNS name of the
>
physical connection to network-host.
>
IMHO, there is an issue with the binding document in section 2.1 Opening a WebSocket Connection,
>
specifically regarding the interpretation of the HTTP Host header.
>
Host HTTP header : Identifies the hostname of the AMQP container. The value provided here SHOULD match that provided
later in the
>
hostname field of the open frame, and during SASL negotiation (if used).
>
The AMQP 1.0 OPEN frame should own identification of the AMQP 1.0 hostname when clients connect over
>
WebSockets just as for TCP, but the current wording of the binding specification seems to imply that
>
the HTTP Host header dominates when the HTTP Host header and AMQP 1.0 OPEN hostname field differ.
>
For example, if the AMQP 1.0 OPEN hostname is omitted from a WebSockets client, the same semantics as
>
TCP should be followed, namely "if no hostname is provided, the receiving peer SHOULD select a default
>
based on its own configuration" (AMQP 1.0 specification, section 2.7.1). Otherwise, there appears to
>
be no natural way to pick up the AMQP 1.0 broker default hostname when accessed by clients over
>
WebSockets.
>
If we intend to have the AMQP OPEN frame hostname field dominate, then perhaps we just need to modify
>
the wording:
>
Host HTTP header : this value MAY be used to identify the hostname of the AMQP container if the hostname field is
omitted from
>
the open frame during the AMQP handshake.
>
...or words to that effect. :-)
Agreed – I think this is a better definition
Okay, let's change it as proposed then.
> One thing that is still not quite clear to me in this approach is how an AMQP 1.0 broker would discover the appropriate
target
> WebSocket URL to redirect the client if the AMQP 1.0 broker is not directly already aware of WebSocket-based connectivity.
Yes – this could only work if the broker was aware that there is the possibility of
intermediaries, or in general allows full configuration of the properties that get put in the error map for redirect. At some level all values in the redirect map must have come from user configuration – what we are implying here is that broker vendors should
allow for the addition of properties to this configuration that they themselves do not understand.
>
An AMQP 1.0 broker configured for direct client access over WebSockets (without any tcp-to-websockets
>
intermediaries) would already be in a position to issue amqp:connection:redirect and amqp:link:redirect
>
frames modified as discussed above.
>
An AMQP 1.0 broker configured for direct client access over TCP, with WebSocket access via tcp-to-websockets
>
intermediaries, would require additional configuration to be in a position to issue amqp:connection:redirect
>
and amqp:link:redirect frames modified as discussed above.
>
Such brokers would also need to determine that a client could (only?) follow such a WebSocket-based redirect.
>
An AMQP 1.0 broker configured for direct client access over TCP, with WebSocket access via tcp-to-websockets
>
intermediaries that also understand AMQP 1.0 protocol, would not require additional configuration because the
>
intermediary could re-write amqp:connection:redirect and amqp:link:redirect frames modified accordingly as
>
discussed above.
>
Btw, what is the expected behavior of an AMQP 1.0 TCP client that receives a redirect after connecting via
>
SASL? Should the client use SASL for the redirected connection or not? Similar question for how to know
>
whether to use TLS when following the redirect.
I think the expectation is that it will attempt to establish the same level of encryption and use
the same identity as with the initial connection. This is never made explicit though.
As far as I can tell, we still have outstanding the definition of some connection property which
identifies the scheme/protocol over which the AMQP endpoint sending an open believes it is communicating (so a websocket client would say ws and a broker sending (potentially unknowingly) through an intermediary would say “tcp”… what else is there left to
define?
In an effort to remain compatible with existing semantics of redirect, we just need to make sure the default behavior is defined accurately as we add the ability to be specific about redirected schemes.
For example, interpreting the default scheme as "tcp" when unspecified would break the description you give above for "tls" redirecting still to "tls" or "sasl" redirecting still to use "sasl".
Given that you mentioned this is currently underspecified in AMQP 1.0, I would just like us to be careful about what we add for the AMQP 1.0 WebSocket Binding so as not to become inconsistent when that is specified later.
This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal
privilege, and legal entity disclaimers, available at
http://www.jpmorgan.com/pages/disclosures/email
See KWIC in action at Booth K24 at AWS re:Invent, Oct 6th - 9th
----------------------------------------------------------------------
KAAZING >|< when
real-time matters™
----------------------------------------------------------------------
KAAZING >|< when real-time matters™
This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email
|