When your web browser visits a secure website, the experience is seamless. Many in-hope 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.
“… they partnered with Digicert to issue a wildcard certificate for *.HASH.plex.direct to each user…”
“the client, instead of connecting to http://18.104.22.168: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.”
Install supporting software
sudo apt-add-repository ppa:yubico/stable
sudo apt-get update
sudo apt-get install scdaemon -y
sudo apt-get install python-setuptools python-crypto python-pyscard python-pyside pyside-tools libykpers-1-1 pcscd -y
sudo apt-get install yubioath-desktop yubikey-personalization yubikey-personalization-gui yubikey-manager -y
Insert Yubikey and Generate key
export and backup the public keys, because the Yubikey only stores the private portion of the key
gpg --armor --export $KEYID > mykey.pub
Require touching the Yubikey button to authenticate, sign, or encrypt:
ykman openpgp touch aut on
ykman openpgp touch sig on
ykman openpgp touch enc on
Change the pin
Change yubikey information
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.
- 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
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:
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.
LWN covers the new W3C spec for HTML subresource integrity (SRI):
SRI is designed to combat injection attacks that come through third-party content. The originating site can include cryptographic hashes of third-party script and image files, enabling the user’s browser to hash the corresponding files it receives from the third-party servers and verify that the hashes match.
Most browsers already support SRI, including Firefox, Chrome and Opera.
If you’re designing a service that requires passwords for authentication, store them using the Argon2 or bcrypt password hashing functions. Don’t use MD5, SHA-1, SHA-2 or SHA-3 — they’re not designed to keep passwords secure against attackers that gain access to your password database.
Reference article: How LinkedIn’s password sloppiness hurts us all by Jeremi M. Gosney
If [online services] aren’t using something like bcrypt or Argon2 for password storage, then they’re doing things very, very wrong. But slow hashing is no longer as effective of a solution as it could have once been had it only been adopted sooner.
When you suspect a password database has been compromised, even just in part, you cash in on that insurance policy [of using forced password resets] immediately by activating your incident response team and your public relations team.
What is Argon2? It’s the winning algorithm from the Password Hashing Competition. Argon2 has been added to recent versions of libsodium.
It’s useful to shorten long URLs, especially when sending them in tweets and in text messages. An LWN.net article helped me learn that they can be a security risk:
URL shorteners such as bit.ly and goo.gl perform a straightforward task: they turn long URLs into short ones, consisting of a domain name followed by a 5-, 6-, or 7-character token. This simple convenience feature turns out to have an unintended consequence. The tokens are so short that the entire set of URLs can be scanned by brute force. The actual, long URLs are thus effectively public and can be discovered by anyone with a little patience and a few machines at her disposal.
Around 7% of the OneDrive folders discovered in this fashion allow writing. This means that anyone who randomly scans bit.ly URLs will find thousands of unlocked OneDrive folders and can modify existing files in them or upload arbitrary content
— VITALY SHMATIKOV
Encrypting sensitive data-at-rest (i.e. in a database) is a good idea, but how does one manage the encryption keys, and rotate keys or start using a new algorithm down the road without orphaning or migrating the old data? Use KeyCzar
Cryptography is easy to get wrong. Developers can choose improper
cipher modes, use obsolete algorithms, compose primitives in an unsafe
manner, or fail to anticipate the need for key rotation. Keyczar
abstracts some of these details by choosing safe defaults,
automatically tagging outputs with key version information, and
providing a simple programming interface.
Keyczar is designed to be open, extensible, and cross-platform
compatible. It is not intended to replace existing cryptographic
libraries like OpenSSL, PyCrypto, or the Java JCE, and in fact is
built on these libraries.
Or learn from what Google did with KeyCzar, and implement the same ideas (key rotation and key version info) using a more modern encryption library, like libsodium.
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.
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.