Is carrying an iPhone worth the risk?

Update: It appears that Apple have resolved the issue with the September launch of IOS 7, essentially by implementing what I suggested below (highlighted):

Find my iphone
Yesterday I was robbed of my brand new iPhone (S/N: DNPGQ4RDDTDM IMEI: 013032008785006 ) for the second time, in public, in Paris. While I’m still a little shaken, angry and disappointed, I’m glad everyone survived unscathed… this time (last time I was assaulted in the process).

These less fortunate victims of crime lost their lives over iPhones, in the course of a robbery, in trying to retrieve the stolen device and as an innocent bystander respectively:

The latter story (around this time last year), in which a 68 year old woman was pushed down a flight of stairs in a Chicago subway station by the fleeing thief only to die later of head injuries, is almost identical to a robbery in Paris in which a young woman also died of head injuries only weeks prior:

Paris police data from that period showed that 53 percent of 1,071 violent thefts on Paris public transport involved smartphones, and the last two models of iPhones accounted for almost 28 percent of items stolen on public transport. The Interior Minister was at the time seeking faster efforts to allow smartphone owners to “block” stolen phones, disabling calling functions to make them worthless in the resale market as a deterrent to theft. “It will be naturally much less attractive” to steal a phone that can be de-activated remotely, he noted, adding that “we have the technical means to deter thieves”. And yet the grey market for iPhones is obviously still alive and well some 18 months later, in no small part because the parties with the capability to solve the problem (carriers, manufacturers, etc.) lack the interest (stolen phones drive new sales).

This brings me to the point of this post — finding a technical solution to solve the problem once and for all. Indeed, if a smartphone can be “bricked” then its resale value is severely limited. Most efforts today involve blacklisting the IMEI number such that the phone cannot be used on the networks in that country, but this usually takes time as it has to be done securely (typically by the operator from which it was purchased, and only after receiving a police report — too bad for those of us who purchase outright from a retailer!). A few days is long enough for the thief to sell the phone, only to have the buyer find it stop working some time later, thus creating another victim of crime (albeit someone guilty of receiving stolen goods, and in doing so driving demand!). Unless the database is global (which gives rise to other problems including distributed trust, denial of service, duplicated IMEIs, equipment limitations, etc.) then the thief can just sell it into another market, especially here in Europe, or swap it.

Enter Apple, who already have (and heavily advertise) the capability to securely locate, message and wipe the device (should it be able to reach the Internet — too bad if you’re roaming and have data disabled, and care about security and have auto join networks disabled, as I did!). Their trivial restore process (which makes iPhones extremely, and I would argue unnecessarily, transferable) also apparently involves a handshake with Apple servers, so who better to “brick” stolen devices by preventing them from being restored until returned? This would make it essentially impossible for anyone but the legitimate owner of the device to make use of it, thereby destroying the market and going from the most attractive to least attractive smartphone for thieves overnight. Sure you could argue that it’s not their problem, but unlike the police they have the capability (and I would argue the interest) to put an end to it once and for all.

I for one will be seriously reconsidering the cost vs benefit of carrying a device that others value more than my own life, and I’m sure that the benefit of a “Remote Disable” function in competitive advantage would outstrip the profit from replacement of stolen devices, so it’s not just about doing the right thing.

Update: Brian Katz points out that the thief need only enter the wrong PIN 10 times and then the iPhone will factory reset itself (depending on settings), no need for iTunes restore!

P.S. Here’s some advice on protecting your iPhone as well as some tips for avoiding pickpockets in Paris from TripAdvisor and the US Embassy.

Apple iPad to be Steve Jobs’ welcome back gift?

You may recall the Crystal Ball: Apple’s $599 “iPad Touch” Netbook (with pictures) article last year in which I mocked up the forthcoming Apple iPad. Although it turns out I wasn’t the first with this idea (further proof it’s got legs) I wasn’t the last either, with the Wall Street Journal claiming that “people privy to the company’s strategy say Apple is working on new iPhone models and a portable device that is smaller than its current laptop computers but bigger than the iPhone or iPod Touch” in Jobs Maintains Grip at Apple. Add to that the mysterious 10-inch touchscreen order and you arrive at something not too far from what you see above.

