Question

I would like to find an elegent way to ensure that my self-hosted web services connect to Azure Service Bus (topics and queues) via HTTPS - I don't want them falling back to HTTP.

// this ensures that HTTP is used instead of TCP sockets.
ServiceBusEnvironment.SystemConnectivity.Mode = ConnectivityMode.Http;

The above setting to ensures that TCP sockets aren't attempted, but I cannot find any way of making sure that HTTP fallback isn't used in the case of a failure to set up HTTPS (SSL).

My proxy stops fiddler from working nicely with the service bus, so when I bring up fiddler it just records a bunch of (unencrypted) HTTP traffic going out from my servers - obviously this is the opposite of what I want.

The messaging entities expect to be passed a URI in the shape of

 Endpoint=sb://somenamespace.servicebus.windows.net/; ...

Which prevents me from specifying https://.... . Does anyone have any ideas of how and where I can forbid Service Bus from using unencrypted communications?


Interestingly (inconsistently?), the namespace manager doesn't seem to mind using a URL with https in it ...

var ns = NamespaceManager.CreateFromConnectionString(
  "Endpoint=https://somenamespace.servicebus.windows.net/;..."
);

Update #1 : Booting up wireshark, looks like the communication going is through port 80. It uses http 1.1 streams, which explains why fiddler and the proxy didn't play nicely. A handshake takes place where azure sends a webstream address in a 201 response, and then TCP packets start getting passed over port 80, including information in the clear like the following:

*sb://somenamespace.servicebus.windows.net:80/....application/ssl-tls
...
(later on)
... 
http://www.microsoft.com/pki/mscorp/MSIT%20Machine%20Auth%20CA%202(1).crt

This makes me strongly suspect that TLS traffic is being sent through port 80 - though I'd like for someone to be able to confirm this.

Was it helpful?

Solution

According to a few presentations on Azure [ 1, 2 ]:

If TCP ports 9350-9353 are blocked:

  • Listeners listen via outbound HTTP (Port 80). "TCP equivalent tunnel with overlaid TLS/SSL formed over a pair of HTTP requests."

  • Senders send via outbound HTTPS (Port 443).

This matches up with my observations from wireshark. It doesn't appear that Azure Service Bus has a non-encrypted fallback for brokered messaging - even when it falls back to port 80 the communication remains encrypted via TLS/SSL.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top