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.

Maybe they're just not that into you?
A decade of blogging

Related Posts

TLS certificates and CAA records

Transport Layer Security (TLS) is what gives you the little padlock in your browser bar. Some people still call it SSL, but TLS has been around for 18 years –  it’s time to move on.
TLS provides two things. One is encryption of traffic as it goes across the wire, the other is a cryptographic proof that you’re talking to the domain you think you’re talking to.
The second bit is important, as if you can’t prove you’re talking to, for example, your bank you could really be talking to a malicious third party who has convinced your browser to talk to their server instead of your bank which makes the encryption of the traffic much less useful. They could even act as a man-in-the-middle and pass your traffic through to your bank, so that you wouldn’t notice anything wrong.

When your browser connects to a website over TLS it, as part of setting up the connection, fetches a “TLS certificate” from the server. That certificate includes the hostname of the server, so the browser can be sure that it’s talking to the server it thinks it is.
How does the browser know to trust the certificate, though? There’s not really a great way to do that, yet. There’s a protocol called DANE that stores information in DNS to validate the certificate, much the same as we do with DKIM. It’s a promising approach, but not widely supported.
What we have today are “Certificate Authorities” (CAs). These are companies that will confirm that you own a domain, issue you a certificate for that domain where they vouch for it’s authenticity (and usually charge you for the privilege). Anyone can set themselves up as a CA (really – it’s pretty trivial, and you can download scripts to do the hard stuff), but web browsers keep a list of “trusted” CAs, and only certificates from those authorities count. Checking my mac, I see 169 trusted root certificate authorities in the pre-installed list. Many of those root certificates “cross-sign” with other certificate authorities, so the actual number of companies who are trusted to issue TLS Certificates is much, much higher.
If any of those trusted CAs issue a certificate for your domain name to someone, they can pretend to be you, secure connection padlock and all.
Some of those trusted CAs are trustworthy, honest and competent. Others aren’t. If a CA is persistently, provably dishonest enough then they may, eventually, be removed from the list of trusted Certificate Authorities, as StartCom and WoSign were last year. More often, they don’t: Trustwave, MCS Holdings/CNNIC, ANSSI, National Informatics Center of India (who are currently operating a large spam operation, so …).
In 2011 attackers compromised a Dutch CA, DigiNotar, and issued themselves TLS Certificates for over 500 high-profile domains – Skype, Mozilla, Microsoft, Gmail, … – and used them as part of man-in-the-middle attacks to compromise hundreds of thousands of users in Iran. Coverage at the time blamed it on “DigiNotar’s shocking ineptness“.
In 2015 Symantec/Thawte issued 30,000 certificates without authorization of the domain owners, and even when they issued extended validation (“green bar”) certificates for “google.com” they weren’t removed from the trusted list.
So many CAs are incompetent, many are dishonest, and any of them can issue a certificate for your domain. Even if you choose to use a competent, reputable CA – something that’s not trivial in itself – that doesn’t stop an attacker getting certificates for your domain from somewhere else.
This is where CAA DNS records come in. They’re really simple and easy to explain, with no fancy crypto needed to set them up. If I publish this DNS record …

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

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