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.
Related
I am developing an IoT device that uses TI's tm4c129encpdt microcontroller, cc3100 wifi chip and TI RTOS, and I am using TLS for secure communication with the server (HTTPS).
I just want to make my device more secure by adding some authentication methods. I am already assigning tokens to the device through a server.
Is there any standard way to add authentication method to an IoT device based on which I can assure to my clients that it has secured communication and authentication method?
Thanka and Regards
Akhilesh Gangwar
Use the 2-way authentication using TLS.
I have a scenario where I have 2 applications.
The service, providing some data
The UI client, displaying the data from the service
I want the communication between the service and the client to be secure (encrypted).
What should I use for that? Is the SSL common protocol for such usage, or do we typically use something else?
Assuming your service is exposing a standard REST API (or similar) that your front-end is calling: yes, SSL is the standard. It provides:
Confidentiality: the data is encrypted between the client and the server and cannot be read by an attacker. Typically uses the RSA algorithm.
Integrity: an attacker cannot tamper with the messages sent between the client and the server. Typically implemented using HMAC
Authentication: the client is able to check that the server it is talking to is actually yours, and not an attacker. Basically, the server shows to the client a certificate signed by the Certificate Authority having issued the SSL certificate (e.g. VeriSign), that proves its identity.
All that is assuming SSL is configured properly on the server's side: up-to-date ciphers, no support for outdated ones, proper key length (2048 bits or higher), etc.
Note that a client can be anything calling your service: a browser-based application, a mobile application, a smart watch application...
You can use SSL Labs to check if your SSL configuration looks secure.
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'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