Browse

Tag: security

Halon’s year in review, looking back on 2021

Image by Ian Schneider

First of all, our industry has just celebrated a great anniversary. 2021 was the year that email turned 50 years! The MIT graduate Ray Tomlinson introduced the convention of the ‘@’ symbol to identify a message recipient on a remote computer system. In October 1971, he sent the first email. Today, 50 years later, email remains the most ubiquitous form of communication, and de-facto business communication medium. Email addresses are one of very few widely used, vendor-agnostic, independent addressing schemes, together with phone numbers of physical addresses. We believe that email aligns very well with the principal design of the open internet, and we don’t really see any viable alternatives around the corner. Improving email is at the very heart of everything we do. We’re continuously working hard to make email service providers all over the world more competitive, to avoid unhealthy domination by a few.

It’s also been another year with the pandemic lingering. While we have all been doing our best to enjoy our home offices, meeting each other whenever possible, and being safe, we must highlight how much we miss meeting up with our customers and other people in the email industry. We have been lucky to meet up with a few, but we cannot stress enough how much we’re looking forward to seeing everyone in person again. However, in terms of exchanging great ideas and knowledge within the email space, we’ve been happy to participate in several virtual and hybrid events such as it-sa, Black Hat, Cloud & Cyber Security Expo, Certezza, Inbox Expo, MailCon, Cloudfest, three M3AAWG meetings, and JPAAWG.

We have also had a busy year on the development side, with a focus on supporting DevOps processes, containers, and orchestration. This can improve both speed and reliability for service deployment, especially with larger teams. This effectively makes your email infrastructure more agile. A new plugin architecture that complements Halon script allows us and our customers to employ a greater level of componentization, made convenient through Visual Studio Code extensions and new package repositories. Developing in Halon script can be made more efficient with Docker Desktop templates, and debugging Halon script running within the MTA directly from Visual Studio Code by leveraging its breakpoint interface. Communication between components is designed to work with the dynamic scaling of orchestration tools, and we now provide Docker and Kubernetes templates.

On top of that, we have released a plugin for BIMI verification. It does the heavy lifting for mailbox providers looking to show brand images in their users’ inboxes. We have also compiled Halon MTA for the ARM processor architecture, evaluating performance and feasibility to run on for example AWS Graviton.

When looking back at the year we also need to highlight our growth – and, what a year it has been in terms of welcoming new Halonites to the Halon team! We’re beyond happy to have been welcoming so many new, ambitious and knowledgeable talents. It feels fantastic to be growing and to see just how much we can accomplish together.

These are just some of the things we have been up to in 2021 and we are very happy to call this another successful year. Now, we are beyond excited for the year ahead. It will be an eventful one with lots of things planned. Already now, we have lots of open positions in engineering, marketing, and sales. So, if you are interested in joining a fast-growing tech company, we would love to hear from you.

The past, present and future; TLS for email

Image by Michele M. F.

Let’s start our quick history lesson by setting the scene; Madonna was topping the charts and Kevin Mitnick had just been arrested after nearly three years on the run from the authorities. It’s February 1995 and researchers at Netscape had just released SSL version 2.0, much of the work was credited to Taher Elgamal, often referred to as the father of SSL. SSL version 1.0 was being worked on before that, but was never published.

Things didn’t start out great; SSL 2.0 was quickly discovered to contain a few bad flaws making it vulnerable to man-in-the-middle attacks, amongst other things. It was also impractical to implement especially for web hosting providers since it only supported a fixed domain certificate. SSL 3.0 addressed the issues found in SSL 2.0, and has been in use since 1996. It wasn’t until the discovery of the POODLE attack in 2014 that things started looking grim for SSL 3.0, which was subsequently deprecated in 2015.

TLS 1.0 is basically SSL 3.1, but the protocol was renamed as it was standardised by the IETF. It was first defined in 1999, and the result of a deal struck between Netscape, Microsoft and the IETF. Remember, this was in a time when the browser war between Netscape and Microsoft, and Microsoft had even introduced their own protocol derived from SSL 2.0 only supported in Internet Explorer and their web server IIS. The IETF wanted a standard, and that’s where TLS comes from.

