Subscribe Now

* You will receive the latest news and updates on the Canadian IT marketplace.

Trending News

Blog Post

Opportunities for incremental improvement

Opportunities for incremental improvement 

In the 1990s, email traversed the Internet in the clear, making it easy to intercept. Providers implemented client-to-server TLS to protect user credentials. In 2002, RFC 3207 added an opportunistic TLS layer to SMTP. According to Google’s Transparency Report, in the year ended July 2016, 85 per cent of email from Gmail to other providers, and 76 per cent of email from other providers to Gmail was protected in transit with TLS. Given Google’s high volume and wide visibility, it is safe to assume that more than three quarters of email is encrypted in transit.

Email remains relatively insecure. It is not protected at rest, creating an exposure at every server through which it flows. Issues such as weak DNS security make hijacking email to entire domains possible. The absence of meaningful authentication makes email trivial to spoof. But implementing TLS has, over time, significantly improved email security.

Lavabit was essentially forced out of business by US Government, but the protracted legal battle with the FBI demonstrated the value of encryption at rest. Lavabit’s solution of encrypting email upon receipt with an RSA public key and requiring the user’s credentials to decrypt the corresponding private key wasn’t perfect, but it provided more protection against at-rest snooping than any email provider offers today.

From a security perspective, the ideal email system includes mandatory automatic end-to-end encryption and authentication. One effort, the Dark Mail Alliance, was formed in October 2013, and published a draft specification in March 2015. Assuming the Dark Mail Alliance eventually creates a working reference implementation, gaining traction will require, at minimum, Windows, Linux, OS X, iOS, and Android client implementations. It will be difficult, if not impossible, to implement as in a webmail environment. Convincing users to transition from their familiar and beloved Gmail or will be an uphill battle.

Hopefully the Dark Mail Alliance will succeed, but a more evolutionary approach might have a greater chance of success. Major providers and vendors could agree to require TLS for all email transport starting January 1, 2017. Domain-level encryption and authentication could be performed on email servers. This would not require client changes, thereby facilitating rapid implementation.

The World Wide Web is another example. HTTP provides no meaningful confidentiality or integrity. The need for HTTPS was recognized decades ago for e-commerce and applications such as banking, but until a few years ago it was still common to see login credentials exposed on many other types of sites. Free certificates from Let’s Encrypt are having an impact, and some sites are moving exclusively to HTTPS.

DNS security issues, the potential for downgrade attacks against sites that support both HTTP and HTTPS, and the flawed certificate model underpinning HTTPS are problematic. Partial solutions such as certificate pinning and HTTP Strict Transport Security (HSTS) are making a positive impact. It’s far from perfect, yet it is significantly more difficult to intercept web sessions today as compared to ten years ago.

Major web server and browser vendors should drop HTTP support and implement certificate pinning. If Apple, Google, Microsoft, and Mozilla agreed to only support HTTPS in their browsers as of January 1, 2018, and implement certificate pinning, it would dramatically improve the state of Internet security.

When security is considered early in the design phase it is often possible to incorporate strong security controls at a reasonable cost. When trying to improve existing systems, it often makes sense to adopt an evolutionary approach and focus on opportunities for incremental improvement.

Have a security question you’d like answered in a future column? Email

Related posts