7

I have an IMAP + SMTP server running on linux, using Dovecot + Postfix. The server only accepts connections over TLS and uses plaintext authentication once the tunnel is established.

I was auditing the mail logs today and was concerned by unknown remote IP addresses shown for some IMAP logins. After some investigation, I found that the logins correspond to Outlook for Android clients.

I am satisfied that the logins are legitimate since:

  • no unauthorised mail has been sent
  • there have not been any failed login attempts
  • the behaviour has been consistent since the Outlook for Android clients were setup.
  • the remote IP addresses seem to be registered to Microsoft.

The remote IPs are in the blocks:

52.125.138.x
52.125.140.x
52.125.141.x

The log entries look like:

dovecot: imap-login: Login: user=<...>, method=LOGIN, rip=52.125.x.x, lip=x.x.x.x, mpid=x, TLS, session=<...>

So I can only assume that the outlook mobile client is designed to use an intermediate server.

Presumably, this is to conserve battery life by allowing the MS server to poll the real mail server and push notifications to the phone.

However, as far as I can tell, this means Microsoft must be storing (at least temporarily) the user credentials in plain-text on their intermediate servers.

Security Implications

  1. Is it possible that they could be authenticating over a TLS tunnel from their own server rather than the client device without sharing the credentials?

  2. Does this mean that the intermediate server is able to read mail prior to pushing it to the client?

  3. Is this behaviour documented or known?

p.s. others seem to have noticed this behaviour:

Improve this question

2 Answers 2

Reset to default
3
  1. Is it possible that they could be authenticating over a TLS tunnel from their own server rather than the client device without sharing the credentials?

No, for the server to make the connection, it has to know the credentials. And we know that the server does make the connection, not the client, because I captured all the packets coming off my Android tablet running Outlook 3.0.46 (315) and absolutely none of them went to the configured IMAP and SMTP server, but quite a few went to Microsoft addresses. Even if their mail bastion acted like an HTTP CONNECT proxy, we would expect to see the TLS certificates from my servers, and I did not.

Likewise, when I sent mail to a third party, the first hop mailserver was mail.outlook.com, which had to authenticate to my mail server to send the mail through it. That's all in the SMTP headers for the recipient to review.

So, it's their server doing the connections, not the client tunneling through. And that means their server knows your passwords, even if only transiently.

  1. Does this mean that the intermediate server is able to read mail prior to pushing it to the client?

Yes, it does.

  1. Is this behaviour documented or known?

That's hard to say. Their bundled documentation doesn't clearly describe it that I saw, but there's a surprising amount of documentation there.

It is worth noting that there is a legitimate technical driver for this behavior - the various phone and wireless networks your device may move between may block access to mail services; it's sort of the sole area that ingress filtering ever took off. By forcing your communications through home base Microsoft, they can ensure that mail protocols aren't blocked at the source...

...whether that's worth it to you is another question.

Improve this answer
1
  • Thanks. I do understand the reason for this approach, but I'm surprised that they did not feel it necessary to inform users about the behaviour explicitly (e.g. when setting up an IMAP account). It is literally a man-in-the-middle exploit, possible only because they are a trusted vendor and have control of the client software. It's a shame, I liked the outlook UI.
    – user97661
    Commented Apr 29, 2019 at 21:57
-1

Its always been the case for android clients. Microsoft are yet to fully address the issue completely. hopefully in the coming months tls 1.2 will be the standard and android will have to rev up its os to support it.

Improve this answer
1
  • 1
    in what way would TLS 1.2 change the practice of initiating the connection from an intermediate server rather than the phone client?
    – user97661
    Commented Apr 28, 2019 at 21:54

You must log in to answer this question.