Mandatory TLS is coming

Well, not exactly mandatory but Chrome will start labeling any text or email form field on a non-TLS page as “NOT SECURE”.

Chrome 62 will be released as stable some time around October 24th. If you want to avoid the customer support overhead then, regardless of whether any of the information on a form is sensitive, you should probably make sure that all your forms are accessible via TLS and redirect any attempt to access them over plain http to https. You can do that globally for a whole site pretty easily, and there’s not really any downside to doing so.
I still have half a dozen sites I need to convert to supporting TLS – the cobbler’s children have no shoes – and I’m beginning to feel a little urgency about it.
There’s more information in Google’s announcement, their checklist of how to set up TLS, and some background at Kaspersky Labs.

Related Posts

Comodo, TLS certificates and business ethics

We run a lot of our own infrastructure at Word to the Wise. Our email and web presence runs on our own hardware, in our own cabinet in our own network space. Partly that’s because we’re all from very technical backgrounds, and can run them in a way that’s better suited to our needs than an off-the-shelf web service. Partly it’s so we can do things like add instrumentation to our inbound mail stream so we have easy access to information when diagnosing a customer’s delivery issues. But it’s also partly so we can keep up to date on protocols and software, and leaven our advice to clients with some first hand, real world experience.
One of those things is TLS certificates, for webservers and email servers.
We already used Comodo for code-signing certificates, so when their sales rep called me and offered some decent pricing of extended validation (EV or “green bar”) certificates in exchange for a three-year commitment that seemed like a good opportunity to experience the extended validation process.
I’ve written previously about how painful the process of getting a TLS certificate from a legacy certification authority such as Comodo is, but this post isn’t about that.
I mentioned a few months ago that our green bar TLS certificate would be going away. That was because Comodo didn’t honor their agreement with us. While we ordered three years of EV certificate from Comodo, paid them for three years of EV certificate and confirmed in writing with the sales rep that they would provide three years of EV certificate, after one year Comodo decided that they wouldn’t honor that agreement.
The sales rep was mysteriously “no longer with the company” and his sales manager decided that they’d keep the money, but not provide the agreed to certificates. After a dozen or so promised calls back or email replies from a “sales manager” to discuss “what they could do for us” didn’t happen, we gave up on Comodo and switched to using Lets Encrypt for our TLS certificates.
We’re very, very happy with Let’s Encrypt. The price of “free” is nice, but it’s the simplicity, reliability and general lack of having to deal with horrible sales reps that’s the best thing.
Apparently a lot of other Comodo customers thought the same thing, as Comodo seems to want to recapture those customers by pretending to be Let’s Encrypt.  They filed trademark registrations for “Let’s Encrypt”, “Comodo Let’s Encrypt” and “Let’s Encrypt with Comodo”. Comodo is in the business of “trust” and “identity” and I can’t think of any behaviour of theirs more antithetical to that.
And, on an email note, Comodo also seemed to decide that they didn’t want their employees to know about this, nor to answer questions about it, and reportedly configured their email filters to reject email mentioning letsencrypt.org with “mail contains a virus”.
steipete_2016-Jun-23
— from Peter Stenberger, on twitter
(Given Comodo are a major email filter vendor I hope that that’s just a local configuration used by Comodo themselves, not part of their public filtering products.)
We will no longer be using or recommending Comodo as a vendor.
(This post brought to you as an exercise in avoiding the question “What effect will brexit have on the email industry?”, as the answer “Global economic collapse would probably be bad for the email industry, yes.” seems a little simplistic.)

Read More

Cryptography and Email