When will all this happen? Well Steve Jobs is due back in June, coincidentally the same time as the Worldwide Developer Conference (WWDC) 2009 which runs June 8-12 in San Francisco. In addition to Snow Leopard then it looks like us Mac junkies will have a[t least one] new toy to play with. This is great news even if only because while surfing the Internet on the iPhone is possible, it’s hardly pleasurable.

Crystal Ball: Apple’s $599 “iPad Touch” Netbook (with pictures)

They say a picture is worth a thousand words so how better to illustrate what I think an Apple “netbook” might look like than to design what I’d build if I were them. I’ve affectionately called it the “Apple iPad Touch” – not because it’s a particularly clever name but because it’s close to “iPod” and thus avoids having to create a new “iNote”, “iNet” or similar logo. There’s been renewed discussion (e.g. here, here, here, here, here, here, here, here, here, here, here and here) about such a device of late thanks to rumours that Chinese manufacturers Wintek and Quanta will make the screens and manufacture the devices respectively, and confirmation by Dow Jones Newswires via “two people close to the situation“.

The device would be bigger than an iPhone but smaller than a MacBook (actually it would be quite similar to the lid/screen of a MacBook on its own) and would be both light and durable. It may come with a protective case to protect its large, glass screen but these would definitely be available optionally and/or from third parties. It would stick with the aluminium/black glass theme, though given the appearance of the high density plastic backing for the iPhone 3G the temptation would be to make multi-coloured and/or special editions available, going back to the iBook clamshell roots.

The interface would be a breeze to use and the multitouch functions would be even more spectacular than when they first appeard on the iPhone. Thanks to advancements in the upcoming Safari 4, navigating to your faviourite sites would be as simple as clicking on a thumbnail in the new coverflow style speed dialer and the browsing experience will be similar to, but thanks to the extra power and pixels, much better than that of the iPhone. Multimedia (including video) will also be a pleasure to watch on its large high definition screen (but you’ll have to keep an eye on the battery) and finding what you want will be trivial thanks to CoverFlow:

Here’s the suggested specs:

  • ARM processor (1Ghz+)
  • 256-512Mb RAM
  • 32-64 Gb flash drive (ala iPhone, primarily for audio & video media)
  • iPhone-style stripped back Mac OS X operating system
  • 9-10″ Widescreen HD ~800×400 multi-touch screen (with LED backlighting)
  • Built-in microphone, speakers and webcam.
  • Battery replacement program (for a clean, catch free finish)
  • WiFi connectivity (802.11 b/g/n)
  • WiMax connectivity (maybe saved for 2nd gen release, 802.16e-2005?)
  • 3G service (potentially with carrier contract)

While it would have been nice to break the psychological barriers given the current economic climate by hitting the $499 price point, price at launch would be around $599.00/€499.00/£449.00, and while unlocked iPhone 3G’s sell around that today (in Australia they’re apparently around USD550), supply with or without a 3G carrier contract may affect the price.

Connectivity is key so it will support at least WiFi, but for “always connected” service 3G may be required. WiMax may also be an option in some regions to provide connectivity while side-stepping the mobile networks. Given good connectivity the iPhone’s dialer functionality may make an appearance too, but rather than holding the thing up to your head you’d have to go for a bluetooth headset, and similarly if you were bored with the onscreen keyboard then a bluetooth Apple Wireless Keyboard would be your only option. The charging cradle would sport the traditional iPod connector and a slot with a photo-frame style appendage for holding the device at an adjustable angle, facilitating the use of the keyboard and making the device a pleasure to use on the road (e.g. on trains/planes).

