Remote SSH using Back To My Mac

One of the less well publicised features of Apple’s iCloud service is Back To My Mac.

This service provides a private IPv6 network which you can use to securely connect all your Mac hosts.

To use BTMM you will need to upgrade all your Macs to OS X Lion and sign them all into the same Apple iCloud account. You will also need your unique BTMM account number.

When you are signed into iCloud you can discover your BTMM account number as follows:

$ dns-sd -E
Looking for recommended registration domains:
Timestamp     Recommended Registration domain
12:07:46.550  Added     (More)               local
12:07:46.550  Added                
                                             - > btmm
                                             - - > members
                                             - - - > 123456789

The final line shows your individual BTMM account number.

For example, if you Computer Name (set in System Preferences > Sharing) is mymac and your BTMM account number is 123456789, then the fully qualified domain name of the host is

If you have spaces in your Computer Name then replace them with dashes, e.g. “My Mac” becomes the hostname my-mac.

To test connectivity to your remote host use ping6, e.g.


To list all the SSH enabled hosts on your domain:

dns-sd -B _ssh._tcp

You would SSH into your host using this command:

ssh -2 -6

Note that you will only be able to communicate with the other hosts on your iCloud private network if the Mac you are using is also signed into the same iCloud account.

You can also use an open SSH connection to access your non-Apple hosts on your internal network by using SSH port forwarding. This tunnels the destination traffic over the BTMM private network via your remote Mac.

For example, if you have a web server running on a host with the IP address then you can use this SSH command to set-up a forwarded port:

ssh -2 -6 -L 8080:

To access the remote host from your local machine you would go to

Dropbox & EncFS on OS X Lion

I previously wrote about a method for creating a super-secure filesystem using Dropbox’s cloud storage.

After updating to Mac OS Lion I struggled to get the MacFusion GUI to work and so I wrote an application to automate the mounting and unmounting of the EncFS filesystem.

I also took the opportunity to switch from the now abandoned MacFUSE to Fuse4X, which is a properly maintained fork of MacFUSE started in June 2011.

The install procedure is much simpler than before, you install Fuse4X and EncFS, but instead of using the MacFusion GUI you just call my script instead.

To the instructions!

First download and install Fuse4X and a version of EncFS which uses the Fuse4X APIs. Thanks to Simone Lehmann for providing an EncFS Mac installer at (also mirrored here).

To create a new encrypted volume (stored locally at first to prevent the EncFS key from being synchronised with Dropbox):

encfs ~/Desktop/_Encrypted ~/Documents/_DropSec

Answer ‘yes’ when prompted to create the new folders and choose ‘p’ for pre-configured paranoia mode (256-bit AES encryption). Enter a secure EncFS password when prompted and you’re done.

Now the filesystem has been created we can deal with securing the key.

umount ~/Documents/_DropSec
mkdir ~/.keys
mv ~/Desktop/_Encrypted/.encfs6.xml ~/.keys/dropsec.xml

The commands above move your key from the EncFS filesystem into a hidden folder in your (local) home directory

Now move the entire ~/Desktop/_Encrypted folder (minus your key) into your Dropbox:

mv ~/Desktop/_Encrypted ~/Dropbox/

Finally download my DropSec application and copy it to your Applications folder.

The first time you run DropSec it will prompt you for your EncFS password which it stores in your local login keychain. The password must match the secure password you set in a previous step.

To mount or unmount the encrypted filesystem simply run the DropSec app. For convenience copy it to your Mac OS Dock for quick access.

Opting-out of Google Location Server

In September Google announced their intention to comply with requests from European data protection authorities and offer a method for opting-out of their Google Location Server (GLS).

Peter Fleischer (Google’s Global Privacy Counsel) has today published an update on the European Public Policy Blog and Google have added specific opt-out details on their Maps Help page.

What is GLS? It’s a location service that most Android smart phones use to request your current location. Your smart phone could simply use satellite positioning (GPS) to accurately pin-point your location, but GPS consumes battery and generally only works outside.

Instead of using GPS your smart phone attempts to discover your location by scanning for nearby WiFi access points. It gathers the relative signal strengths, network names and unique network addresses and sends the details to the Google Location Server (GLS) for processing.

The GLS checks its database of WiFi access points and returns an estimate of your location. If your local WiFi access points are known and already in the GLS then it will return a fairly accurate location, almost on a par with GPS, for a fraction of the power.

