How to avoid Men in Middle attack when you try establishing a new connection to SQL Azure via SSMS


Fact: All connections with SQL Azure are SSL encrypted. No exception.

Then what am I talking about? Why do I need to worry about Men in Middle attack now?

Turns out there’s a way, Men in Middle attack can happen – Not on your established connection But when the client first tries to establish a new connection. And in this blog post, we are going to see how to avoid Men in Middle attack when you first try establishing a new connection via SSMS.

BTW: I have not researched on how to do it from developers perspective, but if any developer is reading this and has figured it out – it would be great if you can share it with us via any communication means of your choice. (Thanks a lot – if you do so).

[Update: See Bottom of the post]

Any-who. Back to SSMS.

All you got to do to avoid this improbable situation to happen is just check the “Encrypt connection”in the connection property when you try establishing a *new* connection to SQL Azure.

That’s it.

if the client requests encryption from the beginning then our connection is not susceptible to Men in Middle attach while the client is negotiating with the server for encryption.

Categorize under “Best practice” if  you wish to.


Update: Developers, When you connect to SQL Azure using ADO.Net – please do not forget to set 1. Encrypt = TRUE and 2. TrustServerCertificate = False  to avoid man in middle attack.


And Thanks to Herve Roggero for his response on my (poorly framed) question on StackOverflow. I am glad, he understood what I meant!  Thanks sir 🙂

My article on “Tuning SQL Azure databases – Part 2/2” got published in SolidQ Journal’s september edition


Part 2/2 of “Tuning SQL Azure Databases” got published. The aim of the series was to show you the options that are available to tune a SQL Azure database. In part two, I  discuss on how to use information made available through dynamic management views (DMV’s) available in SQL Azure; while the first part focused on examining execution plans and tuning the database based on that information. Here are the links to download the magazine:

Part 2:

Part 1:

Top two ways you can screw up the established SQL Azure connection from SSMS 2008 R2 running locally


I am able to connect to SQL Azure database through SSMS (SQL server Management studio) 2008 R2 running on my machine. What I want to do is to tinker with the configuration and create a situation where I am not able to connect to SQL Azure DB through SSMS 2008 R2. Simple, eh?! Destructive – oh yeah!

Now that I know I can connect to SQL Azure through SSMS, let’s tinker it so that I am not able to connect to SQL Azure.


First thing we are going to do is block our very own machine through the great wall of china  SQL Azure Firewall. So connect to the Master database and let’s see the firewall rules:


you can see that, my SQL Azure DB allows connection from all possible IP ranges. FYI: this is my test account. In big bad world, it’s not a recommended practice. be careful. Anyways, since we do not want ourselves to get connected to the SQL Azure DB, we will go and delete the firewall rule named “all” that allowed IP range to to connect to SQL Azure DB.

so I ran this command on my Master database via principal server login:

exec sp_delete_firewall_rule N’all’;

Now, try connecting to the SQL Azure DB again. you will get an error message: “cannot connect to [randomstring]”


So remember:


Now I enable “ALL IPs” to access the server and here I try reconnecting to SQL Azure:


It runs! Now, let’s do some other type of tinkering and see what are the other ways in which we can spoil our connection to SQL Azure DB from SSMS.

Open, SQL server configuration manager –> SQL server network configuration  –> Disable TCP/IP.

When you alter the status from “enabled” to “disabled”, you are then asked to restart the SQL server. Please do so!

Now, try reconnecting to the database – and thou shall be greeted with an error:


Note that to connect to SQL Azure DB, we should make sure that port 1433 (TCP IP) is open for outbound access

Thus remember:


There’s couple of more ways:


And Uninstall the latest version of “recommended” SSMS and install the SSMS from pre-R2 era. Just kidding again!





BTW the goal of the article was to show you that to connect to SQL Azure, you should have

1) The recommended version of SSMS

2) Correct SQL Azure firewall rule settings

3) TCP/IP enabled on local machine


Related Posts:

SQL Azure Firewall: An unique security paradigm of SQL Azure << Paras Doshi