I'm using Brokered Messaging (Topics/Subscriptions) in Azure Service Bus and I'm curious how (or whether) the communication is secured using SSL.
I'm sending and receiving messages using the connection string:
var connectionString = CloudConfigurationManager.GetSetting("Microsoft.ServiceBus.ConnectionString");
var Client = TopicClient.CreateFromConnectionString(connectionString, "TestTopic");
Client.Send(new BrokeredMessage());
Is that message secure when it is sent?
Yes and no. The communication to and from your client to the Azure server is encrypted if using TLS (SSL). Once that communication is complete and the data is passed along to the server process, it's no longer secure (it's behind the Azure firewall, etc. etc. but no longer encrypted).
Brokered messaging does not have a message-level security option like relayed messaging (WCF option) so only transport-layer security is used--which means it's only protected while in that transport layer.
Yes, they are using SSL by default. It might depend on your connectionstring, but I tested (and verified with Fiddler) with the following connection string and can say it is transport level encrypted:
Endpoint=sb://myns.servicebus.windows.net;SharedSecretIssuer=owner;SharedSecretValue=mykey
cheers
Related
We need some async workers for some 1-2 min tasks and then provide the user feedback from this tasks.
The idea would be to use the rabbitmq mqtt websocket plugin and provide the user feedback when the calculations done directly in the browser.
For our "old" stack we have some api endpoints as a layer between the user (browser) and rabbitmq services which more or less act as fire and forget.
As mentioned, we now need to provide feedback where we thought it would be create to user websockets (rabbitmq mqtt plugin).
But we are wondering how do we secure the exposed websocket endpoint for each user? Currently its not a problem as we have an amqps clients with X.509.
Our new features need has public access so we can not auth the user beforehand.
Is there a way to directly and securly use the exposed endpoint or do we need a layer in between as we have now?
The RabbitMQ Web MQTT plugin supports TLS. You can then use a username / password to authenticate the user, or use client certificates.
If you need public access then there is no way to secure the endpoint. This applies to all MQTT brokers, not just RabbitMQ.
NOTE: the RabbitMQ team monitors the rabbitmq-users mailing list and only sometimes answers questions on StackOverflow.
If you use a plugable authentication source (sorry, not familiar with what RabbitMQ offers here) e.g. that stores user/password in a database. Then you can generate a short lived set of credentials for each session and the webpage can request these from the server via a REST API and then use these to authenticate the MQTT connection over WebSockets.
This means that credentials are only exposed as variables for a short time as temporary variables in the browser, which can be revoked easily as soon as the web session/actions are complete
when working with service bus relay how's the security done?. Both transport and message level? If we use SAS key based sb endpoint does it mean it is https by default? At Message level I believe we have to do the regular encryption and decryption.
It uses either TCP, HTTP, or HTTPS depending on what you select. If you set it up so it uses client authorization, it will block you from using HTTP.
We use Azure Service Bus and Azure Web App which fills queue. They are in the same resource group. We use WindowsAzure.ServiceBus v2.6.5.
We get this error very rarely:
The X.509 certificate CN=servicebus.windows.net is not in the trusted people store. The X.509 certificate CN=servicebus.windows.net chain building failed. The certificate that was used has a trust chain that cannot be verified. Replace the certificate or change the certificateValidationMode. A certificate chain could not be built to a trusted root authority.
Question: Is this internal error on Azure ? If it's not, what can we do to not get this error ?
I managed to find our more information about this issue. First of all,
what needs to be established is that this is a pure client issue, this
is why there are no tracking IDs. The client refuses to complete the
TLS handshake with Service Bus.
This is a known issue this is a known issue with the way how Microsoft
manages certificates and how they are used on non-HTTP(S) transports.
The errors occur when the endpoint that hosts the intermediate
certificates for Microsoft is unavailable or slow or cannot be reached
by the client for any reason. We are investigating a workaround for
injecting the required extra certificate into the TLS handshake for
the SBMP and AMQP transports similar to how this is done by HTTP.SYS,
so that this extra request is not needed.
The immediate workaround available is to enable
ServiceBusEnvironment.SystemConnectivity.Mode = ConnectivityMode.Https
This will force all traffic to use a WebSockets tunnel that is
protected by a prior TLS/HTTPS handshake, and that handshake carries
the required intermediate certificate. The WebSockets handshake does
impose a little extra latency as the connection is established, but
will otherwise be comparable with the regular communication mode. The
messaging protocol used through that tunnel will still be AMQP or
NetMessaging, so you should not be worried to get HTTP characteristics
when choosing this option.
This is the response from Microsoft. I'll apply this and if I don't face any problem at some period time, I will accept this as an answer. Who faces this problem, they can try this also.
Edit:
ConnectivityMode.Https is just in avaliable service bus 3. I have to use servicebus 2 because of issue on Signalr. Therefore I couldn't apply this solution.
I believe there must be a missing certificate.
From this stack overflow post https://stackoverflow.com/a/24224550/4735373 here is a link that may help: https://corp.sts.microsoft.com/Onboard/ADFSOnboard.htm#Corp-STS-Certificates
I am using Azure service bus and I have a bounded context (profile management) that will send out updates to users profiles have occurred (an email_address_updated event for instance).
I would appreciate help with the following questions for Azure Service Bus:
Is it possible to secure the bus to prevent 3rd party apps from
sending data?
Is there built in support to prevent/detect forged messages, or
should i implement my own signature hash on the packet contents?
I am actually using the On-Premise Windows Service bus 1.1 and believe the functionality is the same as the Azure cloud offering.
To answer your questions:
Is it possible to secure the bus to prevent 3rd party apps from sending data?
The Azure one and the Windows Server Service Bus use security tokens to secure the access. Unless you want to explicitly allo unauthenticated users to access your Service Bus (why would you?). You can read more on Authenticating and Authorizing Service bus here.
Is there built in support to prevent/detect forged messages, or should i implement my own signature hash on the packet contents?
Nope. But there is built-in support for Authenticating and Authorizing. So unless you think anyone has stolen your SB credentials, all messages should be reliable. And if someone has stolen your SB credentials, most probably he/she has also stolen your hashing/signing algorithm and can generate system-valid message, so I would not bother for this part.
I am developing against software app that sends notifications via email and it doesn't support SSL/TLS encryption. I need to send these notifications to a server that only supports encrypted connections.
I am thinking about I might be able to solve these problems with a local mail relay, something that runs as a windows service and accepts local unencrypted connections then relays the mail to the proper server using an encrypted connection.
Does anyone know of a good lightweight mail relay/server app that I can use to do this? Is there a better solution?
I've had some great success with hMailServer - I think it covers your needs (I'm using it as a small domain mailserver).