SafeLinks: Annoying or Harmful?

Sommaire

My organization has deployed SafeLinks, and as a computer scientist, the solution bugs me for conceptual and practical reasons. I’m also preparing a new course on defense against cyberattacks, so it is a good teaser for future students :)

Safelinks is a feature offered by Microsoft Defender. It scans and rewrites URLs in emails (as well as Teams and other Microsoft apps) to prevent malicious links used in phishing and other scams.

SafeLinks protects the recipients of organizations by scanning/rewriting URLs in emails they receive. The aim is to prevent human users from clicking malicious (phishing) links and compromising their accounts by transmitting credentials to scammers or executing malware.

SafeLinks differs from classical spam filtering. Filtering is often done at email reception by the email server, whereas SafeLinks validates the URL when the human user clicks on it. Both approaches seek to be complementary.

Unfortunately, SafeLinks has conceptual and technical defects: they make some emails unreadable, they disrupt the integrity of messages; they obfuscate URLs; they break the secrecy of correspondence; they leak personal information; they stealthily track users; they operate in a black box; and they are a single point of failure. Some of these issues can be mitigated by the organization (by setting better local policies), some others by the receiver (to suffer less), or by the sender (who knows their emails can reach unfortunate Office 365 users). The best course of action is to fix the SafeLinks design (or use better solutions from other vendors).

For the context, electronic mail (email) is a complex beast. But, this complexity is manageable as the basic design of email is analogous to postal mail, except it is on the Internet. Most principles and expectations of postal mail also apply to email (or should).

Basically, when an email (for instance, from Alice that works at ExampleCommercial alice@example.com) reaches an Office 365 email recipient (for instance, Bob, a member of ExampleOrganization bob@example.org), then URLs in Alice’s email are rewritten to protect Bob (per policies of ExampleOrganization).

Organizations can use preset security policies (that activate SafeLinks by default) or set up specific local policies and rules for users, groups of users, senders, URLs, etc. Microsoft can also add, change, and remove options and offer various service plans, so your mileage may vary.

For example, the email Alice sent to Bob is

From: Alice <alice@example.com>
To: Bob <bob@example.org>
Subject: Check that website!

https://example.net/funny-kittens/

Bob receives the following:

From: Alice <alice@example.com>
To: Bob <bob@example.org>
Subject: Check that website!

https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%example.net%2Ffunny-kittens%2F&data=05%7C02%7Cbob%40example.org%7Cbebb8fc1cc3b4c6fa61208dd8d7e4df6%7C12cb4e2a42da491d90e17a7a9753506f%7C0%7C0%7C638822295653699921%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=4CV%2BlVQE9XKQkz5sSMxv2xfhTrFzeJMYs2si19Xxht5%3D&reserved=0

SafeLinks rewrite the URL to point to a Microsoft server (can01.safelinks.protection.outlook.com). When Bob clicks on it, the Microsoft server checks that the original URL is safe; if so, Bob is automatically and transparently redirected to the original URL. If the URL is considered unsafe, then the Microsoft server presents a warning page and does not redirect.

To my knowledge, there is no independent evaluation on the usefulness or efficiency of SafeLinks. But fighting cybercrime, phishing, and malware is a noble task. Therefore, I won’t argue against the goal or the effectiveness of SafeLinks.

Plain Text Emails Are Unreadable

Emails can be in plain text (without formatting or color) or in HTML (formatting, fonts, colors, images, and many other things), or both (or some less-used forms). In HTML, a link is usually a text (classically blue and underlined) that holds a link target attribute (a URL). The URL does not appear in the text but is used when the user clicks (or touches or activates) the linked text. It is classic HTML with the a element and a href attribute, nothing fancy here.

With HTML emails, SafeLinks rewrite only the target URL, so Bob’s HTML emails look like the original ones. Except that, if Bob clicks on links, the target is the SafeLinks server. Bob can also check the link (mouse over, left click, etc.) and discover the long SafeLinks URL.

Most users use HTML emails because it is the default in many email applications (and allows colors and images), so SafeLinks are more or less transparent for most final users.