Although full-blown Mac OS X is pictured above, in reality a significantly reduced feature set would be available via an iPhone, Front Row and/or Cover Flow style interface running on something akin to Snow Leopard. This would be the main thing preventing cannibalisation of MacBook sales – the included AppStore wouldn’t include mainstream apps like iWork and Microsoft Office. Basic functionality would be provided via a suite of cloud computing tools like iWork.com but the absence of a keyboard would be another limiting factor. Similarly a lot of the media management would depend on a more traditional device (like the iPhone and Apple TV), but that doesn’t really matter since most of the content would be accessed over the Internet (at least when a high speed connection is available). Make no mistake – being a “netbook” this will largely be a single-purpose device, for watching YouTube videos, interacting with friends on Facebook, reading news feeds and so on. Nobody said netbooks had to be small or cheap but instant-on, constant connectivity is a must.

I for one would line up for this device (well, I’d submit an online order anyway) and if I were Steve Jobs I’d make its release my “I’m Back!” message.

Update: There’s evidence of new devices in the iPhone 3.0 OS images including the iProd and iFPGA. The iProd is likely a personal trainer device, though my initial reaction was a touch interface ala the tablet above. The iFPGA on the other hand is certainly referring to a different type of chip than the usual ASICs that can be programmed at the hardware level to function differently – this could well be a new architecture for the new devices.

2010 Update: With the announcement scheduled for tomorrow I thought I’d update this post to refine my predictions based on what we’ve discovered in the interim (it’s getting harder and harder for Apple to run a tight ship with secret product development – thanks to patent and trademark leaks, suppliers, and just plain old guesswork).

  • The device will be like a blown up iPhone and most importantly will run the iPhone OS (a derivative of OS X) rather than some skinned version of Snow Leopard.
  • It may be smaller than anticipated, but it will have a high quality screen like that of the Nexus One – possibly 7″ @ 1280×720 (for HD video content).
  • It will cost ~€499 in Europe with a mobile contract like T-Mobile’s Complete L (€899 without), and that contract may well include voice, text, etc. in addition to data. Contrast to the Amazon Kindle which provides free albeit limited service for store purchases, subscriptions and soon, 3rd party applications.
  • It won’t be immediately available, rather it will ship February/March (possibly March 1st).
  • Not much will be said about the specifications (as is the case for iPhone) but they will be quickly discovered and likely in line with what I suggested above – except perhaps for a bump in solid state storage for video.
  • Apple tend not to mix messages so there will be a lot of focus on specific use cases. Figuring this to be young/middle-aged professionals with discretionary spending even in a tough economic environment I’m thinking education and entertainment. Books. Magazines. Newspapers. Games. Movies. Music.
  • Expect a lot of the content to be subscription based, though given 3G is the weak link for delivery of HD video the focus will likely more be on newspapers et al (which are relatively cheap to deliver while still offering significant value)
  • The interface will want to be sexy – think photorealistic page turns and [enhanced?] coverflow based browsing.

HOWTO: Reverse engineer the iPhone protocols

A few months back (‘Apple iPhone 2.0: The real story behind MobileMe Push Mail and Jabber/XMPP Chat‘) I analysed how the iPhone interacted with the new MobileMe service with a view to offering the same features to Google Apps customers. Unfortunately this is not yet possible (the APIs don’t exist on both sides of the fence) but we learnt a lot in the process.

For those of you who have been living under a rock, MobileMe (previously known as .Mac) is Apple’s foray into cloud computing. It offers some impressive synchronisation and push services, but for a relatively steep annual subscription. One of the most coveted features is push mail, which makes e-mail behave more like instant messaging; as soon as the mail hits Apple’s servers they notify the clients which then retrieve the item. Technically that’s ‘pull’ with notifications rather than ‘push’ per se, but the result is the same; the user experience for email improves dramatically. They do similar things with contacts and calendar items. Due to popular demand (and making good on my promise to elaborate), here’s a brief explanation of how it was I got ‘under the hood’ of the iPhone’s encrypted communications with the MobileMe servers.