Google built their WiFi location database while collecting data for Google StreetView and it is constantly updated and augmented by smart phone crowdsourcing. The manner in which Google collected this data has been controversial and Google have been investigated for breaches of interception laws. As a result Google has been forced to offer this opt-out scheme to appease regulators.

So what do you need to do to ensure that your own WiFi access point is not included in the Google Location Server database?

Simply append “_nomap” to the SSID of your WiFi network and Google will remove it from their database the next time a device sends information to the GLS.

It’s undoubtedly an inconvenience to change your WiFi network name and re-associate all your wireless devices, but if this scheme is adopted by all the mapping services (Microsoft, Apple, Skyhook) then it could well be worth it.

Hotmail account recovery

I’m trying to resurrect an old address to use it as a Windows Live ID.

Admittedly the last time I used the address was a few years ago, but it is still mine and I should be able to get it back right?

The first obvious problem I encounter is that I’ve forgotten the password. I try the ‘Reset your password‘ link and gave the secret answer to my security question.

Windows Live responds with: “This option is temporarily unavailable because incorrect information was entered too many times. Please try another option or try again later.”

So far so bad.

I go for the ‘Customer Support’ option instead and attempt to fill out an account recovery form.

“Help us to make sure that this is you. To recover your account, enter as much information as you can.”

I have a go at providing old passwords, possible subject lines for old emails and contacts I’ve previously sent email to. I last used the account in 2008 so my memory is more than a bit hazy.

After a few hours I received this email response from Microsoft:

Unfortunately, we could not verify your ownership of using the information you provided. Your account recovery request with issue number 12345678 has been closed.

In keeping with Microsoft’s commitment to protecting online privacy, Windows Live takes account security seriously. Passing the account recovery process can be difficult. Please reconsider your originally submitted information, as well as provide any additional information when submitting a new account recovery request.

Here are some suggestions to assist you in submitting a new request:

  • Answer questions using the information you used when you created the account or last updated it.
  • Submit the recovery request from a computer you frequently use for Windows Live services.
  • Answer as many questions as you can and be as precise as possible.
  • For questions with multiple answers, such as email subjects and contacts, provide as many answers as you can.
  • If you have difficulty remembering email subjects or contacts, try reaching out to family, friends, or business contacts to verify.

Ready? Click here to submit a new Windows Live account recovery request.

Please do not reply to this message. Replies to this message are routed to an unmonitored mailbox.

Thank you,
Windows Live

Not a great help. I’ve tried a couple more times, but I get the same response each time.

Does anyone have any suggestions, or have I lost my account forever?

Who do you trust?

I trust a few people and organisations – my parents, some close friends and a handful of organisations such as EFF. Your personal circle of trust is probably not hugely dissimilar.

I wonder, have you heard of DigiNotar or Comodo before? Do you realise that you implicitly trust them and hundreds of other organisations every time you use your Internet web browser?

What are you trusting these organisations to do? You trust them to vouch for secure web sites that you visit. These 650 ‘trusted’ organisations are SSL Certificate Authorities (or CAs) and they are responsible for confirming that a given domain name and web site belongs to the legal entity named in the web server SSL certificate.

As a result of security weaknesses, the integrity of the Comodo and DigiNotar Certificate Authorities was breached in hacks which made news all around the world. Even the non-tech press realised the significance of these attacks.

The hacker responsible was able to generate a number of bogus web server SSL certificates, which were used by persons unknown to transparently intercept and spy on communications with popular web services such as Gmail, Skype and Facebook.

(Update: This article was written in 2011, before Edward Snowden’s revelations about NSA interception techniques. The paragraph above now has extra significance with regards to the persons unknown!)

This led me to question the role of certificate authorities and how fit for purpose the SSL protocol is in the modern Internet world of web applications.

The original SSL protocol specification was drafted in 1994 by Netscape engineer Kipp Hickman. In the section describing ‘Man In The Middle’ attacks the author simply says:

During the security connection handshake the server is required to provide a certificate that is signed by a certificate authority.

Any good secure protocol requires three elements: secrecy, integrity and authenticity. Apparently Hickman himself has admitted that authenticity was “thrown in at the end” of the SSL protocol specification. This weakness of SSL is a fundamental and critical flaw. This is the element where commercial interests, criminality and good old fashioned human error have all come into play.

