Whether organizations store and process data on-premise, in the cloud, or use a combination of both, it is important that they protect that data when it is transmitted across networks to information workers, partners and customers.
For example, when an administrator is using the Microsoft Azure Portal to manage the service for their organization. The data transmitted between the device the administrator is using and the Azure Portal needs to be protected. Another example is protecting both outbound and inbound email. When you send an email to someone when using Outlook.com, your email is encrypted and thus better protected as it travels between Microsoft and other email providers that also support email encryption.
Microsoft is using encryption to protect customer data when it’s in-transit between our customers and our cloud services. More specifically, Transport Layer Security (TLS) is the protocol that Microsoft’s data centers will try to negotiate with client systems that connect to Microsoft cloud services. There are numerous benefits to using TLS including strong authentication, message privacy, and integrity (enables detection of message tampering, interception, and forgery), interoperability, algorithm flexibility, ease of deployment and use.
Perfect Forward Secrecy (PFS) is also employed so that each connection between customers’ client systems and Microsoft’s cloud services use unique keys. Connections to Microsoft cloud services also take advantage of RSA based 2,048-bit encryption key lengths.
The combination of TLS, RSA 2,048-bit key lengths, and PFS makes it much more difficult for someone to intercept and access data that is in-transit between Microsoft’s cloud services and our customers, than previously employed encryption technologies. Since no encryption suite is truly unbreakable, the goal of these protections is to make it extremely time consuming and expensive for would-be eavesdroppers to intercept and decrypt data that is transmitted between client devices and Microsoft datacenters. I have included some references at the bottom of this article if you are interested in learning more about PFS and TLS, and how Windows clients negotiate encryption protocols when connecting to servers. Besides using a newer version of Windows, there isn’t any action customers need to do to secure data in-transit between them and Microsoft’s cloud services.
Since seeing is believing I thought I’d show you what is actually happening on the wire when a client system connects to a Microsoft cloud service. Figure 1 and Figure 2 are screen shots of a network monitor trace I took while I was logging into the Azure Portal. This trace shows the Windows system I used to log into the Azure portal negotiated a secure connection that uses TLS and Elliptic curve Diffie–Hellman (ECDH) for PFS, and that the subsequent data communicated between the client device and the portal is encrypted and unreadable if intercepted.
In this article I provided some details on how Microsoft protects data in-transit between our customers’ client devices and Microsoft’s cloud services. But there are numerous additional encryption controls that customers can choose to use to protect their data depending on the type of service they are using and the risk they are trying to mitigate. I will cover some of these controls in future articles in this series on cloud security controls.
Some newer useful content:
Speaking in Ciphers and other Enigmatic tongues…
How to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll
Protecting against the SSL 3.0 vulnerability
How to Disable SSL 3.0 in Azure Websites, Roles, and Virtual Machines
Associating a custom domain and securing communication with Microsoft Azure
Chief Security Advisor
Worldwide Cybersecurity & Data Protection