The first problem was to see what it was talking to. We’ve got a Mac household and a bunch of VMs (Windows, Linux and some other strange stuff) so I set up internet sharing on one of them and installed Wireshark. This allowed me to capture the (encrypted) traffic, which was terminating at aosnotify.mac.com:5223. Although we couldn’t decipher the traffic itself we already knew a fair bit from the server name, port number and traffic patterns; whenever a test mail arrived there was a small amount of traffic on this connection followed immediately by an IMAP poll and message retrieval. ‘AOS’ presumably stands for ‘Apple Online Services‘ (a division that’s at least 15 years old assuming it still exists) rather than Australian Online Solutions (which is what I translate ‘AOS’ to) and ‘notify’ tells us that they have a specific notification service, which reconciles with what we observed. Most importantly though, network port tcp/5223 was traditionally used by Jabber (XMPP) chat servers for encrypted (SSL) traffic; that reconciled too because Wireshark dissectors were able to peer into the SSL handshakes (but obviously not the data itself, at least not without the private keys stored safely on Apple’s servers and/or SSL accelerators).

The next problem was to tell the iPhone to talk to us rather than Apple. There’s a number of ways to skin this particular cat but if I remember well I went with dnsmasq running in a Linux VM and simply configured the DHCP server to use this DNS server rather than those of the ISP. Then it was just a case of overriding aosnotify.mac.com’s IP with the address of the VM by adding a line to the /etc/hosts file. That worked nicely and I could not only see the iPhone hitting the server when it started up, but could see that it still worked when I wired port 5223 up to the real Apple servers using a rudimentary Perl/Python proxy script. At this point I could capture the data, but it was still encrypted.

I now needed to convince the iPhone that it was talking to Apple when in fact it was talking to me; without a valid certificate for aosnotify.mac.com this wasn’t going to work unless Apple programmers had foolishly ignored handshake failures (that said, stranger things have happened). Assuming this wasn’t the case and knowing that this would be easily fixed with a patch (thereby blowing my third-party integration service out of the water) I started looking at the options. My iPhone was jailbroken so I could have hacked OS X or the iPhone software (eg by binary patching aosnotify.apple.com with aosnotify.<mydomain>.com) but I wanted a solution that would work OOTB.

Conveniently Apple had provided the solution in the iPhone 2.0 software by way of the new enterprise deployment features. All I needed to do was create my own certification authority and inject the root certificate into the iPhone by creating an enterprise configuration which contained it. I’d already played with both the iPhone Configuration Utility for OS X and the official Ruby on Rails iPhone Configuration Web Utility so this was a walk in the park. Deploying it was just a case of attaching the.mobileconfig file to an email and sending it to the iPhone (you can also deploy over HTTP I believe). Now I just needed to create a fake certificate, point the proxy script at it and start up the iPhone.

Sure enough this worked on the first attempt and I was even able to peer into the live, cleartext connection with Wireshark. Although I was surprised with the choice of XMPP’s publish/subscribe functionality, it makes a good deal of sense to use an existing protocol and what better choice than this one (though I wonder if Cisco’s acquisition of Jabber will have any effect). This discovery would have come as a disappointment for those touting the discovery of the private XMPP libraries (who naturally assumed that this translated to an Instant Messaging client like iChat), but it is interesting for us cloud architects.

Apple iPhone 2.0: The real story behind MobileMe Push Mail and Jabber/XMPP Chat

So those of you who anticipated a Jabber/XMPP chat client on the iPhone (and iPod Touch) after TUAW rumoured that ‘a new XMPP framework has been spotten(sic) in the latest iPhone firmware‘ back in April were close… but no cigar. Same applies for those who hypothesised about P-IMAP or IMAP IDLE being used by MobileMe for push mail.

The real story, as it turns out, is that Jabber (the same open protocol behind many instant messaging networks including Google Talk) is actually being used for delivering push mail notifications to the iPhone. That’s right, you heard it here first. This would explain not only why the libraries were curiously private (in that they are not exposed to developers) but also why IMAP IDLE support only works while Mail.app is open (it’s a shame because Google Apps/Gmail supports IMAP IDLE already).