Unfortunately, many computer scientists, advanced users, and IT professionals prefer plain text emails because they are lighter, safer, more accessible, compatible with popular formatting text conventions like Markdown, easier to edit and read in text editors and terminals, easier to process, etc. Some of these people are also joyless and dislike images and colors.

When SafeLinks rewrite plain text emails that contain URLs, they become unreadable and restrict the transmission of information. The following screenshot is an example of a weekly report from a mailing list:

A screenshot of Outlook web full of mangled URLs

Message Integrity is Broken

Rewriting emails does direct harm. The received message is no longer the one that was sent.

Users expect that messages (including URLs) remain pristine. This is especially true in IT, education, and research, otherwise, it hinders technical and academic communication between researchers, professionals, educators, students, etc. Breaking message integrity also reduces the confidence of users against their own organization, or the organization of their correspondent.

While SafeLinks seeks transparency in its application, it still causes miscommunication, especially with plain text emails.

For instance, Alice can send the following helpful email:

From: Alice <alice@example.com>
To: Bob <bob@example.org>
Subject: Modernized apt sources

Hi Bob, for a modernized apt source, you can create a file
    /etc/apt/sources.list.d/debian.sources
with the following contents:

```
Types: deb deb-src
URIs: http://deb.debian.org/debian/
Suites: bookworm
Components: main non-free-firmware 
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
```

Adapt it to the suites you want.
Do not forget to remove the old /etc/apt/sources.list

Cheers, A.

Unfortunately, SafeLinks scrambles the message, making it wrong for Bob, and causing bugs and issues on Bob’s computer.

From: Alice <alice@example.com>
To: Bob <bob@example.org>
Subject: Modernized apt sources

Hi Bob, for a modernized apt source, you can create a file
    /etc/apt/sources.list.d/debian.sources
with the following contents:

```
Types: deb deb-src
URIs: https://can01.safelinks.protection.outlook.com/?url=http%3A%2F%deb.debian.org%2Fdebians%2F&data=05%7C02%7Cbob%40example.org%7Cbebb8fc1cc3b4c6fa61208dd8d7e4df6%7C12cb4e2a42da491d90e17a7a9753506f%7C0%7C0%7C638822295653699921%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=4CV%2BlVQE9XKQkz5sSMxv2xfhTrFzeJMYs2si19Xxht5%3D&reserved=0
Suites: bookworm
Components: main non-free-firmware 
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
```

Adapt it to the suites you want.
Do not forget to remove the old /etc/apt/sources.list

Cheers, A.

A real story was instructions given to a colleague by an editor. The email was about the preparation of a manuscript for publishing. But the LaTeX code in the email has URLs to external images and research artefacts, and thus was mangled and unusable. Round trips and a different communication system were used to solve the issue. Such misadventures make everyone lose time and reduce confidence in organisations to manage a usable IT infrastructure.

HTML emails are also impacted if the user right-clicks and copies the link. What will be put in the clipboard is the rewritten URL, not the original one. The sender did send a specific URL, but the recipient cannot simply copy it.

URL are Obfuscated

URLs are not only meant for computers. They are not an opaque agglomerate of random characters. They are expected to be readable by humans who know how to read them.

Advanced users and IT people are used to read URLs, understand what servers they are poking and click URL with due caution. The mangling of URLs done by SafeLinks makes these URLs unreadable by humans, thus less secure for advanced users.

Paradoxically, I would even go so far as to say that URLs obfuscation harms the fight against phishing. URLs are everywhere (in email, in the location bar, on paper…) and user education is one of the best instruments against cyberattacks. Therefore, it is a common recommendation of serious phishing trainings to look at the domain of links. URL obfuscation prevents users from practicing finding malicious links and applying the current recommendations.

Email Search is Broken

Nowadays, emails are so prevalent that the only way to deal with them is to have access to an efficient search feature.

But because URLs are rewritten, searching for them in your emails will return nothing.

Secrecy of Correspondence is Violated

Disclaimer: I’m not a lawyer.

In some democratic jurisdictions, secrecy of correspondence is a legal principle that guarantees that the content of sealed letters is never revealed, nor tampered with. This naturally extends to electronic mail.