From there on, it’s basically the same story all over again, but with more openness and collaboration. Each TLS version from 1.1 to 1.3 tightened up security, added features and removed old functions. TLS 1.0 and 1.1 were both deprecated in 2020, leaving us with TLS 1.2 and 1.3 as the only versions currently not deprecated.

Impact on email security

Alright, but how does this impact in-transit security for email? Let’s start by talking about SMTP. For server to server communication, opportunistic TLS is what happens in most of the cases. If one (or both) of the servers doesn’t support SSL/TLS the transaction continues unencrypted.

220 mx.halon.io ESMTP // Server introduces itself
EHLO halon.email      // Client sends extended hello
250-mx.halon.io       // Server replies with its capabilities
(cut)
250-STARTTLS          // Informing the client that SSL/TLS is available
(cut)
STARTTLS              // Client asks for the session to be encrypted
220 2.0.0 Ready to start TLS
(handshake and encrypted session)

This by design is vulnerable to man-in-the-middle via downgrade attacks. A malicious party on the line with the ability to modify traffic could very easily force the transaction to continue unencrypted by just dropping the 250-STARTTLS reply. And since there’s no straight forward way of verifying certificates as with HTTPS, it becomes a bit tricky to solve. Two solutions to this problem are DANE and MTA-STS. DANE relies on DNSSEC to establish trust, MTA-STS relies on CA issued certificates.

How to act and what to think about

What TLS protocol versions should you support, since you could argue that even the worst of encryption is better than nothing? Well, Google/Gmail supports TLS 1.2, but also the deprecated 1.0 and 1.1, for inbound and outbound SMTP. Microsoft/Outlook only support TLS 1.2 for both directions. Neither support the older SSL versions. Both will obviously send and receive emails in plain text, if the other party doesn’t support TLS (as is the norm today). To sum things up; make sure that you support TLS 1.2 or higher. Since Microsoft has disabled support for the deprecated TLS 1.0 and 1.1 protocols for server-to-server SMTP, you could probably too. By doing so however, there is a risk that traffic from and to older systems will be sent unencrypted.

More importantly, you should use DANE and/or MTA-STS for your inbound traffic, and validate both DANE and MTA-STS for your outbound traffic. Since these are two competing standards right now, supporting both is probably your best course of action. For sending outbound traffic, Microsoft does MTA-STS checks, whereas Google doesn’t according to our testing. Neither checks DANE, but Microsoft has announced that this will be implemented in December 2021, with inbound DANE coming in December 2022.

When it comes to end-user client communication there’s more protocols to consider in addition to SMTP; mainly IMAP, POP3 and HTTP (for webmail). This is slightly more straightforward, since the user have interactive control over what is happening. Because client connections are generally authenticated with a username and password, it’s a good idea to require TLS if at all possible. This can be done either via implicit TLS; that means running SMTP over port 465, IMAP over port 993 and POP3 (if you still use that) over port 995. The alternative is to use STARTTLS on the default ports, but then it’s important to configure the server software to require TLS to be started, if that’s your policy. Instruct your users to always take extra care to inspect the certificates in use; certificate warnings could be a strong indicator of someone interfering with your traffic.

Adding BIMI to your mailbox service to improve security and user experience

Image by Valimail

BIMI (Brand Indicators for Message Identification) is an emerging industry standard which attempts to drive adoption of strong email authentication, to help fight phishing, spoofing, and fraudulent emails by displaying verified brand images in the inbox. Several mailbox providers, including Gmail, AOL and Fastmail, are now live with BIMI. Are you looking to increase the security and experience for the users of your mailbox service by implementing this new standard as well? With Halon MTA, you’re ready to get started. Our BIMI module does the heavy lifting; verifying the indicators for inbound email and attaching the images to the email for display in the users’ inbox. Currently there are very few MUAs with BIMI support, but if you develop your own webmail or app the BIMI group has guidance for how to display the verified logo in your user interface.

