“J'ai rencontré Dieu dans un solarium / Il était là, il mangeait une pomme”
… and I do think it’s particularly tough for engineers:
I’m lucky enough to work at a company, where most folks are not complete morons. It’s sometimes slightly worse with our business partners though. Anyhow, I can feel for that guy.
Stumbled upon through a fb-post by DerKalle.
So the NDR (a branch of Germany’s public broadcasting service ARD) got to interview Edward Snowden — exclusive stuff apparently. And whom do they send to talk to him? Some nitwit called Hubert Seipel, whose English sounds like a combination of the Simpsons’ Rainier Wolfcastle and Bond-villain Maximilian Largo.
I don’t know much about that man’s eligibility otherwise, but just trying to listen to the first 3 minutes of the interview made me grind my teeth. Harsh stuff. Seriously.
Would I do better myself? Hell no! But neither would I dare to take upon me such a task. Doesn’t the ARD have any qualified staff at all? What am I paying my mandatory fees for, anyway?
Ranting about superficial bullshit aside, I hear the actual contents of the interview are rather disappointing themselves. Well, I guess I’ll have to bite the bullet and watch the whole interview, if I want to find out for myself…
I’m more and more becoming a fan of Dan Savage. He’s one of these guys, who constantly manage to point out the nuisance of religion, without being a total dick about it.
That may be, because instead of just weighing in on abstract, philosophical questions, he actually does something good for society. He’s an LGBT activist and initiator of the It Gets Better Project, an organization that helps prevent suicide among young people with “non-traditional” sexuality. Also, he is the guy who brought us Santorum.
Last night, Dan Savage was on Bill Maher’s show, and the two were talking about the recent legalization of gay marriage in Hawaii:
Maher:
Their catholic bishop there […] says something about how children who are […] adopted by gay parents have a greater chance of committing suicide. That must be bullshit, right?Savage:
That’s total bullshit. He’s confusing children with gay parents, with children who where raped by catholic priests.Maher:
Savage:
Sorry, I’m just done being lectured about children and their safety by catholic fucking bishops, priests, cardinals, …[…]
Savage:
I hate to always go there, but they don’t have moral high-ground when they talk about the welfare and safety of children. They just don’t! They have squandered that on the tips of their dicks.
Beim neuen Lesekompetenztest für Erwachsene der Titanic scheinen Tschechen ja eindeutig im Vorteil zu sein. Trotzdem würde man der OECD gerne auch auf Deutsch sagen: “Steck dir den Finger durch den Hals”, und was auch immer “grmpf” bedeutet.
The following has been said by Rowan Atkinson over a year ago. It is concerned with specific piece of legislation over in Britain, but its approach to freedom of speech is a far more general one:
Just in case anyone wonders about the piece from Not the Nine O’Clock News that is mentioned: Constable Savage is also available on the web.
Just stumbled upon an old NY-Times article about good old Glockenbachviertel in Munich. The article is from 2006, and I must say that the foreign autor grasped the essence of this quarter quite well.
Of course, things have changed since back then. Cool places have moved away (X-cess) or even shut down completely (KuK). Others, like Trachtenvogel or Netzer, have been mutilated by bourgeois neighbors and consecutive municipal restrictions.
Moreover, the Glockenbachviertel has been over-run by hoards of zombie hipsters – and rich IT-folks like myself have been taking over the residential properties. There goes the neighborhood!
The OpenSSL library is utilized by a wide range of other open-source projects, like web-servers, mail-servers, VPN-servers, etc. When dealing with such software and SSL, it often proves useful to be familiar with the openssl command-line tools.
Of course, OpenSSL does have great man-pages, and a quick web-search reveals plenty of usage examples. However, OpenSSL is packed with features, and I often struggle to find just the information I need. Hence this cheat-sheet of openssl calls that I personally find useful…
Once you have a certificate file (e.g. downloaded from a HTTPS website or created with the commands described below) you’ll likely want to check what it says. You can display it in human-friendly form and check its fingerprints with the following commands:
openssl x509 -noout -text -in meeque.crt openssl x509 -noout -fingerprint -sha1 -in meeque.crt openssl x509 -noout -fingerprint -md5 -in meeque.crt
This corresponds to the certificate information displayed by popular web-browsers, when you ask them to display details of an SSL-connection.
Likewise you can display the contents of a certificate-signing-request (CSR):
openssl req -noout -text -in meeque.csr
To obtain an SSL-Certificate you first need a certificate-signing-request (CSR), which you can then submit to a certification authority, like CAcert. Create a new CSR and a matching private-key like so:
openssl req -newkey rsa:4096 -keyout meeque.key.enc -out meeque.csr
By default, this command asks for all the information you want to include into the certificate along the way. (E.g. it asks for stuff like domain-name or distinguished-name, orgaisation-name, etc.)
It also asks for a passphrase to protect the private-key with. You can later remove such a passphrase with the following command:
openssl rsa -in meeque.key.enc -out meeque.key
(Depending on one’s security needs, this can be useful, since it facilitates server-restarts without user-interaction. However, keep non-encrypted private-keys extra safe!)
When you need a certificate for test-purposes only, you probably don’t want to involve a certification authority. Instead, you want to sign the certificate yourself. Based on above CSR and private-key it works like this:
openssl x509 -req -days 365 -extensions v3_req -in meeque.csr -signkey meeque.key -out meeuqe.self.crt
One aspect, which cannot be handled on the command-line easily, is creation of a multi-domain certificate. More precisely the creation of a respective CSR. Here, you’ll need to create a custom OpenSSL configuration file, with an subjectAltName entry for all additional domains. Just start with one of the sample config-files, and add the following lines:
[ v3_req ] subjectAltName = DNS:meeque.de,DNS:meeque.org,DNS:foo.example.net
When creating your CSR, you pass your config-file to the command described above:
openssl req -config meeque.openssl.cnf -newkey rsa:4096 -keyout meeque.key.enc -out meeque.csr
Once certificates are in place, you might want to tweak other properties of your SSL connections, e.g. enable or disable certain ciphers. The OpenSSL library provides a rather peculiar cipher list format, which is also utilized in the config-files of various SSL-enabled servers. (E.g. Apache’s mod_ssl.) Luckily the openssl command helps you to test such cipher lists. The following command takes a textual cipher list, and tells you to which actual ciphers it resolves:
openssl ciphers '!ADH:!AECDH:!MD5:HIGH'
Which leaves us with my new personal favorite: the SSL client command that comes with OpenSSL. It lets you initiate an SSL connection to a given server and port, and dumps plenty of info regarding certificate validation, SSL-handshake, SSL-session, etc. Usage is as simple as this:
openssl s_client -connect meeque.de:443
OpenSSL is also used by the small SSLScan tool. It provides a quick way to check, which ciphers a given server supports:
sslscan --no-failed meeque.de:443
Tobi was mentioned here before, and now he’s just published his season-edit for 2012:
Check it out! You’ll be amazed how many sports he’s skilled at! Other folks don’t even have that kind of action on their X-Box. Of course Tobi’s been focusing on skiing for a long time. So check out that part (roughly last third of the video) for some more advanced shots!
Oh an just for completeness: here’s an older edit, which focuses on skiing only:
And here is, what his employer thinks about all that (in German).
Since my old notebook computer recently gave up on me, I had to install a new one from scratch. I finally decided to give Ubuntu a go, after I had been using Debian (testing) for almost a decade. I must say that I’m really impressed with Ubuntu’s lean installation process, which handles diverse aspects like live-preview, hardware-detection, pre-existing operating systems, partitioning, etc. in a very convenient manner.
However Ubuntu also seems to come with several annoyances and limitations. I plan to figure out solutions for most of these in the following days, but one thing struck me right in the beginning: disk encryption. Sure, Ubuntu comes with easy support for encrypted home directories, but for reasons listed below that’s not exactly what I need.
According to an article by the EFF, the latest (12.10) Ubuntu installer already comes with built-in support for full-disk-encryption. Apparently, this feature only works when you’re installing Ubuntu alone, on an otherwise empty physical disk. Sadly, I wasn’t offered this option when trying to install alongside an existing OS. (Or maybe I just overlooked the feature, which would make most of the information provided here rather less essential. However, this article is still useful as a starting point for more exotic installations and as a reference for trouble-shooting.)
Update: By now I have successfully tested Ubuntu’s built-in support for full-disk-encryption on a different computer. When installing on an empty disc (or completely replacing an existing OS installation) it works as expected. The outcome – in terms of partition, luks, and lvm setup – is very similar to the one presented here. Hence I can fully recommend it, if applicable to one’s pre-existing setup!
I partially use my computer for development work, and I like to toy around with system-wide settings. That’s why:
I used to have a setup that addressed all these requirements on my old Debian box. As far as I remember the Debian installer had offered a rather reasonable partitioning scheme with luks encryption and lvm volumes – though some manual interaction may have been needed. It is this kind of setup I was aiming to reproduce with Ubuntu.
So I first checked the encryption capabilities of the Ubuntu installer. The presets it offers are very convenient, but as mentioned above, support for full-disk encryption seems somewhat limited. Even the manual partitioning tool of the installer, only seems to provide very basic support for encryption. E.g. it offers dm_crypt, but does not have any (good) luks support.
So I had to abort the install, which got me back to the Ubuntu live-session. Being a GUI junkie, I first did some basic partitioning work (shrinking and moving old windows partitions) with gparted. Then I used the same to create the following 2 new partitions:
Next I used the CLI-tool cryptsetup to initialize an encrypted luks-container:
sudo cryptsetup luksFormat /dev/sda6 sudo luksOpen /dev/sda6 crypt1
The first command generates a new encryption-container on sda6 and asks for a passphrase to protect it. (Should be chosen wisely! However, luks also gives you the possibility to add or remove passphrases later.) The second command opens the new encryption-container (asking for the passphrase) and makes its contents available under /dev/mapper/crypt1.
Now, lvm comes into play:
sudo pvcreate /dev/mapper/crypt1 sudo vgcreate system-volumes /dev/mapper/crypt1 sudo lvcreate --name swap --size 3G system-volumes sudo lvcreate --name root --extents 100%FREE system-volumes
This creates a new physical volume (pv) and a new volume group (vg) called system-volumes inside the encryption container. It then creates two logical volumes in this volume-group:
That’s basically it. Without exiting the Ubuntu live-session, I started the installer tool again, and did the rest of the work with its GUI. GParted didn’t seem to recognize the new logical volume devices, but the partitioning-tool of the installer did. So I formatted the new volumes, and mapped everything to the following mount-points:
I also chose to install Grub into the MBR of /dev/sda and continued installing Ubuntu.
The installation finished flawlessly – but the first boot into the new system did not. It did not ask to decrypt the encryption-container on sda6 and therefore could not find any root file-system to mount. Instead, the boot process fell back to a BusyBox shell, and I had to decrypt it manually. As above, the following command does the trick:
luksOpen /dev/sda6 crypt1 exit
The exit command terminates the shell and resumes the boot process, which will now find the root file-system and continue to boot. In my case, this lead me all the way to a working Ubuntu desktop.
Since I did not want to do this manually on each boot, a few more steps were necessary. After my Ubuntu system fully booted, I created the following entry in /etc/crypttab:
# <target> <source device> <key file> <options> crypt1 /dev/sda6 none luks
This tells the system about the encrypted disks that are available. And the boot process will try to open them, and see if they contain the root file-system. In order for this to actually take effect at boot time, I also reinstalled the linux kernel, the initrd, and grub. (In my case I did it in the course of pending system updates, but one could also trigger package reinstalls manually with apt-get or synaptic.) From there on, the Ubuntu boot process has always asked me for a passphrase to access my disk, and booted flawlessly. Yeah!
You might wonder, why one couldn’t adjust /etc/crypttab before or during the install? And, why a reinstall of the kernel is necessary? Well, maybe the first approach might work, but I didn’t test it. As for the kernel reinstall, it is not strictly necessary. The only thing that is strictly necessary is building a new initrd file, which will then contain its own copy of the above /etc/crypttab file. (I know there are other tools to achieve that, but a reinstall of the package seemed the easiest.)
But why is that necessary? And what is the initrd anyways? Well, you also might have been wondering how the boot process can access any configuration before the root file-system is mounted? Well, that’s where the initrd, the initial RAM disk, comes in: it contains all the files that are necessary for the boot-process, before the actual root file-system is available. That may be stuff like kernel-modules, low-level user-space tools (e.g. cryptsetup, lvm, BusyBox, etc.) and basic configuration files (e.g. fstab and crypttab). That’s why it is not sufficient to adjust the /etc/crypttab file in the actual root file-system. It is the /etc/crypttab inside the initrd that is relevant at boot-time!
After so much configuration hassle related to luks/cryptsetup, what about the layer above? What about lvm? Well, as you might have guessed by now, there is no further configuration necessary here. The lvm subsystem heavily relies on meta-data stored in the pvs, vgs, and lvs themselves. Apparently, the lvm kernel module together with the lvm user-land tools (from the initrd) automatically recognize the physical-volume /dev/mapper/crypt1 once it is created by cryptsetup. And lvm makes all the included logical-volumes available automatically, in particular the one containing the root file-system. Also, the installer already added a suitable entry for / in /etc/fstab. So this part of the problem seems to solve itself under Ubuntu.
Oh, one more thing: As you may have noticed, this approach leaves a couple of weaknesses open. In particular, the /boot partition itself is not encrypted. Neither is the grub code in the MBR. Or the partition table. This does not impose a huge problem, since those don’t usually contain any data that needs protection.
However, someone could tamper with them, when you leave your computer unattended! This might enable an eavesdropper to sniff your password. So when in doubt, you should probably re-install the /boot partition and the MBR! However, when someone has access to your computer, they might aswell tamper with the hardware. So I don’t consider this weakness overly relevant.
Just watching axelarnbak‘s 29C3 talk on Certificate Authority Collapse, which covers structural flaws in SSL. I’ve reported on the mess with SSL before, and you may notice related complications (see CAcert) while browsing this page.
After a good summary, the talk mainly focuses on structural problems and regulatory solution approaches. But apparently there are other talks at the 29C3, which focus on the technical side of the problem…