There is no such specific guarantee in the USA, so big American companies like Microsoft are not very reluctant to inspect emails for their own usage or to alter them for various reasons. For instance, it was reported that Bing (the Microsoft web search engine) can visit links present in emails managed by Microsoft servers.

While SafeLinks’ goals are good, the technical design does tamper with the correspondence. And in this specific case, I think that this tampering is unreasonable.

Personal Information is not Protected

For an unclear reason, the email of the original recipient is embedded in the SafeLinks URLs.

Remember the email about kittens (alleged funny) that Bob received from Alice? Here it is.

From: Alice <alice@example.com>
To: Bob <bob@example.org>
Subject: Check that website!

https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%example.net%2Ffunny-kittens%2F&data=05%7C02%7Cbob%40example.org%7Cbebb8fc1cc3b4c6fa61208dd8d7e4df6%7C12cb4e2a42da491d90e17a7a9753506f%7C0%7C0%7C638822295653699921%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=4CV%2BlVQE9XKQkz5sSMxv2xfhTrFzeJMYs2si19Xxht5%3D&reserved=0

We can try to decipher the mangled URL.

  • https is the scheme. Here, it’s a webpage with secure communication (quite standard!)
  • can01.safelinks.protection.outlook.com is the server. Here it is a Microsoft server (possibly serving a region in Cadada)
  • url=https%3A%2F%example.net%2Ffunny-kittens%2F is a part of the query. It indicates to SafeLinks the original URL to check (and redirect to if everything is OK). The %3A and %2F are URL encoding for the characters : and/. Because these characters have a special meaning in URLs.
  • data=05%7C02%7Cbob%40example.org%7Cbebb8fc1cc3b4c6fa61208dd8d7e4df6%7C12cb4e2a42da491d90e17a7a9753506f%7C0%7C0%7C638822295653699921%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C is another URL encoded information. When decoded, it reads data=05|02|bob@example.org|bebb8fc1cc3b4c6fa61208dd8d7e4df6|12cb4e2a42da491d90e17a7a9753506f|0|0|638822295653699921|Unknown|TWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ==|40000|||. We can see a bunch of other information. Among them, there is the receiver email: bob@example.org. The other information has no clear meaning for us, but should be meaningful for Microsoft.

Why the email of Bob is there? The email is not required to check the safety of any URL — and all the other data is also suspicious, but we deal with them in the next subsection.

Whatever the reason, now Bob’s email is part of the content of the email from Alice. In HTML emails, this information is not even visible in the text of the email, so the user is unaware of any potential leak of personal information. When an HTML email from Alice, with rewritten URLs, is forwarded by Bob to a third party, Carol, the information of the original receiver (Bob) is therefore still embedded and hidden in the email that Carol receives.

Imagine that Carol wants to transfer the email to a fourth party, Dan, but needs to remove any reference to Alice and Bob’s names and emails. She can redact the text of the email before forwarding it to Dan. But she unknowingly leaks the email of Bob to Dan, as it remains embedded in the target of any of the links in the message.

Another situation is copy-pasting. Bob receives an email with links, and wants to share some of the content of the email on a social media platform under a pseudonym. So, he copies, pastes, and then publishes. What he does not know is that the copy-pasted message contains links that expose his personal or professional email address.

As the last example, Bob copies and pastes some email content into a Word document. His email address is leaked when the final document is shared or made public (even if the document is converted to PDF).

These are fun stories about Alice, Bob, and the gang, but the same kind of personal information leaks can happen in real scenarios involving confidential topics, vulnerable people, harassment, sources of journalism, clients of attorneys, political oppression, etc.

Emails are considered personal information that is protected by legal frameworks (like in the European Union) they also often correspond to the name of the person, which is also personal information. The management of personal information always requires special due care.

Users are Tracked

The long SafeLinks URLs also contain opaque information used for user tracking. Microsoft and the recipient’s organization know if and when the email recipients click on links.