What BIMI is, and how it works

In short, BIMI displays verified brand images in users’ inboxes, visible even before messages are opened. It builds upon the existing email authentication standards (SPF, DKIM and DMARC), and incentives email senders to embrace those technologies by increasing their brand impression. According to Agari, only 24% of Fortune 500 sending domains are authenticated. BIMI improves visibility and engagement for the brands, while at the same time increasing security for users. It roughly consists of the following steps;

  1. The brand sending the email first needs to implement email authentication (enforcing DMARC) for their domain name.
  2. The brand then creates an appropriate image of their trademarked logo, optionally applies for a Verified Mark Certificate (VMC), stores it on a HTTPS location, and points at it with a BIMI DNS record.
  3. When a BIMI-enabled mailbox service (like Gmail) receives an email from the brand to a specific recipient, the mailbox service’s MTA first verifies that the email is in fact from the sending brand using email authentication like DMARC.
  4. If the email is successfully authenticated, the mailbox service’s MTA checks if the sending brand’s domain has BIMI, and if so, verifies that logo against the VMC certificate authorities or using some other reputation system.
  5. If the brand’s BIMI logo was successfully verified, it is attached to the email (for example as a header), before the email is shipped off the recipient’s inbox.
  6. Finally, the recipient looks at her inbox using the mailbox service’s webmail or app, which displays the brand’s logo next to the address and subject in the email listing.
Getting started with BIMI validation on Halon MTA

Halon was the first commercial MTA to add support for many great new security standards such as DMARC, EdDSA DKIM (elliptic curve), DANE and MTA-STS. To our knowledge, we’re the first to add BIMI validation as well. Our BIMI validation module is only 182 lines of Halon script, which I think is pretty impressive (especially considering that it includes a basic ASN.1 parser). To get started with BIMI on Halon MTA, just check out the BIMI module to your configuration repository, add the following to your end-of-DATA script hook. The module uses some X.509 functions from the unreleased Halon MTA 5.8, please let us know if you want to try it out. As for showing the images in your webmail or app, we’re happy to provide guidance and examples.

import $calist from "bimi/ca.crt";
import { bimi, bimi_vmc } from "bimi/bimi.hsl";
import { dmarc } from "dmarc/dmarc.hsl";

$dmarc = dmarc($mail, $senderip, $senderhelo, $senderdomain);
$bimi = bimi($mail, $dmarc);

// Verified Mark Certificate (VMC)
if ($bimi["record"]["a"]) {
	$bimi_vmc = bimi_vmc($bimi, $calist);
	if ($bimi_vmc["indicator"]) {
		$mail->addHeader("BIMI-Indicator",
			str_strip(array_join(pcre_match_all(#/(^(.{0,49})|(.{0,64}))/, 
					$bimi_vmc["indicator"])[1], "\r\n ")),
			["encode" => false]);
	} else
		echo "BIMI VMC error: $bimi_vmc; $bimi";
} else {
	if ($bimi["error"] and $bimi["class"] != "dmarc" and $bimi["class"] != "dns")
		echo "BIMI error: $bimi";
}

Thank you for reading, and don’t hesitate to reach out if you want to learn more!

Not all successful DSN deploys are successful

Our latest release 5.5 adds support for the RFC 3461 DSN extension, and published a guide on how to get started. At first glance it may seem like a very nifty feature, and one may wonder why it’s not just enabled by default. Fact it, the DNS extension comes with a few peculiarities which need to be considered.

In many email environments, the receiver has multiple store-and-forward MTAs before the message reaches the recipient’s inbox. Each MTA in the path has a different purpose, and may reject the message (if it is spam, for example) rather than deliver it forward. This is what requires MTAs to send “failed” DSN notifications; when an MTA which isn’t your first (edge) rejects a message. The sender always has to be notified as per the transaction safety requirement of email.

One of the features provided by the DSN extension is that you may also request “delivered” notifications by the last MTA before the recipient’s inbox (or “relayed” notifications by the last MTA supporting the DSN extension). This lets the sender know when and if the message was delivered.