While it’s in line with Apple’s arguments about background tasks hurting user experience (eg performance and battery life), cluey developers have noted that the OS X (Unix) based iPhone has many options to safely enable this functionality (eg via resource limiting) and that the push notification service for developers is only a partial solution. It’s no wonder though with the exclusive carrier deals which are built on cellular voice calls and SMS traffic, both of which could be eroded away entirely if products like Skype and Google Talk were given free reign (presumably this is also why Apple literally hangs onto the keys for the platform). If you want more freedom you’re going to have to wait for Google Android, or for ultimate flexibility one of the various Linux based offerings. We digress…

So without further ado, here’s the moment we’ve all been waiting for: a MobileMe push mail notification (using XMPP’s pubsub protocol) from aosnotify.mac.com:5223 over SSL:

<message from="pubsub.aosnotify.mac.com" to="sam@aosnotify.mac.com/5e60ad2e47da9fca36de59244f25c9b1cd8e0cb8" id="/protected/com/apple/mobileme/sam/mail/Inbox__sam@aosnotify.mac.com__3gK4m">
<event xmlns="http://jabber.org/protocol/pubsub#event">
<items node="/protected/com/apple/mobileme/sam/mail/Inbox">
<item id="5WE7I82L5bdNGm2">
<plistfrag xmlns="plist-apple">
<key>maild</key>
<string>E1B537</string>
</plistfrag>
</item>
</items>
</event>
<x xmlns="jabber:x:delay" stamp="2008-07-18T01:11:11.447Z"/>
</message>

<message from="pubsub.aosnotify.mac.com" to="sam@aosnotify.mac.com/5e60ad2e47da9fca36de59244f25c9b1cd8e0cb8" id="/protected/com/apple/mobileme/sam/mail/Inbox__sam@aosnotify.mac.com__NterM">
<event xmlns="http://jabber.org/protocol/pubsub#event">
<items node="/protected/com/apple/mobileme/sam/mail/Inbox">
<item id="8ATABX9e6satO6Y">
<plistfrag xmlns="plist-apple">
<key>maild</key>
<string>544FE17</string>
</plistfrag>
</item>
</items>
</event>
<headers xmlns="http://jabber.org/protocol/shim">
<header name="pubsub#subid">3DEpJ055dXgB2gLRTQYvW4qGh91E36y2n9e27G3X</header>
</headers>
</message>

I’ll explain more about the setup I used to get my hands on this in another post later on. So what’s the bet that this same mechanism will be used for the push notification service to be released later in the year?

Single command Django installer for OS X

So you want to see what all the fuss around Django is about? To get the latest bleeding edge snapshot (as discussed here, here, here, here, here, here, here and here) you just need to run these commands (as root), per the official install instructions:

/usr/bin/svn co http://code.djangoproject.com/svn/django/trunk/ /usr/local/django-trunk
ln -s /usr/local/django-trunk/django /Library/Python/2.5/site-packages/django
ln -s /usr/local/django-trunk/django/bin/django-admin.py /usr/local/bin

For the lazy, get root (eg sudo -s) and run:

curl https://s3.amazonaws.com/media.samj.net/devel/django.sh | sh

If it’s already there then this script will update to the latest revision.

Making SSL work with Apache 2 on Mac OS X with CAcert

Getting SSL up and running on OS X is not too difficult these days. First you need to tell it to read the SSL config file (removing red lines, adding green lines):

— /etc/apache2/httpd.conf 2008-06-11 03:42:25.000000000 +0200
+++ /etc/apache2/httpd.conf.dist 2008-06-11 04:15:15.000000000 +0200
@@ -470,7 +470,7 @@
#Include /private/etc/apache2/extra/httpd-default.conf

# Secure (SSL/TLS) connections
-#Include /private/etc/apache2/extra/httpd-ssl.conf
+Include /private/etc/apache2/extra/httpd-ssl.conf
#
# Note: The following must must be present to support
# starting without SSL on platforms with no /dev/random equivalent

