Stream: fhircast-github
Topic: docs / Issue #40 FHIRCast clients without SSL (no public ...
Github Notifications (FHIRcast) (Oct 25 2018 at 17:31):
gkustas opened Issue #40
Not unlike issue #33 (why must a subscriber have an accessible URL?), we want to implement FHIRCast as a context sharing mechanism between our Windows desktop application (C# forms app) and other third party apps (mostly PACS). I started looking at WebSockets thinking it may solve our problem, but it really doesn't. While we could use the WebSocket as a means for the hub to notify the client (real time) of events, we still can't allow the hub to send sensitive information over that WebSocket and still be secure.
I started thinking that we could have "limited" event data posted to the client over the WebSocket, where only some notification id is sent - nothing sensitive. Then the client could issue a query request to the hub (over secure HTTPS) to obtain the event data (eg. rest hook method GetEvent(int notificationId). But, this would require a new extension to FHIRCast, and it also goes against the WebSub specification intent - correct?
Additionally, the WebSub specification requires that subscriptions have a callback verification (see related issue #27 Callback URL Verification). Unless we change that specification making that callback optional, the client still needs to have a secure HTTPS accessible URL. We could say the verification payload contains NO sensitive data, and host the callback url on insecure HTTP, but I don't know if that is wise.
If we are going to consider the option of non-conformance with WebSub (which I have no problem with), and extending the FHIRCast specification to add event queries, I suggest we consider the following proposal:
1. Allow a subscriber to send a subscription parameter indicating that its callback URL is not secure, and all content (including the verification) WILL NOT contain sensitive information.
2. When an event occurs for such a subscriber, the Hub will send a "safe" notification event which will contain an id referencing the event.
3. The client then gets the notification event details using the new rest-hook method, eg. GetEvent(int notificationId).
Another option for us is to implement a "broker" as described by @RazStorm in issue #27. This would allow us to conform to all WebSub specifications, and would not require additional Hub methods. However, this would be a much more complex solution for us (and other PACS vendors) to implement. The broker would essentially implement the above proposal, and it would have to maintain routing, authorization and notification to all of the clients in its domain. It's also another point of failure added to the equation.
Github Notifications (FHIRcast) (Oct 25 2018 at 17:44):
gkustas edited Issue #40
Not unlike issue #33 (why must a subscriber have an accessible URL?), we want to implement FHIRCast as a context sharing mechanism between our Windows desktop application (C# forms app) and other third party apps (mostly PACS). I started looking at WebSockets thinking it may solve our problem, but it really doesn't. While we could use the WebSocket as a means for the hub to notify the client (real time) of events, we still can't allow the hub to send sensitive information over that WebSocket and still be secure. We might as well replace the WebSocket with an insecure HTTP Rest server on the client.
I started thinking that we could have "limited" event notification data posted to the client, where only some notification id is sent - nothing sensitive. Then the client could issue a query request to the hub (over secure HTTPS) to obtain the event data (eg. rest hook method GetEvent(int notificationId). This would require a new extension to FHIRCast, and it also goes against the WebSub specification intent - correct?
The WebSub specification requires that subscriptions have a callback verification (see related issue #27 Callback URL Verification). Unless we change that specification making that callback optional, the client still needs to have a secure HTTPS accessible URL. We could say the verification payload contains NO sensitive data, and host the callback url on insecure HTTP, but I don't know if that is wise.
So to conclude, I have to ask, why do we need conformance with WebSub? It is a great model for what FHIRCast is designed for (subscription/publication), but FHIRCast doesn't NEED to be WebSub compatible, does it? Does the FHIR specification say so? If it doesn't, I suggest we consider the following proposal or something similar:
1. Allow a subscriber to send a subscription parameter indicating that its callback URL is not secure, and all content (including the verification) WILL NOT contain sensitive information. The hub will return a response containing a unique subscription id if the subscription succeeds.
2. When an event occurs for such a subscriber, the Hub will send a "safe" notification event which will contain an id referencing the event notification.
3. The client then gets the notification event details using the new rest-hook method, eg. GetEvent(int notificationId).
4. All other protocols would remain the same.
Another option for us is to implement a "broker" as described by @RazStorm in issue #27. This would allow us to conform to all WebSub specifications, and would not require additional Hub methods. However, this would be a much more complex solution for us (and other PACS vendors) to implement. The broker would essentially implement the above proposal, and it would have to maintain routing, authorization and notification to all of the clients in its domain. It's also another point of failure added to the equation.
Github Notifications (FHIRcast) (Oct 25 2018 at 18:12):
lbergnehr commented on Issue #40
I've always thought about FHIRcast using https and wss when in an open environment. Are you saying that won't be enough? Perhaps I'm missing your concern.
Github Notifications (FHIRcast) (Oct 25 2018 at 18:19):
gkustas commented on Issue #40
Yes. Because unless I'm wrong, wss (Websockets with TLS) still requires
that the client has an SSL certificate. Correct? That is the biggest
problem we have right now.On Thu, Oct 25, 2018 at 2:13 PM Leo Bergnéhr <notifications@github.com>
wrote:I've always thought about FHIRcast using https and wss
<https://tools.ietf.org/html/rfc6455#section-11.1.2> when in an open
environment. Are you saying that won't be enough? Perhaps I'm missing your
concern.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<https://github.com/fhircast/docs/issues/40#issuecomment-433152506>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFw87qsND4Tn0DE1QDziGqrZ5jwa7hvZks5uof8rgaJpZM4X6whK>
.
Github Notifications (FHIRcast) (Oct 25 2018 at 18:32):
gkustas commented on Issue #40
Looking further into it I believe I was incorrect. It doesn't appear that
the WSS client requires a certificate as long as the WSS server has a valid
third party cert. This would be acceptable to us. I have to re-think
(again!).Maybe I should remove my post to prevent others from wasting their time -
or maybe I should just edit it?On Thu, Oct 25, 2018 at 2:18 PM George Kustas <gkustas@gmail.com> wrote:
Yes. Because unless I'm wrong, wss (Websockets with TLS) still requires
that the client has an SSL certificate. Correct? That is the biggest
problem we have right now.On Thu, Oct 25, 2018 at 2:13 PM Leo Bergnéhr <notifications@github.com>
wrote:I've always thought about FHIRcast using https and wss
<https://tools.ietf.org/html/rfc6455#section-11.1.2> when in an open
environment. Are you saying that won't be enough? Perhaps I'm missing your
concern.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<https://github.com/fhircast/docs/issues/40#issuecomment-433152506>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFw87qsND4Tn0DE1QDziGqrZ5jwa7hvZks5uof8rgaJpZM4X6whK>
.
Github Notifications (FHIRcast) (Oct 27 2018 at 07:05):
lbergnehr commented on Issue #40
Maybe I should remove my post to prevent others from wasting their time - or maybe I should just edit it?
I think it's good to keep it in case anyone else has the same thoughts.
Github Notifications (FHIRcast) (Oct 27 2018 at 07:06):
lbergnehr {} a comment on Issue #40
Maybe I should remove my post to prevent others from wasting their time - or maybe I should just edit it?
I think it's good to keep it in case anyone else has the same thoughts.
@isaacvetter, could you close this one, please?
Github Notifications (FHIRcast) (Nov 19 2018 at 15:23):
isaacvetter closed Issue #40
Not unlike issue #33 (why must a subscriber have an accessible URL?), we want to implement FHIRCast as a context sharing mechanism between our Windows desktop application (C# forms app) and other third party apps (mostly PACS). I started looking at WebSockets thinking it may solve our problem, but it really doesn't. While we could use the WebSocket as a means for the hub to notify the client (real time) of events, we still can't allow the hub to send sensitive information over that WebSocket and still be secure. We might as well replace the WebSocket with an insecure HTTP Rest server on the client.
I started thinking that we could have "limited" event notification data posted to the client, where only some notification id is sent - nothing sensitive. Then the client could issue a query request to the hub (over secure HTTPS) to obtain the event data (eg. rest hook method GetEvent(int notificationId). This would require a new extension to FHIRCast, and it also goes against the WebSub specification intent - correct?
The WebSub specification requires that subscriptions have a callback verification (see related issue #27 Callback URL Verification). Unless we change that specification making that callback optional, the client still needs to have a secure HTTPS accessible URL. We could say the verification payload contains NO sensitive data, and host the callback url on insecure HTTP, but I don't know if that is wise.
So to conclude, I have to ask, why do we need conformance with WebSub? It is a great model for what FHIRCast is designed for (subscription/publication), but FHIRCast doesn't NEED to be WebSub compatible, does it? Does the FHIR specification say so? If it doesn't, I suggest we consider the following proposal or something similar:
1. Allow a subscriber to send a subscription parameter indicating that its callback URL is not secure, and all content (including the verification) WILL NOT contain sensitive information. The hub will return a response containing a unique subscription id if the subscription succeeds.
2. When an event occurs for such a subscriber, the Hub will send a "safe" notification event which will contain an id referencing the event notification.
3. The client then gets the notification event details using the new rest-hook method, eg. GetEvent(int notificationId).
4. All other protocols would remain the same.
Another option for us is to implement a "broker" as described by @RazStorm in issue #27. This would allow us to conform to all WebSub specifications, and would not require additional Hub methods. However, this would be a much more complex solution for us (and other PACS vendors) to implement. The broker would essentially implement the above proposal, and it would have to maintain routing, authorization and notification to all of the clients in its domain. It's also another point of failure added to the equation.
Martin Bellehumeur (Visage Imaging) (Nov 19 2018 at 16:07):
Hi, would websocket over TLS be ok. That's what I'm using (wss instead of ws).
Last updated: Apr 12 2022 at 19:14 UTC