In HTML emails, this information is hidden, so the user is not aware of any tracking. If the email is replied-to-all, forwarded, or copy-pasted, the tracking information is also propagated to correspondents that might not belong to the organization or even use Office 365.

Exclusiveness and Black Box

SafeLinks gives Microsoft the task of validating URLs. The details of the validation process are secret. A malicious URL might be validated, and a legitimate URL might be blocked, without explanation.

So, some users might want to add another URL validation to complete the diagnostic of Microsoft servers. Unfortunately, using another link checker conflicts with SafeLinks since URLs are rewritten.

There is also a social aspect. Delegating phishing prevention to SafeLinks creates a false sense of organizational security. It doesn’t raise awareness, the problem is centralized without addressing the fundamental issues.

Single Failure Point

If the Microsoft servers go down or are unreachable, rewritten links will stop working.

Attachments

Safe Attachments is a related feature that can scan, filter, or defer attachments in emails.

Scanning to classify as spam or malware is standard (good) practice. The impact on the secrecy of correspondence is considered acceptable as long as filtering is done correctly. The email can be identified as genuine and accepted in the inbox, identified as probable malware and put in a spam mailbox (quarantined), bounced and returned to the sender with an error message, tagged for future processing, or just dropped by the server.

Detaching attachments and altering the email content cause some of the same issues with SafeLinks, since this rewrites the original email body.

Replacing an attachment with a placeholder (called Dynamic Delivery by Microsoft) is used to alleviate the delay caused by an extensive scanning of attachments. This also alters the message body and might have nasty side effects if such an email is replied to or forwarded.

I did not extensively test or investigate the Safe Attachments feature. Maybe for a future update.

Workarounds

Okay, SafeLinks is far from perfect, but I’m just a simple user — or a simple IT administrator. What can I do about it?

Organization IT

See Safe Links policy settings documentation.

  • Disable SafeLinks rewriting;
  • Disable user tracking;
  • Petition Microsoft to do SafeLinks right (see below), or use another vendor.

Recipients

Once the email reaches the inbox, rewriting is already performed. The only solution is thus to reverse the rewriting when retrieving or displaying the emails.

  • Add-on for Thunderbird that removes SafeLinks in the emails (that includes reply and forward)
  • UserScript (*Monkey) for popular browsers that remove SafeLinks in the Microsoft webmail (unfortunately, that does not include reply and forward, the script needs to be improved).
  • Python script for other use-cases and tools, like mutt.
  • Petition your IT administrators.

Senders

The documentation states that some emails are not modified. This is the case for s/mime emails. After some experimentation, PGP-signed emails are also kept unmodified.

Email signatures (with s/mime or pgp) are used for end-to-end guarantee that the sender is cryptographically identified, and that the email is not altered. Not all email clients have the feature to sign or check signatures (the webmail of Office 365 does not). Some other clients require a third-party plug-in. However, when signed, SafeLinks cannot alter the email without invalidating the signature, so choose not to do it.

Emails can also be encrypted so that only the legitimate user can read them. Unlike an email signature (that the receiver’s email client can ignore), the receiver’s email client needs to be able to decrypt the email to display it. In this case, SafeLinks cannot even read the email body and detect URLs.

Note: end-to-end encryption prevents any email filtering or spam detection. But it is an expected trade-off.

The only way to do SafeLinks right is to not alter the original message body. This simple trick alleviates all the issues of SafeLinks identified in this blog post.

But my security?

URL validation can be done (non-exclusively):

  • At email reception on the recipient’s server side. What most email servers already do for spam filtering. And what SafeLinks does when URL rewriting is disabled.
  • At email retrieval by the recipient for just-in-time filtering. It makes sense in the case of a new phishing campaign since the malicious intention of the URL might not be detected when the email is received by the server, but is discovered after some analysis and user reports.
  • By the email client (and webmail). The email client could check links or redirect them to a link validator: rewriting the email body was never required for that feature. It is especially true for Microsoft that controls its own groupware suite and provides official webmail, desktop client, and mobile apps. Note: This is exactly what Google does for link protection with its GMail webmail and apps.

Also, if you want to implement a link validator (or improve your own):

  • do not expose user emails (duh!);
  • do not track users.