A decade or so ago it was fairly rare for cryptography and email technology to intersect – there was S/MIME (which I’ve seen described as having “more implementations than users”) and PGP, which was mostly known for adding inscrutable blocks of text to mail and for some interesting political fallout, but not much else.
pgp
That’s changing, though. Authentication and privacy have been the focus of much of the development around email for the past few years, and cryptography, specifically public-key cryptography, is the tool of choice.
DKIM uses public-key cryptography to let the author (or their ESP, or anyone else) attach their identity to the message in a way that’s almost impossible to forge. That lets the recipient make informed decisions about whether to deliver the email or not.
DKIM relies on DNS to distribute it’s public keys, so if you can interfere with DNS, you can compromise DKIM. More than that, if you can compromise DNS you can break many security processes – interfering with DNS is an early part of many attacks. DNSSEC (Domain Name System Security Extensions) lets you be more confident that the results you get back from a DNS query are valid. It’s all based on public-key cryptography. It’s taken a long time to deploy, but is gaining steam.
TLS has escaped from the web, and is used in several places in email. For end users it protects their email (and their passwords) as they send mail via their smarthost or fetch it from their IMAP server. More recently, though, it’s begun to be used “opportunistically” to protect mail as it travels between servers – more than half of the mail gmail sees is protected in transit. Again, public-key cryptography. Perhaps you don’t care about the privacy of the mail you’re sending, but the recipient ISP may. Google already give better search ranking for web pages served over TLS – I wouldn’t be surprised if they started to give preferential treatment to email delivered via TLS.
The IETF is beginning to discuss end-to-end encryption of mail, to protect mail against interception and traffic analysis. I’m not sure exactly where it’s going to end up, but I’m sure the end product will be cobbled together using, yes, public-key cryptography. There are existing approaches that work, such as S/MIME and PGP, but they’re fairly user-hostile. Attempts to package them in a more user-friendly manner have mostly failed so far, sometimes spectacularly. (Hushmail sacrificed end-to-end security for user convenience, while Lavabit had similar problems and poor legal advice).
Not directly email-related, but after the flurry of ESP client account breaches a lot of people got very interested in two-factor authentication for their users. TOTP (Time-Based One-Time Passwords) – as implemented by SecureID and Google Authenticator, amongst many others – is the most commonly used method. It’s based on public-key cryptography. (And it’s reasonably easy to integrate into services you offer).
Lots of the other internet infrastructure you’re relying on (BGP, syn cookies, VPNs, IPsec, https, anything where the manual mentions “certificate” or “key” …) rely on cryptography to work reliably. Knowing a little about how cryptography works can help you understand all of this infrastructure and avoid problems with it. If you’re already a cryptography ninja none of this will be a surprise – but if you’re not, I’m going to try and explain some of the concepts tomorrow.

Read More

Protocol-relative URLs in email

When you link to an external resource – an image, a javascript file, some css style – from a web page you do so with a URL, usually something like “https://example.com/blahblah.css” or “http://example.com/blahblah.css”.
The world is beginning to go all https, all the time, but until recently good practice was to make a web page available via both http and https.
The problem is that if you try and load a resource from an http URL from a page that was loaded via https it’ll complain about it, and not load the resource.
And if your users web browser is loading the http version of your page because it’s Internet Explorer 6 and doesn’t speak modern SSL then it’ll be unable to load anything over https, including any of your resources.
So whether you choose https or http protocol for loading your page resources it’s going to break for someone.
One common trick to avoid the problem is to use a protocol-relative URL. That looks like “//example.com/blahblah.css”, and it’ll load the resource over the same protocol that the page was loaded over.
While we can safely use “https://…” everywhere now, “//…” URLs are still a common idiom for things like loading things like CSS libraries from public content-distribution networks as well as your own resources.
I was reading long-but-excellent writeup about Stack Overflow’s migration to TLS (hey, I read this sort of stuff for fun) and they point out something I hadn’t considered – mail clients don’t really have any sensible way to use protocol-relative URLs. The mail client loaded the “page” from a mailbox and so has no base document protocol to work from (even if there’s a <base> element in the content it’s not likely to affect a mail client). If the user is reading it via webmail or a mail client that’s using an embedded web browser to render HTML it might work, sometimes, but it’s not going to reliably load that resource in general.
So, if you’re copy-pasting content from your web collateral to reuse in an email, make sure you’re not loading anything external – including images – via a “//…” style URL. Rewrite them to use “https://…”.
 

Read More