Jan-Piet Mens

Upon connecting to an untrusted SSL resource, the device will inform me that the SSL certificate which is automatically sent by the server is untrusted. For example when synchronizing the device with my SyncML server over an HTTPS URL, my Nokia N70 reports an untrusted SSL certificate at each connection.

I don't want to have to confirm the trust at each connection, so I set about to get my Certificate Authority's root certificate into the phone.

Knowing a bit about the topic, I imagined the Series 60 phone would prefer a DER-formatted certificate to a PEM-formatted one, so I converted by PEM certificate (often stored as a .crt or .pem file) into a DER format (often such files are named .der, or in the Microsoft world, .cer). I guessed it would be .cer, and it turned out my hunch was correct.

The conversion is simple if access to the OpenSSL tool chain is available:

$ openssl x509 -in jpmensca.crt -out jpmensca.cer -outform DER

This file I then transmitted via BlueTooth to the mobile device. Your mileage will vary here of course, but from my Windows notebook I used file transfer to do it. I simply dropped the jpmensca.cer file onto the OBEX file transfer folder. My device told me I had a message waiting for me,

and I then opened the message to find a message from the BlueTooth stack containing the attachment jpmens.cer file. As soon as it is opened, the mobile phone recognizes that it is a certificate and offers to import it.

After acknowledging that the new certificate might be insecure, I saved anyway and gave it a label with which to later identify it, then specifying the trust options for the certificate:

The certificate is then saved in the phone's certificate store.

To later view details of the certificate, revoke trust, or even delete the certificate, I use the security settings utility to access Certificate management which lists all the trusted certificates, and I can open mine of course.

Now I can connect to an HTTPS resource which is protected by SSL/TLS certificates I have issued myself.

sendspace is a service which allows you to send large files to a correspondent. Since email is always limited in size (some servers allow mails no larger than a few hundred KB), sendspace comes in handy. After selecting the file to upload and a bit of patience,

the file is uploaded via HTTP and you get a URL which you post to your correspondent, who in turn uses the URL to download what you sent.

There are a number of such services on the Internet, but this one just worked, and it doesn't require registration.

The Mozilla Firefox Add-ons site offers half a myriad of extensions with which Firefox can be altered to offer functionality that I consider useful.

I don't use many extensions, but those that I do use I love:

• whatmon helps me keep an eye on my servers


• del.icio.us (finally updated to be Firefox 2.0 compatible) is a neat and clean interface to del.icio.us bookmarks


• QuickProxy allows me to simply click proxy use on or off. I don't use this often, but when I do, it is a timesaver


• When not at home, I use Sage for reading RSS feeds


• coComment keeps track of where I leave which tracks

whatmon heads the list not only because I wrote it, but because it is most useful to me.

Jeffrey Zeldman has an amusing Web 2.0 Thinking Game going with a huge number of quite amusing comments on the comparison between Web 1.0 and 2.0:

Web 1.0: Social drinking
Web 2.0: Social bookmarking
...
Web 1.0: Webmail 2mb storage
Web 2.0: Webmail 2gb storage

Whenever I draw a diagram of the Internet connected via a firewall to a corporate network, I draw the Internet on the left and the corporate LAN on the right of the firewall. I've always pictured the Internet on the left, although many people do it in reverse.

Is there a correct or standard way of drawing such diagrams? Where do you put your Internet?

The news that Serbia & Montenegro now have their own top-level country domain names (rs and me respectively), opens up a load of new possibilities for amusing domain names: perl.re, kiss.me, etc.

This book fully covers the ground in securing a Linux system. Hardening Linux by James Turnbull (who also authored Pro Nagios 2.0) packs all you need to know about getting a Linux system secured into a single five-hundred page volume.

Turnbull takes the reader in a fast-paced but very comprehensive fashion through the arduous tasks of closing up the open holes in a Red-Hat or Debian – based Linux distribution, and he covers all major topics which include unlikely candidates such as the virtual terminals on the console, immutable files and capabilities, system logging, rootkits, and penetration detection and recovery.

After reading up on the basics which include users & passwords, Pluggable Authentication Modules (PAM), and information on hardening the Linux kernel and the boot loaders, the reader gets an excellent introduction to firewalling with iptables with a whole firewall script for a bastion host in the appendix. That is followed by a full chapter devoted to securing connections with SSL/TLS and remote administration with ssh.

Chapter four is dedicated to securing files and file systems, and includes a section on encrypted file systems to safekeep your data, as well as a walk-through Tripwire. That is followed by a comprehensive look at logging with syslog and syslog-ng, and this chapter includes a discussion and tools related to log analysis and correlation.

NMAP, Nessus and network sniffers make up the bulk of the security testing tools with which Turnbull rightly suggests we check our work after having hardened the basic system. These are covered on fourty pages.

Although Mr. Turnbull recommends Postfix, he covers both that and Sendmail, carefully noting that he doesn't want to contribute to the "my mail server is better than yours" wars. On over fifty pages, the two mail transport agents (MTA) are given careful consideration as to making them as secure as possible. In a further chapter aptly titled Authenticating and Securing Your Mail, the author covers SSL/TLS certificate generation with OpenSSL as well as SMTP authentication (SMTP AUTH) with Cyrus SASL, for both flavors of mail server.

As far as access to mail is concerned, the Cyrus IMAP server is well documented in chapter nine, and the last two chapters guide the reader through securing FTP servers as well as the BIND name server.

Every person responsible for installing a Linux server must read this book! There is of course also detailed information to be gathered from dedicated books which cover the individual subsystems (such as those for DNS & BIND, OpenSSH, etc.), but I strongly encourage every system administrator to have a copy of this excellent book on his or her desk.

I just stumbled accross one of many free image and file hosting services, this one being called keepmyfile.com and was curious enough to read the FAQ in which they describe their server configuration (emphasis mine):

1x:
Dell PE750 (P4 2,8Ghz HT)
1GB DDR Memory
1×250 GB SATA HD

Come again? One single twohundredandfiftygig harddisk? It is going to be difficult to fulfill the fourty-day promise they have…

Well, what do I always say? You get what you pay for.