Thinking about it, this feature may be nice to have enabled in your MTA for outbound email. It would let you or your users know if and when a message is delivered; rather than only notifying you when and if delivery fails.

If you implement this feature for inbound traffic however, it would be one of your own MTA that would have to send those notifications out to anyone on the Internet that requested them. The notifications would go out from the last MTA in your inbound path. When messages are processed and routed internally, additional information that should not be visible to the sender are sometimes added. Allowing the sender to request a notification possibly containing some of this possibly sensitive information might not be ideal. This concern has be raised many times before, for example in the Exim documentation

Note: Supplying success-DSN messages has been criticised on privacy grounds; it can leak details of internal forwarding.

During our implementation and testing we enabled success notifications for some of our outbound traffic, to see which mailbox providers send such notifications. We were quite surprised to learn that Microsoft includes quite a lot of information regarding the recipients in their success notifications. We instantly reported this to the MSRC team but it was rejected as not being an issue 🙈

Amongst those hundred of lines of X-MS- headers you receive in their success notifications, I’m not sure if the last login time of the recipient is necessary. This is in fact the actual time when the recipient (eg. [email protected]) last checked their email:

X-MS-UserLastLogonTime: 10/1/2020 12:06:31 AM

Bottom line is; should you choose to implement this feature, make sure you do not add sensitive or unnecessary information to your success notifications that may expose your network internals or your customers’ personal information.

Using ARC to work around DMARC’s forwarder issues

Authenticated Received Chain (ARC) is a proposed standard that have been developed to help address issues with DMARC and certain forwarders, such as mailing lists. It defines a standard for how to pass authentication results from one intermediary to another, making this information available to the recipient system. It works even in the case of multiple intermediaries, a.k.a. a chain

DMARC verifies the sender authenticity, as specified by the RFC5322.From header domain name, using SPF and DKIM. Certain indirect email flows such as mailing lists break this by altering the message, while maintaining the original From header. It causes issues for both senders that publish a DMARC policy, and receivers that verify DMARC. The two large mailbox providers AOL and Yahoo published a p=reject DMARC policy for their domains in 2014, causing some disruption for senders on those domains. It occurred when emailing recipients on mailbox services that verifies DMARC via for example mailing lists. This was, and still is, remedied by ad-hoc solutions.

ARC in itself isn’t a reputation system. The specification doesn’t define how the reputation of intermediates should be tracked, nor how public lists should be operated. In other words, as a recipient mailbox provider you still have to operate such systems in order to make use of the information that ARC provides. DMARC.org announced ARC at a M3AAWG meeting in Atlanta, 2015, where it’s been a frequent topic ever since.

include "authentication.header";
include "authentication.arc";

$chain = ARC::chainValidate();
if ($chain["status"] == "pass" or $chain["status"] == "none")
{
	ARC::seal(
			"201805", "example.com", "pki:arc",
			$chain,
			AuthenticationResults()
				->SPF(["smtp.client-ip" => $senderip])
				->DKIM()
				->DMARC()
				->addMethod("arc", $chain["status"], ["header.oldest-pass" => $chain["oldestpass"] ?? "0"])
				->toString()
		);
}

 

We have just released an implementation for ARC (draft 14) on Github, which supports both verification and (re)sealing. It’s written in Halon script, and we’re using it on our own domain to start with. If you’re interested in taking it for a spin, just let us know.

We attend TES security roundtable in London

The very successful TES security roundtable meetings are continuing. This time it brings us to London, UK on May 24th.

The meeting will revolve around DMARC, DANE, email encryption techniques, password protection and SMTP transport protection. Vittorio Bertola, Head of Policy and Innovation at Open-Xchange has assemblied a great line-up. The meeting is an exclusive invite-only event for people working with email infrastructure issues.

Halon 4.6 “curry” with outbound anti-spam

