The Challenges of Privacy and Security by Design

My last blog post ended with:

Enter that other blog post.

More and more of infrastructure has migrated from in-house hardware to third-party providers. Hopefully that's not news to you. In the “old days” everyone maintained bare-metal servers in their office or in a data center.

Who hosts their own email servers anymore, well, besides ClearOPS? Or their source code repositories, again, besides ClearOPS? Or who won't take the plunge into trusting "other peoples' systems" with internal chat services, besides ClearOPS?

The answer is that it is a dwindling minority.

Even behemoths who claim to “own” the new privacy technology field such as OneTrust can't seem to find the resources to follow best practices and bring their email hosting in house from Outlook.com. If you’re in privacy and security, and controlling your own data isn’t a priority, I suspect you don’t like the field as much as you like the revenue.

Witness the onslaught of advertising technology people into some distorted version of privacy technology. Some of us realize that you just walked in, and the deluge of privacy regulations pushed you onto the opposing team.

Sorry, but eat your own dog food if you want to prove your worth and commitment especially when it comes to privacy technologies.

Initially ClearOPS did host its own web site with nginx, but the ability for less-technical staff (i.e., those who have no position in the vi versus Emacs debate) to whip out revisions quickly produced friction that we wanted to avoid. Therefore we opted for a third-party web hosting firm with Webflow, who we thoroughly vetted.

Basic brochure-style web sites are no longer the domain of the IT staff. An entity’s standard www.domain.tld web site now resides in the hands of the marketing people.

But this circles back to the previously mentioned problem: what happens when your service providers don't follow the basic standards?

Needless to say, that issue has caused much frustration for us on several points.

Note in our OPSReport on ClearOPS.io that there is a query for "Which versions of SSL/TLS does clearops.io allow for https connections?"

While Webflow fortunately doesn't allow ancient versions of TLS, they still don't offer TLSv1.3, which was first in an RFC in August 2018.

There's some online chatter about it, but it's hard to grasp why a firm almost exclusively focused on being a web site provider isn't keeping up with the standards in their somewhat narrow specialty.

I mean, come on, no Certification Authority Authorization record for their own domain? CAA records designate that only specific Certificate Authorities can provide the SSL/TLS certificate for a web site’s HTTPS encryption. There are few security-related standards more directed at web hosters than that CAA records.

More recently, we ran into another problem with Webflow about hosting basic text files with Webflow.

What is the relation between a text file and a web site? At its most basic an HTML file is text and nothing more. Tags in the actual text tell the web browser to render the text a certain size, set a particular background color, or insert some image.

The source of HTML will show this in bold:

<b>bold</b>

… which displays as this:

bold

When it comes to that functionality, we have been frustrated to no end.

Consider PGP, a tool over thirty years old for encrypting email content, among other functions. A private key is kept secret to create and decrypt email, for instance, while the public key is provided to anyone to encrypt email to the holder of that private key.

The simple part is that you provide your public key in a text file for anyone to use for that purpose. Hosting a public key provides some assurance that the public key offered is valid, especially considering the mess that public key management is with PGP. It's not in everyone's array of skills to use PGP unfortunately, but for those who can send PGP-encrypted emails, it matters.

We can't host our PGP keys on the web site in a text file.

Webflow won't allow “https://clearops.io/PGP-keys.txt” as their editing interface wants to turn it into an "asset" with some long URL. It's not an "asset." It's a damned text file.

Before there was Microsoft Word, WordPerfect or HTML, there was text. Text files will survive after any other format. Text files will out live the cockroaches that survive the nuclear apocalypse. Text files don't require any fancy interpreters and are quick and easy to read.

Then why not? Maybe because it’s hard to inject tracking pixels and irrelevant data-mining JavaScript bits into the page?

Standards evolve over time. There's a recent pending standard which calls for providing a "security.txt" file inside a .well-known directory. For example, on the ClearOPS web site, the path would be “https://clearops.io/.well-known/security.txt.”

Overall it's a worthy standard, in my humble opinion.

While it hasn't yet been formally adopted as an RFC yet, it's increasingly utilized by domains around the world.

The location of the PGP file, as mentioned above, can be referenced.

A web site's security policy can be referenced.

And contact information for reporting security issues is also provided.

But as I referenced in the previous post, it's a proposed standard that does include some non-sensical data, including a "Hiring" field.

It seems the human resources department have inserted themselves into IETF standards. What happens when this current technology bubble pops? Is the revised RFC going to include resumes of people seeking security work instead of incoming queries for hiring?

Security.txt has a funky web site, and was blogged about by Brian Krebs some four months ago.

But another text file, another series of frustrating sessions in the Webflow interface. Can't do, won't do.

The question is why? Users won't burn their fingers creating text files. Text files can’t hide horrendous binary viruses. They can't even generate bitcoins. Text files really can't do much of anything offensive, which is why a lot of us only read and send emails in ASCII text and not HTML.

And why shouldn’t we only use basic text formatting for email? Would you be more likely to click on a URL in an email formatted with HTML like this:

Large Software Manufacturer Class-Action Suit Payouts

… or email displayed as plain text that doesn’t obfuscate the actual content?

<https://3moum.page.link/Samsung_gift_juf8urhf7hhfd7yhd6erje8ijfjioijhvf867530954kanekejjiUEMLDKJ6UHGTYuhgtyuu8yghjhy7uhjkioi9ujhyu8ytrfgfrfvGFRYUJKIUHkd;woc9rjt876545jakeewp7>

This all begs the obvious question: why the public shaming?

We have queried Webflow's support, pinged the CEO on LinkedIn, and even worked through a former Webflow developer.

The results: chirp chirp.

Again, if there is one focus for an entity, that entity should "do things right" and standards are a key ingredient. A closer adherence to standards is the best mitigation against tomorrow’s known and unknown attacks. But we’re told chasing the new shiny object in security products is vital to enhancing the ecosystem.

Maybe it is time for the technical staff to take back web-site hosting. It might not be pleasing to the eye, but at least the site has a fighting chance at following the standards.

At some point, we’ll have to grapple with Substack’s TLS setup, which still allows those ancient versions of TLS.

George is a co-founder and CTO of ClearOPS. By trade, George is a systems administrator spawning from BSD Unix land, with long-time involvement in privacy-enhancing technologies. By nature, he thrives on creating unorthodox solutions to ordinary problems.

About ClearOPS: Do you have clients that ask you to respond to their security questionnaires? Are you thinking about a SOC2 to get rid of them? A SOC2 takes 6 months so what are you going to do in the meantime? You are going to use ClearOPS. ClearOPS now offers hosted security pages. Providing you with even more proof for your customers that you “take their privacy and security seriously.” Inquiries: [email protected]