Mount an iPhone inside a KVM guest by disabling usbmuxd

Today I wanted to mount an iPhone inside a KVM-based VM. My host is Ubuntu 15.04, the guest is Windows XP. Well, it didn’t quite work at first because the host kept stealing back the phone’s USB connection. The culprit was usbmuxd, a “USB multiplexing daemon” that handles communications with iOS devices and Linux. To temporarily overwrite its behavior I added an empty udev rules file:

$ sudo touch /etc/udev/rules.d/39-usbmuxd.rules

This rule file (which does nothing) takes precedence over the original rules in /lib/udev/rules.d, with the result that it would no longer trigger the usbmuxd daemon whenever an iPhone is detected on the USB host.

Reload udev with:

$ sudo udevadm control --reload-rules

And now, it’s time to run the TaiG Jailbreak.

Google Domains invites up for grabs

I have five invites for Google Domains available. The first five users to reply to this post will get one (make sure to enter a valid e-mail or I won’t be able to send it to you).

Keep in mind Google Domains is currently only availble for users in the US; your location is determined by the billing address for the credit card you use with Google Wallet to purchase or transfer a domain.

Enabling ATA Security on a Self-Encrypting SSD

Recently I purchased a Samsung 840 Pro SSD for my frayed old notebook (a Thinkpad X200s). It’s a self-encrypting drive where data is always stored with AES-256 encryption. But first, to benefit from the encryption, I needed to encrypt the underlying encryption keys. One way of doing that is to set an ATA user password for the drive, which is supported by the BIOS of most notebooks.

But there is a problem.

Continue reading

Optimize AES and ChaCha20 usage with BoringSSL

BoringSSL is a Google fork of OpenSSL. It includes various interesting patches, including an implementation of the ChaCha20 cipher. In addition, BoringSSL allows you to group cipher suites of equal preference:

Equal preference cipher groups. This change implements equal-preference groups of cipher suites. This allows, for example, a server to prefer one of AES-GCM or ChaCha20 ciphers, but to allow the client to pick which one. When coupled with clients that will boost AES-GCM in their preferences when AES-NI is present, this allows us to use AES-GCM when the hardware exists and ChaCha20 otherwise.

Source

In this article I show you how you can tweak your nginx configuration to take advantage of this feature.

Continue reading

OpenSSL with ChaCha20-Poly1305 support

Update: Meanwhile you could also switch to the BoringSSL fork.

D. J. Bernstein’s ChaCha20-Poly1305 has not been merged into the OpenSSL master branch yet (ETA, anyone?). If you are curious to test it with nginx or any other application relying on the OpenSSL libraries with support for TLS 1.2, you can check it out via the 1.0.2-aead branch:

$ git clone https://github.com/openssl/openssl.git
$ cd openssl
$ git checkout 1.0.2-aead

Then follow the usual instruction from the INSTALL file on how to compile OpenSSL.

IPSec Fail: Perfect Forward Secrecy, Where Art Thou?

Perfect Forward Secrecy (PFS) has garnered widespread publicity in recent months thanks to Snowden and the NSA. As a result, an increasing number of websites and email service providers have been pushing for PFS to provide better security to their users.

PFS protects previous key exchanges even if the current one is compromised.

Unfortunately the same cannot be said about current popular IPSec VPN clients. Neither of the ones I tested – all of them from recent distributions including Windows and OS X – offered PFS out of the box, meaning previous IPSec key exchanges could be decrypted by an attacker if the current one is compromised.

NSOC-2012

Continue reading

Despite Heartbleed bug: certification revocation refused (Updated)

Note: [04/14/14] Today I was contacted by GlobalSign representative Gregory who stumbled over this blog post, and he was so kind to revoke the affected certs free of charge. He also added, in response to my summary below, that there is an option in the Chrome settings to enable revocation checking, and that beginning April 1, 2015, GlobalSign will restrict the maximum validity of then-issued certs to 39 months.

So the Heartbleed bug (CVE-2014-0160) is out, and every administrator using SSL to protect his infrastructure has been wondering the same thing: should I absolutely, positively, without a doubt, replace all certificates and associates keys?

The only reasonable answer is: yes – if you used certificates on a vulnerable machine. Even those in disbelief were quickly proven wrong.

The first thing I did was to patch all impacted OpenSSL instances and restart the services that depend on the OpenSSL library (that includes not only HTTP but also MTA and IMAP, among others). That was the easy part.

What followed was a major pain with my certificate authority and one of its partners.

Heartbleed

Continue reading