You probably know from before that Halon’s scriptable SMTP server enable email providers to avoid blacklisting and increase deliverability. The 4.6 release, “curry”, contains Cyren’s outbound anti-spam (OAS). In combination with our cluster-synchronised rate limit function, it provides incredibly effective and accurate abuse prevention. Just like their Cyren’s inbound anti-spam, OAS uses a hash-sharing technology called recurrent pattern detection (RPD) that identifies outbreak patterns. It’s designed to detect spam from internal sources rather than external, and doesn’t report/contribute any signatures since it could blacklist your own infrastructure.

With the flexibility of scripting you can determine customer/sender identities accurately even in mixed traffic. This is used as identifier for rate limits based on classifiers such as Cyren’s OAS, delivery failure rate, queue size, etc. By using IP source hashing and alternative IPs for suspicious traffic, deferring obvious abuse and controlling connection concurrency, you can achieve high deliverability with minimal administration.

The 4.6 release comes with many additional features and improvements. It adds SNI support to the TLS functions. The Monaco-based code editor now have additional code completion, built-in documentation, tabs, and a mini-map.

For more information on the release, see the full changelog on GitHub. If you want to try Cyren’s outbound anti-spam, contact our sales team.

Anders Berggren speaker at Driving IT in Copenhagen

Driving IT, on November 3rd in Copenhagen, is a conference that gives a unique insight into the world’s constant changes in IT and development. The host IDA is The Danish Society of Engineers.

IDA Universe wants to strengthen knowledge exchange and personal and development for professionals who engage in technical and science subjects at a high academic level.

One way of doing this is the Driving IT conference, where Halon CTO Anders Berggren will be speaking. His topic is ”The state of email encryption”, addressing the fact that standards such as DANE and MTA-STS are becoming competitive differentiators. Are you in the Copenhagen area? Get your ticket!

Better spam protection in Mölndal municipality

Mölndals Stad (Mölndal municipality) has approximately 5000 employees and 10 000 students. In 2010 the IT department decided that 15 000 inboxes needed a new spam protection.

Anders Westerberg, now Head of IT Security in Mölndal, had built an open-source based solution that worked well. But for Annika Samuelsson, Head of IT development and maintenance, it was clear that they could not go on using a solution that only one person knew how to operate. Together with Anders she investigated possible replacements that could fulfill their wishes, and Halon caught their eye. The Halon software was then newly introduced to the market, and they saw an advantage in the company being open to a dialogue around how the product could be tailored to fit their needs.

The focus was of course on abiding by laws and regulations. Email sent to Mölndal municipality becomes public record and must be archived, even if it’s just spam. Stopping the email before it enters their system saves them that burden, and it’s also the procedure recommended by the organisation SKL (Municipalities and Country Councils of Sweden). Before implementing Halon, Annika and her team handled all spam quarantine, something that is now in the past. With the ”bulk” feature, an email manager will get a report on all blocked unsolicited email.

The result is very satisfying, says Annika Samuelsson

Introducing Halon was a quick process, and even though most of the work was done in-house they received some help from Halon support staff to do the fine tuning. Since becoming a customer, they have reached out a few times to address spam issues.

There have been incidents where we get spam that passes through the filter. But it’s always been very easy to get in touch with Halon and resolving the issues. Once it was actually as easy as a misunderstanding on which users that could report spam.

Mölndal municipality are subject to public procurement, and regularly has to compare their system to market competitors. But they have yet to find a product that solves their problems as effectively and smooth as Halon.

We feel very comfortable with what Halon provides us, and we would definitively 
recommend it to other governmental businesses.

Download case study (PDF).

Time-of-click protection against ransomware, malware and phishing

Time-of-click protection adds an extra layer of security to protect email users from accessing malicious content. Attacks including malware, ransomware and phishing are becoming more common and more sophisticated with every day, along with users keeping more sensitive information.

With an additional time-of-click protection, Halon will classify links in email every time it’s clicked, before allowing or denying the user to visit it. This means that if the scammer waits two minutes or two months with infecting the site, the user will still be protected when he or she chooses to click the link. It’s the extra layer of security that won’t allow you to visit infected websites by way of a link in an email protected by Halon.

Read more.