Category: Security

When your web browser visits a secure website, the experience is seamless. Many in-home appliances also have web servers built in. If you were to point your browser to a WiFi-enabled lightbulb running its own web server at https://192.168.1.123, the browser would most likely give you a big scary warning.

What to do? This writeup explains most of the technical details of how plex did it. I think it’s a fascinating read. There are at least a couple of CAs that offer services to make this possible.

https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users

“… they partnered with Digicert to issue a wildcard certificate for *.HASH.plex.direct to each user…”

“the client, instead of connecting to http://1.2.3.4:32400, connects to https://1-2-3-4.625d406a00ac415b978ddb368c0d1289.plex.direct:32400 which resolves to the same IP, but with a domain name that matches the certificate that the server (and only that server, because of the hash) holds.”

I recently learned of Chrome’s intent to remove public key pinning, and replace it with the new, draft, Expect-CT HTTP header. Ultimately, it should give us a safer web.

Chris Palmer explains:

To defend against certificate misissuance, web developers should use the Expect-CT header, including its reporting function.

Expect-CT is safer than HPKP due to the flexibility it gives site operators to recover from any configuration errors, and due to the built-in support offered by a number of CAs. Site operators can generally deploy Expect-CT on a domain without needing to take any additional steps when obtaining certificates for the domain. Even if the CT log ecosystem substantially changes during the validity period of the certificate, site operators can provide updated SCTs in the form of OCSP responses (if their CA supports it) or via a TLS extension (if they wish for greater control). The combination of these mitigations substantially reduces the risk of DoS (either accidental or hostile) via Expect-CT deployment. By combining Expect-CT with active monitoring for relevant domains, which a growing number of CAs and third-parties now provide, site operators can proactively detect misissuance in a way that HPKP does not achieve, while also reducing the risk of misconfiguration and avoiding the risk of hostile pinning.

CSO Online reports that The National Institute of Standards and Technology’s (NIST’s) draft guidelines change some long-established best-practices — practices that have been ineffective for many years.

Changes include:

• Remove periodic password change requirements
• Drop the algorithmic complexity song and dance
• Require screening of new passwords against lists of commonly used or compromised passwords

Elaborating further:

The reality is that passwords are weak no matter how often they are changed or how difficult they are, and people usually have only a variant of one or two passwords. Man in the middle or man in the browser hacks can take your password even if it is extremely lengthy and complicated – IT administrators can see your passwords, your bank can see your passwords,” [Eric Avigdor] said.

He said the guidelines recognize that the way to solve the password problem is to accept that passwords are weak and add on other complementary factors of authentication, whether mobile or hardware OTP tokens as well as PKI based USB tokens or smart cards.

It’s been several years since I used GPG to PGP-sign and encrypt and to verify the authenticity of PGP-signed email messages.

So it was interesting to read why the PGP trust model doesn’t improve security:

http://arstechnica.com/security/2016/12/op-ed-im-giving-up-on-pgp/

I believe that confidentiality isn’t a binary thing — if one desires it, one must continually stay up-to-date on what approaches work and what is economically feasible, and what is no longer effective.

The article recommends Signal or WhatsApp for instant messaging, Magic Wormhold or OnionShare for file sharing, etc. It also recommends the use of Yubikey 4 for authentication.

I was glad to come up to speed with what has been happening with TLS in the last couple of years, and I highly recommend reading these articles.

• https://lwn.net/Articles/663875/
• https://lwn.net/Articles/664385/

I learned about HTTP Public Key Pinning, Certificate Transparency, and STARTTLS stripping, among other things.

Here’s one of many good quotes:

The core problem of the TLS certificate system is that there exist hundreds of certificate authorities. And unless extra protection measures are in place, each of those can create valid certificates for any domain. Therefore the whole system is only as strong as the weakest of all certificate authorities.

And as for embedded devices that handle encryption:

We are well aware that crypto appears to be something that needs to be field replaceable, and yet we more or less have no clue how to do that in deployed embedded hardware. Indeed, we seem to have a very poor idea in general on how to maintain the software on field deployed embedded hardware. — Perry Metzger

As I’ve worked with Python, I realize that it’s one thing to implement TLS, and another thing to verify server certificates. The Python requests library can be configured to do the right thing, but the python SMTP cannot. It’s still another thing to check on certificate revocation. Python doesn’t implement OCSP or CRLs, and those mechanisms are problematic anyway. It doesn’t yet implement HTTP Public Key Pinning. The state of affairs may not be much better in other programming toolboxes.

So I’d guess that machine to machine internet communication is probably more vulnerable to man in the middle attacks than consumer web browsers.