In the early days of SSL, VeriSign was the lone certificate authority entrusted to verify that a web server belonged to a particular domain name and legal entity. The problem with a monopoly such as this is that without competition the CA can set an unreasonably high price for the service they provide. To stimulate competition more and more CAs were added to the trusted root certificate lists and over time we now find ourselves with literally hundreds of ‘trusted’ CAs.

So what makes these businesses trusted? Judging by some of the CAs that have bought their way onto the list – not a lot!

StartCom CA for example will issue free SSL certificates with only cursory validation. In their own words:

Class 1 Certificates provide modest assurances that the email originated from a sender with the specified email address or that the domain address belongs to the respective server address. These certificates provide no proof of the identity of the subscriber or of the organization.

Most Internet users naively assume that seeing https and the padlock icon is a guarantee that the identity of the web site owner has been verified and the web site is secure. Actually both assumptions are no longer true.

It is no longer necessary to go through strict vetting procedures to obtain a valid and trusted SSL certificate. With fake certificates having already been created via compromised CAs there is also no guarantee that your communications are safe from a man-in-the-middle attack.

Former Netscape Chief Scientist Dr Taher Elgamal is credited as being one of the co-authors of the original SSL specification. He too has voiced his concerns that a copycat attack against CAs could result in more rogue SSL certificates:

It could happen again. There’s no back-up plan, which is generally a bad security model. The problem of what to do when certificate issuers were compromised never came up when the original work was being done on SSL/TLS. Nobody asked the question of what to do if a certificate authority turns out to be bad. The problem was not so much with the technology as it was with the firms issuing the certificates.

There’s way too many of them.

But what of the Online Certificate Status Protocol (OCSP), which was specifically designed to protect us from rogue SSL certificates? Well that is unfortunately flawed too and can be bypassed using a simple protocol trick.

So are there any workable alternatives to SSL?

Moxie Marlinspike (the security researcher who found the OCSP flaw referenced above) has been giving it some serious thought. He was inspired by a concept called Perspectives which he has improved on and developed into Convergence – “An agile, distributed, and secure strategy for replacing Certificate Authorities“.

Convergence is still in its infancy and it’s not perfect, but with SSL now coming of age it could be a critical enabler for the future of secure communications.

I’m glad that someone who understands the weaknesses of SSL has proposed an alternative to CAs. Let’s hope that this effort gains some momentum in the industry and together we properly solve the issue of web server authenticity.

Security and The BEAST

The news of supposedly trusted certificate authorities DigiNotar (now bankrupt) and Comodo being penetrated by hackers was a severe blow to the long established SSL/TLS chain of trust security model.

Now there’s another serious web security vulnerability to be concerned about.

Security researchers Juliano Rizzo and Thai Duong have exploited a weakness in CBC (Cipher Block Chaining) based ciphersuites which they have used to create a proof of concept attack on SSL.

Their exploit is called BEAST (Browser Exploit Against SSL/TLS) and it demonstrates how to steal a web browser session cookie that is supposed to be protected by SSL. The implications of this are that your supposedly secure (i.e. HTTPS) web browser sessions can be hijacked by a third party.

How can we protect against this? Well since BEAST exploits CBC then web server administrators need to use a different cipher.

Google have switched to using the RC4 cipher on their web sites and Microsoft has issued an advisory recommending that you “prioritize the RC4 algorithm in server software in order to facilitate secure communication using RC4 instead of CBC“.

Twitter Typosquatting

I just mistyped as and was surprised to find that I was redirected to what looked like a Twitter survey / competition page.

The logo at the top of the page is presumably deliberately designed to fool you into thinking that it’s an official Twitter survey:


You’ve been selected to take part in our short, anonymous 30 second questionnaire. To say “thank you”, you’ll have the opportunity to receive one of our exclusive offers including a Airline Travel Voucher and Win an iPad2. Start this short survey now.

I tried going to a few times and was redirected to a number of alternative domains, each with the same fake ‘quiz’:

I got bored of harvesting all the various quiz and survey related domain names (they actually had some really good names), but I collected around 70 and submitted them to the OpenDNS Community tagged as Adware.

Incidentally, if you’re not already using the fantastic OpenDNS service then I highly recommend it.