Outlook Connection Status Shows "Clear [Anonymous]" and "SSL [No]"

If your mailbox is hosted in Office 365 Exchange Online you may be surprised to see that the Outlook Connection Status shows Authn "Clear [Anonymous]" and Encrypt "SSL [No]", as shown below.

Outlook Connection Status

Note: You can view the Outlook Connection Status by ctrl+right-clicking the Outlook icon in the Windows Taskbar when Outlook is open or by running Outlook /rpcadmin from the Run menu.

Ctrl + Right-Click the Outlook Icon to view Connection Status

While "Clear [Anonymous]" authentication and "SSL [No]" encryption may look scary, understand that both authentication and encryption are enabled in the Service. 

The "Clear [Anonymous]" authentication method refers to the inner authentication channel that is no longer used in Office 365 since it only uses RPC over HTTPS. Technically, it should probably show either "n/a" or the external auth method (if Outlook can even see that). Just know that all authentication is performed at the HTTP layer now, which is encrypted via SSL.

The "SSL [No]" encryption method may well be a UI bug. I have a case open with Microsoft to look into it. In the meantime, I configured a Network Monitor trace to confirm that Outlook is using HTTPS to encrypt the authentication and connection with Office 365.

Here, we see a connection between Outlook 2013 and Exchange 2013.

Exchange 2013 NetMon Trace

The trace shows Outlook on the source computer (MAILGATE) starting up and connecting to the Exchange 2013 CAS (EX1).  In the first three frames we see Outlook negotiating with EX1 using HTTPS port 443. The next two frames show the SSL handshake and the certificate exchange with the target server, EX1. Note in the detail of frame 116 that the certificate being used to encrypt the conversation is a wildcard cert (*.theguillets.com) from DigiCert. From there on, we see that all communication is encrypted using TLS on port 443. All further authentication and application data transferred from EX1 is encrypted and cannot be read in the NetMon trace, proving that the entire conversation is encrypted.

Now let's take a look at the same process when Outlook 2013 connects to Exchange Online in Office 365:

Office 365 NetMon Trace

This trace shows the identical sequence of events. MAILGATE negotiates with the Office 365 CAS (OFFICE365) in the first three frames using HTTPS port 443. The next two frames show the SSL handshake and the certificate exchange with the target server, OFFICE365. Note in the detail of frame 576 that the certificate being used to encrypt the conversation is a SAN cert (outlook.office365.com) from Microsoft IT. Just like the connection with Exchange 2013, the entire conversation is encrypted and cannot be read by NetMon.