Azure Service bus - queue connectivity error - azure

Question

I am trying to connect and send a message to azure service bus queue using the following code
var connectionString = "<Your connection string>";
var queueName = "<Your queue name>";
var client = QueueClient.CreateFromConnectionString(connectionString, queueName);
var message = new BrokeredMessage("This is a test message!");
client.Send(message);
This is the same code they have on their site as an example.
But while connecting, it gives an SSPI ERROR with an inner exception of 'The client and server do not possess a common algorithm'.
Also, I have disabled TLS 1.0 and SSL 3.0 in my system. Is it because of that.
Can someone help me understand what is wrong here?

Answer 1

The client and server do not possess a common algorithm
That's not a TCP layer problem. That's higher up in the TLS handshake and it means just that. The two parties (client and server) could not agree on a common cipher suite and the handshake failed.
Run your client's host through SSLLab's browser test (even if it's not a browser):
https://www.ssllabs.com/ssltest/viewMyClient.html
Then run the Service Bus endpoint through the server test page:
https://www.ssllabs.com/ssltest/
Compare results and enable at least one cipher suite in your client that matches what the TLS stack on the Service Bus endpoint accepts.
You should also simply try doing:
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
..since you've disabled TLS 1.0 and i'm no longer sure what your .NET now defaults to, so explicitly setting the protocol version is the natural way to go.
TLS 1.2 was released back in 2008. You can be sure Azure supports it for all services, globally - check your own Service Bus namespace here!
(same story for 935x/TCP).
It's not enough to support TLS 1.2, your host must have at least one common cipher suite with the server -- use this to check your host:
https://github.com/snobu/get-schannel-ciphers (.exe under /Release/)

Answer 2

We encountered the exact same issue when we disabled TLS 1.0 and 1.1 (we used https://docs.nwebsec.com/projects/AzureStartupTasks/en/latest/ and also added
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
in Global.asax under Application_Start).
We opened a ticket with Microsoft support and found out that Azure Service Bus needs to be upgraded to .Net Framework 4.6.2 in order to support TLS 1.1 and TLS 1.2. Here are the details:
Service Bus relies on the underlying SSLStream class for secure communication for NetEventRealyBinding.
In WCF included in the .Net Framework 4.5.2, SSLStream only supports SSL 3.0 and TLS 1.0.
The WCF version in .Net Framework 4.6.2 supports TLS 1.1 and TLS 1.2 for SSLStream.
The Service Bus Service will need to be updated to use .Net Framework 4.6.2. Currently Service Bus uses OSFamily 4 https://learn.microsoft.com/en-us/azure/cloud-services/cloud-services-guestos-update-matrix#family-4-releases which has .Net Framework 4.5.2. Current plans to upgrade to .Net Framework are slated for middle of 2017.
I'll update this answer once I hear more from Microsoft.
UPDATE 2017-03-21:
Microsoft sent this workaround, which fixed the issue and allowed our code to work with TLS 1.2.
In the PowerShell script you currently use to set up TLS 1.2, add the following line. On .Net Framework 4.5.2 this will force SslStreams to use Tls 1.0/1.1/1.2. But since your machine allows only TLS 1.2, that will be used.
UpdateRegistryKey "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" "SchUseStrongCrypto" 1 "DWORD"
In you the startup of your code add the following line, and rebuild and retest
ServiceBusEnvironment.SystemConnectivity.Mode = ConnectivityMode.Https;