This section gives a basic overview of some technical concepts on email infrastructure.

What About Spam/Scam/Junk/Email Filtering?

Spam designates unsolicited emails. Spam includes marketing communication, badly configured mailing lists, or any unwanted email from annoying (or hostile) people. It also includes scams (like phishing) and malware. While more nefarious, they are still considered unsolicited email.

Classical spam filtering (inbound filtering) occurs when an email reaches the recipient’s email server. It prevents unsolicited emails from filling the user’s inbox by dropping them, moving them to a spam folder, etc. Additional (more complex or up-to-date) filtering can also be done after the arrival by the recipient’s email server, until the email is retrieved by the email client of the user.

Outbound filtering occurs when an email is sent and reaches the first email server (the server of the sender’s organization). It prevents spam from starting its journey across email servers, prevents the sender server from losing reputation by originating spam, and enables the sender organization to act on the malicious or compromised user.

Additional spam filtering can be done on the user side by the email client. For instance, in Thunderbird or in GMail clients.

What about IMAP, POP, and SMTP?

Those are standard protocols used by email clients to connect to email servers and retrieve (IMAP/POP for inbound servers) or send (SMTP for outbound servers) emails. SMTP is also the protocol used between two email servers to transmit emails.

Proprietary or custom protocols can also be used when the clients and servers are tightly integrated or belong to the same organization, like the Microsoft Outlook desktop application and the Microsoft Office 365 servers.

What about MUA, MTA, and others M*A ?

MUA is a mail/message user agent. It is the software used by humans to send, receive, and manage emails. E.g., Thunderbird, the desktop Outlook application, or a mobile app. I (heretically) use the term email client in the blog post.

MSA, MTA, and MUA are the software used by IT infrastructure, Internet providers, or companies that offer email services (Microsoft, Google, Yahoo, ProtonMail, etc.) I (heretically) use the term email server for all of these. Orthodoxically: MSA is a mail/message submission agent. It is an inbound server that receives email from MUA and sends it to one of its local MTA. MTA is a mail/message transport agent. It accepts emails from MSA and other MTA and transfers them to a MTA or MDA of the recipient. MDA is a mail/message delivery agent. It is an outbound server that accepts emails from a MTA, and stores them. The recipient’s MUA can connect to the MDA to retrieve and read the emails.

Webmails are a special kind of MUA that are web applications offered by email providers. E.g., gmail.com, outlook.com, or the weird and antiquated website used by some Internet providers. Webmails are accessed by web browsers and can be tightly integrated with the MDA.

What about SSL and TLS?

The SSL/TLS protocols (and the STARTTLS SMTP command) are used for encrypting and securing communication between an email client and an email server or between two email servers. They seek to prevent communications from being listened to or altered and servers from being impersonated. It is not an end-to-end encryption as each server needs to manipulate the emails and their metadata.

What about password, OAuth, SSO, and MFA?

Those deal with how a human user (or an email client) authenticates and connects to an inbound server to retrieve emails (POP/IMAP), an outbound server to send emails (SMTP), or a webmail.

What about SPF, DKIM, and DMARK?

Those are SMTP protocol extensions to improve trust between two email servers (it is an executive summary; the specific details are quite technical and out of scope). Note: they impact email deliverability and spam filtering, as untrusted emails might be more likely to be dropped or quarantined.

What about email encryption and signature?

Email encryption and email signatures are end-to-end features. Email encryption seeks the guarantee that only the legitimate recipient can read the email. An email signature seeks the guarantee that the sender is legitimate and that the message remains unaltered.

My humble opinion is that these features are not as widely used as they should be. Mainly because the two current main approaches S/MIME and PGP are complex to set up. Because some email clients fail to handle them. For instance, Outlook webmail ignores email signatures (but with a warning) and cannot display encrypted email. The user can still download email parts and then decrypt emails by themselves. Because nowadays it is hard to find free S/MIME certificate providers, and key signing parties are less popular (they were not that popular before either).

As stated above, signed (and/or encrypted) emails prevent SafeLinks rewriting.