Then you need to fix this config file for your environment:

— /private/etc/apache2/extra/httpd-ssl.conf.dist 2008-06-11 03:43:21.000000000 +0200
+++ /private/etc/apache2/extra/httpd-ssl.conf 2008-06-11 04:03:50.000000000 +0200
@@ -22,9 +22,9 @@
# Manual for more details.
#
#SSLRandomSeed startup file:/dev/random 512
-#SSLRandomSeed startup file:/dev/urandom 512
+SSLRandomSeed startup file:/dev/urandom 512
#SSLRandomSeed connect file:/dev/random 512
-#SSLRandomSeed connect file:/dev/urandom 512
+SSLRandomSeed connect file:/dev/urandom 512

#
@@ -75,8 +75,8 @@

General setup for the virtual host

DocumentRoot “/Library/WebServer/Documents”
-ServerName http://www.example.com:443
-ServerAdmin you@example.com
+ServerName secure.samj.net:443
+ServerAdmin xxxx@samj.net
ErrorLog “/private/var/log/apache2/error_log”
TransferLog “/private/var/log/apache2/access_log”

@@ -125,6 +125,7 @@

Makefile to update the hash symlinks after changes.

#SSLCACertificatePath “/private/etc/apache2/ssl.crt”
#SSLCACertificateFile “/private/etc/apache2/ssl.crt/ca-bundle.crt”
+SSLCACertificateFile “/private/etc/apache2/server-ca.crt”

Certificate Revocation Lists (CRL):

Set the CA revocation path where to find CA CRLs for client

@@ -143,6 +144,8 @@

issuer chain before deciding the certificate is not valid.

#SSLVerifyClient require
#SSLVerifyDepth 10
+SSLVerifyClient require
+SSLVerifyDepth 2

Access Control:

With SSLRequire you can do per-directory access control based

Notice that I’m using client certificates for authentication but you can comment out the SSLCACertificateFile, SSLVerifyClient and SSLVerifyDepth options if you don’t need this. If you do you’ll want to grab the root from CAcert:

# curl -o server-ca.crt https://www.cacert.org/certs/root.crt

You’ll want to generate random nubmers (key) and a certificate signing request (csr) in order to get a certificate (crt) file, and despite most information on the topic this can be done in one command:

# openssl req -newkey rsa:2048 -nodes -keyout server.key -out server.csrGenerating a 2048 bit RSA private key
………+++
……………………………………………………………+++
writing new private key to ‘server.key’
—–
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.
—–
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:New South Wales
Locality Name (eg, city) []:Sydney
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Australian Online Solutions Pty Ltd
Organizational Unit Name (eg, section) []:Security
Common Name (eg, YOUR name) []:secure.samj.net
Email Address []:xxxx@samj.net

Please enter the following ‘extra’ attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Actually in the case of CAcert.org everything except the common name is ignored so you can leave it as defaults.

For testing we’ll use a script which prints all the environment variables (this is what I was after for my certificate authentication anyway):

# cat /Library/WebServer/CGI-Executables/printenv
#!/bin/bash
echo “Content-type: text/plain”
echo “”
printenv

