I really like eCryptfs, an encrypted file system supported in kernel able to encrypt right on top of the already supported file systems. No kernel-user-kernel-user swapping required. I like the selective ability of encrypting individual files and I especially like the interchangeable key structure.
While eCryptfs sounds great, there are a few downsides of stacked file system encryption.

eCryptfs is a POSIX-compliant enterprise-class stacked cryptographic filesystem for Linux that is…

Here is a directory where I checked out some code, and I don’t want this to get updated or changed in any way at all. I like it exactly like it is, and if someone messed with it, i’d like to know what’s changed. For this example, I use a fsvs repository so I can see the history and roll back to exactly the right version, but lets just say you want a one shot deal for a bunch of files… If something comes up and I think this has changed in any way, I can run another batch of md5sums and meld the results. (yum info meld, good utility)

So now I know this certificate is blessed by my client, I can try to use it to connect. But let’s say I try to use a self-signed certificate or another cert that’s not trusted… And using a self-signed certificate, you should see something like this… If it’s a trust issue, perhaps the certificate is valid, but it just can’t find the CA or intermediate certificate… But, if everythings working correctly, your client should connect just fine. And it will look something like this, with a big fat Verify return code: 0 (ok) at the end.

I’m going to test on a remote machine that I have a shell on, so lets see how many processors it has. I wonder how many connections it can handle with its current 1024 bit certificate. You could test by retrieving a file accessible from the encrypted web server if you wanted (to see how many requests for something specific that the server can handle for example) I’ll try this from a different machine.

If you submit an SSL certificate request for your Apache/Lighttpd web server to a Certificate Authority (CA) on a Windows Domain Controller, you might have to convert your resulting binary DER formatted Security Certificate into PEM so Apache or Lighttpd can understand it.

I read in a bunch of places that you can’t use HTTP["scheme"] to redirect http:80 traffic to https:443 without using 2-3 levels of nesting with socket and host. But that’s just not true. The only reason it doesn’t work at first is because http is a subset of https, so be more specific with http$ and it works with just one line in lighttpd.conf.

Now edit the lighttpd.conf configuration file to enable ssl. Use the public facing interface’s IP address instead of mine, unless yours happens to be 192.168.1.2 too! And nmap or netstat will let you know it’s listening on port 443

Enabling LDAP authentication should take you about 2 minutes, unless you type with just 2 fingers. Then maybe 3 or 4. …If you don’t allow anonymous connections to your ldap, give it a user/password combination that has enough privs to do the lookups, or just use your master account if you’re just testing or don’t really care. … Now tell it what parts of your webserver you want to protect and how. You can specify any string you’d like for the realm. Here I require an LDAP user account name and password just to get to the wiki main page, and only admin can see the server-config page… Restart lighttpd and you’re done.

I just saw a recent article describing some simple ssh attacks that looked a little funny to me. So I figured I’ll test them out. The one that smelled funny was using local and remote port forwarding on itself, localhost. It just doesn’t work on modern linux …