And when you browse to your machine (eg https://secure.samj.net/) you should see something like this:

SSL_SERVER_A_KEY=rsaEncryption
SSL_CLIENT_VERIFY=SUCCESS
SSL_SESSION_ID=A6C2F73FBFBB30AF927947D03B8E61AF26E0C4C68CB98F3B9CB7EB6E6ED78147
SERVER_SIGNATURE=
SSL_CLIENT_S_DN_Email=xxxx@debian.org
SSL_CLIENT_A_SIG=sha1WithRSAEncryption
SSL_CLIENT_I_DN_Email=support@cacert.org
HTTP_KEEP_ALIVE=300
SSL_VERSION_LIBRARY=OpenSSL/0.9.7l
HTTP_USER_AGENT=Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9) Gecko/2008053008 Firefox/3.0
SERVER_PORT=443
HTTP_HOST=secure.samj.net
SSL_CIPHER_ALGKEYSIZE=256
SSL_SERVER_I_DN=/O=CAcert Inc./OU=http://www.CAcert.org/CN=CAcert Class 3 Root
SSL_CLIENT_M_VERSION=3
DOCUMENT_ROOT=/Library/WebServer/Documents
HTTP_ACCEPT_CHARSET=ISO-8859-1,utf-8;q=0.7,*;q=0.7
SCRIPT_FILENAME=/Library/WebServer/CGI-Executables/printenv
HTTPS=on
REQUEST_URI=/cgi-bin/printenv
SSL_SERVER_I_DN_OU=http://www.CAcert.org
SSL_CLIENT_A_KEY=rsaEncryption
SCRIPT_NAME=/cgi-bin/printenv
SSL_SERVER_S_DN=/CN=secure.samj.net
SSL_VERSION_INTERFACE=mod_ssl/2.2.8
SSL_CLIENT_I_DN_OU=http://www.cacert.org
SSL_CIPHER_EXPORT=false
HTTP_CONNECTION=keep-alive
SSL_SERVER_I_DN_O=CAcert Inc.
SSL_CLIENT_S_DN=/CN=Sam Johnston/emailAddress=xxxx@debian.org/emailAddress=xxxx@samj.net/emailAddress=66e1c629ca065f0cead0ac9bee8e4cb016f93cb7
SSL_COMPRESS_METHOD=NULL
REMOTE_PORT=50392
PATH=/usr/bin:/bin:/usr/sbin:/sbin
SSL_CLIENT_I_DN_O=Root CA
SSL_CLIENT_M_SERIAL=0551B7
SSL_CIPHER=DHE-RSA-AES256-SHA
PWD=/Library/WebServer/CGI-Executables
SERVER_ADMIN=xxxx@samj.net
SSL_SERVER_A_SIG=sha1WithRSAEncryption
SSL_CLIENT_V_START=Jun 11 01:38:03 2008 GMT
SSL_SERVER_M_SERIAL=56C8
SSL_PROTOCOL=SSLv3
SSL_CLIENT_I_DN_CN=CA Cert Signing Authority
HTTP_ACCEPT_LANGUAGE=en-gb,en;q=0.5
SSL_SERVER_S_DN_CN=secure.samj.net
HTTP_ACCEPT=text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
REMOTE_ADDR=::1
SHLVL=1
SERVER_NAME=secure.samj.net
SSL_SERVER_M_VERSION=3
HTTP_PRAGMA=no-cache
SSL_CLIENT_V_END=Jun 11 01:38:03 2010 GMT
SERVER_SOFTWARE=Apache/2.2.8 (Unix) mod_ssl/2.2.8 OpenSSL/0.9.7l DAV/2
QUERY_STRING=
SERVER_ADDR=::1
SSL_SERVER_V_END=Jun 11 01:48:07 2010 GMT
SSL_CLIENT_I_DN=/O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/emailAddress=support@cacert.org
SSL_CLIENT_S_DN_CN=Sam Johnston
GATEWAY_INTERFACE=CGI/1.1
SERVER_PROTOCOL=HTTP/1.1
HTTP_CACHE_CONTROL=no-cache
HTTP_ACCEPT_ENCODING=gzip,deflate
SSL_SERVER_I_DN_CN=CAcert Class 3 Root
REQUEST_METHOD=GET
HTTP_COOKIE=__utma=64622253.189158232302809900.1213012569.1213012569.1213087976.2; __utmz=64622253.1213012569.1.1.utmcsr=blogger.com|utmccn=(referral)|utmcmd=referral|utmcct=/rearrange
SSL_SERVER_V_START=Jun 11 01:48:07 2008 GMT
SSL_CLIENT_V_REMAIN=730
SSL_CIPHER_USEKEYSIZE=256
_=/usr/bin/printen

That’s it for this morning’s lesson.