According to the article, they performed an inventory of the network, finding ca. 6,000 machines, many of whose IPs are accessible “publicly and directly with the system’s source code” (?), as well as a large number of hidden nodes.

There’s a lack of detail, but supposedly the attack involves creating a virus (?) and using it to infect such vulnerable systems in a laboratory environment, and thus decrypting traffic passing through them – again via an unknown, unmentioned mechanism.  Finally, traffic is redirected towards infected nodes by essentially performing a denial of service on clean systems.

I’m skeptical, as the piece contains just too much “oh, and then you hack component x and compromise component y and voilà, you’re in” to necessarily be plausible.  Furthermore, the ESIEA page has a large video presentation on French backwardness in “cyberwarfare” – any time a reputable institution uses such terms, it makes me wonder how much it’s angling for more funding from buzzword-prone politicians, with resulting pressure on researchers to provide supporting, news-grabbing headlines.

However, if it is real, details are to be presented at Hackers to Hackers in São Paulo on October 29/30.  TOR is no more than an additional layer of obfuscation and should  not be relied upon for anonymity or security.  Like any darknet, it is a complement to application-layer encryption and authentication, no more.

For a good in-depth history for even non-technical persons, I’d recommend Simon Singh’s excellent The Code Book.

Original link (pdf), full talk here.

Unfortunately there’s no information about hash algorithms, or salt mechanisms.

This post outlines why and how travelers with laptops, especially business travelers, are put at risk by border police searches of their computers.

I also attempt to present some techniques as to how this risk can be avoided, or at least mitigated.

Thus Far

The United States Transportation Security Agency, and the United Kingdom’s Regulation of Investigatory Powers Act (RIPA) have one thing in common — they expose travelers carrying sensitive information to risk.  A few relevant links on the subject:

Security researcher Moxie Marlinspike profiled and detained, equipment confiscated (later returned)

Wikileaks volunteer and developer David Appelbaum detained, equipment confiscated (some of it returned)

ACLU mounts lawsuit against baseless border laptop searches (a warrant is required since 2009)

UK man jailed under RIPA for refusing to hand over encryption keys to laptop

The USA and UK are by far not the only countries where user laptop or portable device data is put in danger.  In other nations, individuals may encounter draconian police laws (e.g. in totalitarian states) or corruption, and some other developed, stable, democratic countries occasionally make legal provision for confiscation of devices or investigation of data.  For example, in 2006, Brazilian federal police raided the offices of Credit Suisse, as well as the homes of several senior bankers.  What kind of access this gave them to business-critical data is open to speculation.

A Hypothetical Situation At the Border

The scenario that most concerns us is as thus:

A user (let’s say a busy manager) boards a flight.  He is on a way to a business meeting, to negotiate a merger.  On the flight, he relaxes and opens his laptop to get a bit of work done, editing his presentation for the first meeting, then becoming a bit distracted and looking over pictures of his little daughter playing in a kiddie pool.  The manager is annoyed at his chatty neighbor trying to crane his neck to get a look at his monitor, but his privacy screen blocks prying eyes.  30 minutes before landing, he closes his laptop lid and opens a paperback.

Upon entering customs, an official looks at his passport and picks up the phone.  He mumbles something about “additional screening”.  Two uniformed officers appear and very politely ask the confused executive to please follow them.  He is escorted to a windowless room, whose walls are lined with posters extolling the mission and professionalism of the bordeabr patrol, and warning against importation of illegal substances.  The manager is asked about his identity, and prompted to empty his pockets and open his bag on a table; while an inspector rifles efficiently through his carry-on, a second official looks on.  The manager’s questions and protestations are met with bland reassurances about “standard protocol”.

The first inspector finds the laptop, and walks out the door with it.  As the manager moves to stop him, the second inspector scowls and blocks his way.  Within a minute, two more officials enter, and begin talking about a suspicion of child pornography, and what serious consequences it harbors.  They mention that a fellow passenger reported having seen “suspicious” images on the laptop, and “encourage” the manager to cooperate, bringing up vague hints of terrible punishments, no-fly lists, and harassment.  He is presented with a form and a pen, and asked to write down his laptop screen lock password.   The manager looks at his watch — he has not slept much and needs a shave; his limousine charter has probably left by now.  His requests to make a phone call are politely but firmly denied.

Periodically, someone re-enters the room to ask about another password to an application (email, etc.)  An investigator inquires as to the password of his PGP-encrypted virtual disk.  The man’s protests are met with stern reminders that he must cooperate.  The executive has heard that it might be a good idea to have a lawyer in this country, but as a foreigner, he does not know how to go about it, and must be present at his meeting tomorrow.  In any case, he could not contact an attorney.  He does not think of asking to leave.  After four hours of this, punctuated by short interviews asking him to clarify, his laptop and phone are returned to him and he is allowed to leave.

What now?

Do we know that the data was removed upon failure to show any child pornography, incitement to money laundering, or terrorist literature (insofar as any of the above are not protected by free speech anyway)?  When the above user is the CEO of a multibillion dollar corporation, or his fully authorized deputy, are we sure that no information was passed on to a national champion or other competing firm?

Ideological Disclaimer

However, the United States and UK are the two largest, most economically significant liberal democracies to give their police and border protection enough leeway in terms of data interception and confiscation to constitute a real danger to anyone carrying sensitive data (or just those who feel that what’s on their laptop is nobody’s business; whether those contents are legal or not is beyond the scope of this article.)

Full disclosure:  I am vehemently against search and seizure laws that do not require a warrant.  I oppose border inspections of personal digital data unless they are extremely tightly controlled, as I believe laptops are very personal items.  It is my opinion that law enforcement (particularly border control) authorities should be held to a very high standard, so they can be trusted to maintain the high professional standards they claim to adhere to, to safeguard data and privacy, and to consistently respect rules of evidence.  Nonetheless, I suspect that border patrol and law enforcement agencies in much of the world have at least at some point acted as agents of industrial espionage.  I have strong ideological convictions in this regard, and do not hide these.

My objections are not so much addressed at places like China or Saudi Arabia, which openly engage in totalitarian, intrusive aspects of data analysis and censorship (and possibly theft), or Venezuela or Indonesia, where corruption and arbitrary measures can be expected.  You know what expects you when you visit an authoritarian or corrupt country.

These are my personal opinions.  I will be happy to provide my reasoning elsewhere.  This post, however, is no more than a discussion of technical and procedural controls that allow individuals and companies to reduce their exposure from mobile device seizure and data analysis.  For the purposes of those who claim that “those who have nothing to hide won’t mind security measures”, I say that

1. no security is engendered by this.  It is nonsense “risk management” or investigatory technique
2. it sets a very dangerous precedent in any society making even a small pretense as to individual liberty and freedom from arbitrary search and seizure, and questions the idea of the fundamental human right to travel
3. it puts a burden on host countries, insofar as illusory, ineffective, intrusive security mechanisms discourage travelers from visiting and bringing money and business, and
4. from now on, you will leave the door to your toilet open every time you go to take a dump

For the purposes of this article, we do not care what kind of data you have.  We will assume that you want to protect it, and that users are sort-of-but-not-highly technically versed.  Furthermore, I cannot address mobile phones, embedded tablet PCs (iPads e.g.) or PDAs, because I am unfamiliar with security mechanisms supported by various operating systems (IOS, Android, BlackBerry OS), so we’ll focus on generic mechanisms for laptop operating systems, with a few concrete examples.

Hardware Exploits, Rootkits, and Keyloggers

First of all, the as soon as someone has unsupervised physical access to your device, it is possible to implant keylogging hardware.  Although the supposed Dell laptop keystroke logger was a hoax, small hardware keyloggers are a fairly mature technology.  Interrupt detection won’t work, as the keylogger isn’t being installed stealthily (remember, the device is out of your possession / sight, and no attempt at stealth is being made.  If it’s rebooted, it’s rebooted.)  We assume the device is being carried, rather than checked in luggage, a stupid thing to do in any case — as such, the whole problem with border patrol or police temporary confiscation of laptops is that it is done in the open.

Even without manipulation of hardware, the hypervisor rootkit model presented by Joanna Rutkowska (“Blue Pill” — more here) would allow persistent access to even an otherwise “secure” laptop operating system, with full bypass of its security capabilities (e.g. by intercepting monitor signals or keystrokes).  I am unfamiliar with any functioning examples of such an exploit, but that does not make the concept any less valid or dangerous, or mean that it does not exist.

If there is any suspicion of the above, there’s not much point to reading the rest of this article.  The instant that something leaves your possession and sight, it can be assumed compromised.  The only mitigating factors are

• hardware keyloggers cost money.  You may not be worthwhile (does not necessarily apply to, say, a senior executive)
• installation takes at least a bit of time.  I do not know whether a rootkit could be slipped onto a drive without imaging the entire system
• there is a tiny risk of detection if done inexpertly — if you are ultra-paranoid and have opened up your device, noting down component serial numbers, you may be able to detect new hardware
• certain types of hardware require user interaction to get around drive-level encryption; cracking these is not feasible in a short period of time.  Then again, someone may just demand a user’s boot password under threat of prosecution or harassment, and walk off with it.
• hardware keyloggers that are hard to detect must be prepared.  An investigator would have trouble having clandestine-ready hardware for any given laptop model ready.

A software keylogger or spyware program / trojan can equally be installed, but a number of methods exist for detecting these with a reasonable degree of reliability, including virus scanners, and cryptographic checksums that can be compared with a central server, e.g. some equivalent of Tripwire or another host-based intrusion detection system (HIDS).

Most importantly, though, the moment something like a keylogger or other hardware exploit is on your laptop, it does not matter what other security measures you take.  Someone will always have access to your laptop from now on.

If the above applies, there is not much point to reading the rest of this article — it is the equivalent of telling a friend a Gmail password, then changing it — while he is watching.  The only ways to deal with this are

• buy a new laptop
• assume that all communications are bugged, all files can be intercepted / opened, and only work with data that does not matter

Data Dumps and Stuff

Be hind the scenes of the fictitious episode above, a forensic investigator took a full image of the user’s laptop.  There was no effort made to hide what was going on, nobody told him about his rights concerning search and seizure, habeas corpus and illegal detention, customs regulation, court and government rulings regarding data investigation, etc.  He was simply coerced into providing access to his information.  All attempts to encrypt, or hide, data on his laptop, and all mechanisms to foil intruders, came to naught.  The government in question, regardless of the (il)legality of its customs agents’ actions, now has a full dump of the user’s laptop, which may or may not include saved passwords for his webmail account, confidential company materials, a (weakly) password-protected Excel list of passwords, personal photographs, contacts, etc.

I’ll leave it to the imagination of the reader why this might be a bad thing.

If you maintain constant visual contact with a confiscated laptop, and can determine, with 100% assurance, that nobody has managed to slip something dodgy on to it, great.

However, the best way to secure yourself against compromise is to assume that any data on a laptop is forfeit and to avoid having any information on the laptop to start out with.  Remember — even if nobody installs anything, it’s pretty easy and quick to just dump a full storage device and play around with its contents later.

User Education

No amount of confidential information is worth the life, safety, or freedom of the person holding it (aside from exceptional situations — we’ll assume there’s not much wartime spying going on here.)

It is the responsibility of an employer to teach any business traveler two things:

1. Cooperate with authorities — regardless of what the situation is, nobody on the road for work should have to be a hero
2. Understand basic data protection techniques, including taking due care with creation of information so nothing described in this article actually becomes an issue

The point of all this is to avoid having to not cooperate or having to worry about data while on the road.

First Baby Steps

A few simple things might provide some degree of protection, but not a whole lot.

Set up a dummy account.  Keep it logged in.  Ensure that your login window does not show a list of users, but rather a username/password field, e.g. not this

but rather this:

When prompted to log in, do so with the dummy account.

Note that this will only fool idiots.

One-Way Encryption

A user cannot give up a key that he does not have.  Bruce Schneier wrote about this idea — allow a user to encrypt his laptop / files with a random key at some point before he is at risk of having his laptop accessed at the border.  Give someone else the password.  After passing the border, call this person to retrieve the password.

The downside to this is that, under something like RIPA, a user may face legal consequences for having encrypted material in his possession for which he cannot / will not provide the password.  The law puts the onus on the holder of the data.

Furthermore, this may expose the person carrying the information to harassment and difficulty entering the country.

External Media

A 64-GB thumbdrive, or a DVD containing personal/confidential data, could be hidden somewhere in a user’s luggage, or mailed out of band (e.g. FedEx).  However, that carries with it risk of interception.  If it is found on a user’s person or baggage, the user can also be coerced into giving up an access code.  If it is mailed separately, it may be very difficult to crack (e.g. PGPDisk) but there is still the risk that the wrong persons get their hands on it.

Pre-Trip Backups

All data on a user’s laptop should be backed up before he leaves.  This can take the form of incremental backups, or a full disk imaging.  This is useful in case a full restore from scratch to a new laptop is necessary.

All users should be storing their important work data on a network drive anyway, see a little further down as to why.

Remote / Travel Laptop Builds

A properly paranoid company will make a travel build available for its international travelers.  This is a stripped down OS configuration, containing as few hints as possible as to the nature of the company and its business.

It makes sense to do this anyway to avoid loss of confidentiality from lost/stolen laptops.  Make sure that someone on the road only has what they absolutely need on their laptop.  It’s understandable that someone wants to work on a presentation or document on the plane, but in this case, it is important to educate users about the need to only carry the data that is absolutely necessary for the current trip.

Unfortunately, that covers locally archived emails, and breaks down on trips involving multiple clients.  Furthermore, if the files a user is working on, say, during a flight on in a departure lounge, are actually highly confidential (e.g. the example of the merger negotiation)

Boy, the consultants will scream about this one.

Virtualization

Use virtual machines, such as VirtualBox, or VMWare.  At the very least, this allows reasonably quick restore of compromised working environments, and can be used to restrict access to a host OS by dodgy websites.  No particular benefit to travelers, except to add another layer of obfuscation — it is conceivable that an encrypted VM could be used for something like the “One-Way Encryption” environment above, completely masking what files / applications / sites are used.

Secure Remote Desktop

Most mobile users have access to remote working tools via VPN.

I once completed an architecture project that provided a Citrix environment over an IPSEC VPN to users.  A limited desktop, located on a hardened server in a DMZ, was presented to users.  Someone connecting remotely had access to their data, could work remotely, and download folders and individual files.

These could be the files that were backed up / copied to the network drive earlier.

Webmail interfaces (SSL-protected, via IPSEC) allow users to get around having to keep mail archives on laptops — unfortunately, most companies do not understand the concept of sufficiently large server mail quotas.  Disk is cheap.  Buy some.

Data Segmentation

For added peace of mind, users traveling to a country whose border patrol or police are known as a source of risk should be limited, via profile, to a subset of data on the remote desktop server.  Allow users to copy their files by project — and specify, either via user interaction, or via centralized management, which elements they have access to.

Most consulting firms already have “Chinese Walls” in place in order to prevent conflicts of interest, i.e. sanitizing one client’s data before using it with another so as to avoid exposing trade secrets.  The user mentality is thus already in place.

Access Logging and Monitoring

Companies should ensure strict logging of all access events, as well as all user activity.  Companies should maintain access profiles and correlate user activity with what is expected — a sudden attempt to dump entire file trees via remote access may be cause for alarm.

This ensures that, in case of a break-in by a foreign law enforcement agency using stolen credentials, it’s clear what was compromised.  This is good practice in any case; in the Brazilian example earlier, police had presumably unfettered access to a major corporation’s international network — many major global companies have some sort of poor segmentation between country networks.  Imagine the amount of scrambling and incident response work required to find out exactly what information they were able to obtain?  A single user is no different, if you don’t know that he has been forced to divulge access, or if your external VPN connectivity uses weak authentication and credentials are extracted from a copied laptop drive.

Two-Factor Authentication

Require users to use two-factor auth (e.g. RSA SecurID cards, chip cards, etc.) — this reduces risk from exposure of saved passwords or persistent authentication cookies dumped from a laptop.

Duress Passwords

In the extreme case that a user is forced to log into a corporate network via remote access, he should be given a a “panic account“.

This could take the form of “salomon.john” as opposed to “john.salomon”.  Keep passwords the same to keep things simple – complexity causes people to become nervous and give things away.  This account could even have access to the same dataset as the “real” account, while setting off all kinds of alerts and informing administrators that shenanigans are in progress.

User training is a strong prerequisite to make this work.

Remote Data Wipe

Many laptops have a SIM card slot.  In the case of the Apple iPad 3G, one of the few reasonable security measures is the central remote wipe capability.  Use it.  Whether as part of a duress code mechanism, or in case of unexpected activity, it may be wise to err on the side of caution and just nuke anything via remote management.

Third-Party VPN Termination

This is an extreme solution to what is, at best, a paranoid situation, but it might be interesting for companies to set up VPN connections to trusted intermediaries located offsite.

This is a bit of a separate issue, but a user connecting to an IPSEC concentrator with an IP registered to a given Swiss bank may raise the curiosity of law enforcement agencies who like to know, out of principle, what a Swiss bank executive is doing in their country — thus giving cause for additional searches the next time the user passes through a choke point like an airport.  Connections to an innocuous IP, however, may avoid such attention.

If the intermediary is trusted, a separate IPSEC connection can then be established from his servers to the corporate DMZ.

Conclusions

Controls of user laptops need not follow rational justifications — even developed countries have shown that their police and border investigations can be arbitrary.  While it is unlikely that a given traveler’s laptop may be investigated in depth, if it happens to you, the probability of it becomes academic.

No company should ever expose its mobile users to danger through their mobile data.  However, there are sensible ways to limit the potential fallout from unauthorized exposure by foreign law enforcement agencies to data that is simply none of their business.  It just takes a bit of investment and willingness to change mobile working habits.

The recently released Firesheep Firefox plugin demonstrates how simple it is to sniff logins and sessions on open, shared networks.  I spent a little bit of time playing with it; it is dirt-easy to install (OSX requires a workaround when running it in combination with FileVault — the fix is to move the extension directory somewhere outside of FileVault, such as the Firefox application directory in /Applications and to create a soft link back to the extensions directory.)  Although French ISPs are generally very good about providing their customers with home routers/firewalls with wireless encryption enabled by default, and it is thus pretty difficult in Paris to find open networks in comparison with other countries (except for the open access Free/O-Zone/SFR/etc. commercial ones), there are always a few.  Jumping on one of these, I had someone else’s Facebook account within 3 seconds (no, I didn’t use it, not that interested in other people’s private lives.)

In short, the plugin allows even a non-technical user to open a sidebar in a browser, click on “start sniffing”, and within fractions of a second, obtain both session cookies and username/password combinations for a wide range of popular web sites (Facebook, Twitter, and Gmail, among others, are configured by default, while the plugin allows easy adding of more pages.)  Sniffed accounts show up as icons on the sidebar — by clicking on one, you’re immediately logged into that user’s web account.

Taking this a step further, the (not as user-friendly, for now) Idiocy Python script (thanks to Thomas for pointing it out) automatically posts a link to this page “explaining what has happened” to a compromised Twitter account.

This is not entirely a problem of unencrypted wireless networks.  Any sufficiently determined user can attack a wireless network secured with WEP or certain types of WPA.  Even WPA2 may be vulnerable to brute force password cracking (standard password/passphrase best practice applies), although due to its key management methods, a compromised WEP environment allows a sniffer to access traffic from all users since the same key is shared.

Furthermore, malicious administrators with access to any sort of network choke point have access to this traffic anyway.  Most users are protected from such abuse by circumstance or pure statistics;

• many (especially European) countries have extremely strict limitations on what an employer can legally do in terms of intercepting traffic
• a network administrator likely has much better things to do than sniff traffic
• any choke point handling a large enough amount of data to be significant as a threat faces the above problem, but even more so

Security through obscurity is not a problem, but as has been pointed out elsewhere, if you’re in a group of people running from the bear, you don’t have to be fastest, just don’t be slowest.  Generally, any sort of network encryption (yes, even WEP) is a good start, and users of mobile data services and fixed-line networks are generally not at realistic risk.  WEP keys can be compromised in a few minutes under optimal conditions; using reinjection and deauthentication, enough packets can be captured reasonably quickly for this to work.  I maintain, though, that an attacker faced with an unencrypted network and even a weakly encrypted one will first go for the former — but a WEP network is only as secure as the most malicious person using it (whether they got on legitimately or not.)  Mr. Lakofski has a very valid point about shared WEP networks (e.g. hotels) insofar as their user base is a lot wider than a private one (which you should set to WPA2 anyway.)

Lastly, there are other, more amusing ways of collecting user data, beyond trojans, keyloggers, and this sort of thing.  A really amusing bit of evil villainery would have been for Eric Butler to have actually included a password stealing trojan in Firesheep itself — thus obtaining massive numbers of unsuspecting would-be crackers’ credentials as they connect to Facebook to boast about their “exploits”.  Yes, that would be illegal and bad, but still pretty funny.

Most popular websites allow SSL; Facebook, Google search, Gmail and Twitter all allow https:// connections (although in Facebook’s case, clicking on a Facebook link within the site redirects to a non-SSL page.)  Other services (LinkedIn, Amazon, Plaxo, and most social news sites e.g.) redirect https:// URLs to plain-text, at least for pages that do not involve entry of payment details or password changes.   Still others mix SSL- and non-SSL elements in their pages, which is about as good as having no SSL at all.  Most modern browsers, and some older ones, display a warning when this is the case.

Widespread SSL use is a good thing.  While it is computationally more expensive than cleartext, even SSL using self-signed certificates is an improvement — this is why I object strenuously to the way some browsers handle self-signed certificates; obnoxious warning messages discourage casual users from using crypto for the sake of crypto (rather than authenticating a web site.)  SSL is not necessarily a fix, due to the fact that a cookie not marked as ‘secure’ is still transmitted in clear text.  Once a user is authenticated, the certificate may be intercepted using passive man in the middle.  There is not much you can do about this, except to bug website owners / web app coders to fix the problem.

SSLStrip can also force a transmission to drop into cleartext.   One fix for this is Strict Transport Security, currently supported in several browsers.  FFixer also lets you force SSL (Facebook chat may not work.)  Another workaround is HTTPS-Everywhere (currently Firefox 3 only).

Gunnar Atli Sigurdsson of the University of Iceland has recently released FireShepherd, which floods nearby open wireless networks with packets designed to disable nearby Firesheep instances at ca. 0.5 second intervals.

Computerworld has an article about protecting against Firesheep that’s worth a look.

Update: the Blacksheep Firefox plugin seeds bogus session information to see if Firesheep is being used, then warns if it detects an attempt to hijack that session.  It’s not a defense, but could be a fun toy.

My overall impression?  A really nice device, with a good touchscreen; although I’m tempted, I can’t imagine what my greasy fingers would do to it – and my iPod Touch 2G scratched pretty easily even with casual use, despite its nice case.   It seemed fast enough, with tons of screen space.  I’m not exactly sure what I’d do with it (I love typing and am a bit clumsy with things like finger/mouse gestures and with my iPod’s – admittedly miniscule – on-screen keyboard), although my friend Ant came up with the best use I can imagine — photographers showing off their portfolio to potential clients.  The same would go for company presentations/electronic note-taking and doodling, and casual news/magazine/book reading, I guess.

In terms of usability, it’s been reviewed to death.

But I was not able to find much of any use regarding data protection and encryption, particularly in an enterprise environment.  Privacy and confidentiality issues seem to be limited to personal use, and nobody appears to have done a comprehensive overview, not of its guts, but of security applications in the business world.

The September MISC Magazine (France) has an interesting section on iPhone security, with a lot of detailed technical analysis.  By comparison, Apple’s overview of iPad security in the enterprise (pdf) is marketing fluff.  Most of the other articles I was able to find were either breathless “the iPad will bring XYZ to your company!” garbage, or fluff pieces of the “in order to secure the iPad in the enterprise, ensure you have proper enterprise security” variety that bored security consultants like me write when they have nothing better to say.

The device I looked at was a 64GB model with GSM (no SIM card), iOS 3.2.2.  This appears to fix certain vulnerabilities that allowed, among other things, remote privilege escalation, used in past versions of jailbreaks, but seems to still be vulnerable to a few issues.  This is an attempt to collect the useful bits I found; the information may be superseded at time of reading, so do your own research.

The risks I can identify are the following:

• danger of sensitive information compromise from a stolen (or less likely, network-accessed) iPad
• danger to the company network from an iPad connected via wireless/VPN

Security features include:

• Mandatory AES256 filesystem encryption.  Although I couldn’t find specifics on this, I assumed it was similar to OSX’s FileVault.  This is apparently not the case.  The encrypted image can easily be accessed via jailbreak, e.g. RedSn0w, allowing access to files.  It looks like the disk crypto allows no protection against this.
• Numeric PIN code, that can auto-lock the device after 2/5/etc. minutes (or never), and manual lock with the top button.  PIN protection can also be used to restrict apps (more on that in a moment.)  The PIN protection is laughable (4 numbers, no more, no less).  4.1 looks like it fixes this, but it is not out for iPad at the moment.
• Auto-wipe after 10 failed PIN attempts.  This is disabled by default in 3.2.2
• Application restrictions.  Not much of a security measure; it allows prevention of access to applications based on the iTunes App Store’s age rating.  You cannot choose which apps to restrict access to, nor is it possible to allow on-the-fly “unlocking” via PIN code of apps.
• Password encryption of backups via iTunes.  This is purely local (on the PC the iPad is being backed up to); Jonathan Zdiarski showed this summer that backup encryption is vulnerable.  That said, iTunes device backup is a purely secondary protection mechanism; I would suggest to try and convince employees to never back up sensitive files to their personal PCs anyway.
• Cisco VPN, including L2TP
• Remote wipe using MobileMe — if there is a GSM or wifi connection.  MobileMe costs $99 a year.  This is also possible via the Exchange management console (over Exchange ActiveSync) or via Outlook Web Access if configured.  Again, requires connectivity.  Steve Jobs confirmed that there exists a remote kill switch for iPads in case of rogue applications; this would concern me enormously from a compliance perspective — not for the possibility of data loss, but as it implies remote third party access.
• Centralized management is possible in the form of XML configuration files deployed via Apple Push Notification Service, allowing setting of such options; the Apple iPhone configuration tool is used to generate such configurations.  Apple has some resources on enterprise management of iPads/iPhones.

Computerworld wisely suggests using something like 1Password, for more granular access control for files.  Applications like Lockdown or Locktopus (both jailbreak required) provide password protection on a per-application basis; a quick google search didn’t turn up any Apple-sanctioned apps that do this.

Concerning danger to corporate networks from iPads, the only thing I can come up with is rogue jailbroken apps, and the very low probability that something bad is successfully smuggled into the Apple app store (as has happened in the past).  The danger from these would be minimal if the iPad is only sync’ed with a company PC via USB, rather than being allowed to access the company network via wireless or VPN.  If you are running an internal wireless network, that’s in front of a dedicated firewall anyway, right?

As always, a little user education goes a long way.  Particularly users who buy their own iPads are less likely to lose them, turning Apple’s obscene pricing policy into a bit of a positive thing.  If users can avoid connecting external USB devices, restrict themselves to only installing apps that they need, and practice a bit of discipline in terms of what they do with the device, they look like reasonable choices for low-security data.  I wouldn’t put anything secret on one, though.

Don’t get me wrong, aside from the bloat I love FF.  It’s like Apache — it’s a resource hog, but it does what you want nicely, and it’s kind of like a pair of old underpants that you can’t quite bear to throw away.  But this one particular bit of chicanery just stinks.

In case you forgot, when faced with a certificate signed by a CA whose root certificate is not in FF’s certificate store, you receive an obnoxious set of messages (here on a Mac:)

Oh noes, a cop.  It must be bad!

“Legitimate…other public sites will not ask you to do this.”  Screw you.

“This site attempts to identify itself with invalid information.”

I am doing no such thing.  Rather, I am attempting to encrypt your data transmission.  My site has no reason to identify itself to a client.  Yes, this goes away after the first time, but boy, what a way to scare off potential visitors?

Like Opera, and in contrast to Google Chrome, Firefox does not use any OS built-in certificate stores, such as Windows’ MSCAPI.DLL or MacOS X’s keychain access.  I assume this is for ease of cross-platform maintenance) but it does make it less likely that anyone will use certificates installed universally as part of a Mac package or Windows MSI installer or equivalent.

Thankfully, StartCom Certification Authority is now included by default; CACert, in addition to providing fairly short-lived certs (full disclosure:  I am a CACert assurer of some sort, or at least I was before I completely forgot about it) appears to have failed an audit at one point; Axel Eble points out that Ian Grigg, of Financial Cryptography, is currently conducting an open audit of CACert.

As far as free certificate issuers’ root certificate inclusion in Microsoft products goes, the company’s CA certification policy is pretty hairy — looking at the technical and audit requirements, an open candidate for inclusion in the Windows / Internet Explorer certificate store will have to muster significant financial resources.  Even if this were the case, there’s the interesting catch-all near the end of the requirements, disqualifying

“CAs who fail to meet the burden of proof for the broad business value of their offering to Microsoft customers.”

Without any criteria on what this constitutes.  At least IE’s self-signed certificate warning is a bit less cumbersome.

Commercial certificates cost a fair amount of money, starting at USD $150 for a 1-year basic SSL cert from Thawte, essentially for no incremental cost once they’ve passed their audits.  It’s a money machine, although I can’t fault them for it; I’d try to make money off a broken model too, if I could.

Why is this an issue?  Because the more the use of encryption permeates the Internet, the better.  Call it a distrust of authority, a desire to see increasing amounts of personal data secured out of general principle, a fundamental interest in an overall increase in entropy (let’s not get into the reasons why hiding, obfuscating and protecting your data is necessary — I will simply revert to the old and invincible argument about “you close your door when you use the toilet, don’t you?  What do you have to hide?”)  I want to see everyone and their dog use cryptography, if only for the purpose of letting Joe Schmoe acclimatize himself to the fact that it is not only possible and perfectly legitimate, but actually a very good idea, to encrypt things.

A big scary looking warning creates fear and distrust in the minds of nontechnical users when they visit a site with a self-signed certificate whose purpose is really only to keep the transmission of data-that’s-nobody-else’s-business secure (in addition to being a very small pain in the ass to those of us who have to click through the annoyance every time we want to log into our private web services from a different browser.)  Is that the point?  What about this?

Nice one, PGP.  Might want to talk to your customer services provider (that is, or at least was at time of writing, their actual site.)

Ian Grigg makes a good point — “I despise and loathe the idea that to use crypto you have to know me.”  As such, I agree with the idea that it’s pretty dumb to combine the handling of credentials used for encryption and identification of sites.  From what I can tell, the latter is Mozilla’s main concern with the hoops a nontechnical user has to go through to make sure a site is “legit.”

I understand the idea of wanting to make it clear that a certificate not signed by a “reputable” CA may be masking a phishing or otherwise fraudulent site.  However, one way around this would be to have two classes of warnings — one a simple check whether the FQDN of the website is identical to that of the host the certificate is created for, with a big friendly easy-to-understand information message stating something along the lines of “this certificate is for host xyz.com, please make sure the address in your browser bar is the same” with a simple list of cautions below it.

Bonus points for separating the authentication and encryption portions of an SSL connection — tell the user “the site claims to be xyz.com but may not be, but your transmission is encrypted, do not enter sensitive data, such as credit card or personal information, unless you’re sure whom you’re talking to” and basta.

The second use case, for certificates authenticating a site and encrypting a connection, should check far more strictly that the issuer is legitimate.  In this case, the end-user has a genuine need to know that the certificate issuance process is tightly controlled via a trusted party — the CA root cert included in the browser store.  Fair enough.

Yes, the average “user” may not have much clue, but excessive mollycoddling at the expense of usability is bound to be counterproductive — it scares people away from increased use of crypto, and annoys the rest of us with way more obstacles than are necessary.

One of my recent projects had me shepherd the development and rollout of an embedded firewall for medical / clinical diagnostic devices in compliance with U.S. HHS / FDA rules on patient data privacy.  Without going into details, a number of new, long-awaited requirements have sprung up within the past few years requiring data protection technology and processes in environments handling sensitive patient information.

This creates a bit of a conundrum for medical device and software manufacturers, insofar as all medical products, not just drugs, must undergo a massive, periodic set of verification and validation tests in order to ensure that they actually do what they’re supposed to, and will not result in minor side effects like genital herpes, limb removal or spontaneous combustion.  Validation is expensive — bringing a drug to market can cost nearly $1 billion;  any changes, upgrades or additions must go through punishing testing procedures.  The same applies to clinical devices — MRI scanners, blood testers, and the myriad of associated machinery — plugs, cables, batteries — anything that somehow processes or plays a role in the processing of patient data.  Fine.

For IT systems, this is a bit of an issue, especially in light of increased connectivity of hospital and other medical products.  When to re-validate?  Software upgrade?  New feature set?  Security patch?  Antivirus pattern udpate?  As we all know, bugs lurk everywhere, and even innocuous changes could bring about unwanted effects in poorly privilege-separated systems.  This becomes worse when consumer operating systems start being used to run task-specific machinery; common development platforms keep costs down and allow for faster and broader-ranging feature implementation, but despite the inevitable whining about security-through-obscurity-is-not-real-security, having an off-the-wall operating system cuts both ways, in that it may hide flaws less likely to be spotted by peer review, but also often requires targeted intrusion attempts in order to break.

So given that clinical validation and revalidation of upgraded software so as to ensure continued reliability can cost anywhere around $500,000 a pop in time, resources and grief, offloading network security is a good thing.  Despite the discrediting of eggshell models of network security (I still firmly believe that any system should be able to survive if exposed on an open network, even if this is not necessarily wise), if it’s simply not feasible to secure everything, you might as well protect it.  The difficulties in validating and maintaining such systems, though, make it desirable to keep things as simple as possible.

Enter m0n0wall and WRAP / ALIX.  This is the most killer hardware/security platform combo I’ve seen.  I have a few of these on the older WRAP board running for years now without a hitch.  They are incredibly robust, simple, without moving parts, and tolerant; my WRAP boards have been dropped, drenched, plugged into massively off-spec power supplies and otherwise abused.  There’s a mini-PCI slot for a wireless card, and newer ALIX boards have VGA-out, sound, USB and serial.

M0n0 has a friendly interface, a great support community and a tremendously motivated developer behind it.  Anyone familiar with basic firewall or crypto terminology will figure it out instantly; it’s fast, lightweight and has never crashed on me.  My only bitch is that changing an inbound NAT rule does not automatically adjust associated firewall rules, but that’s a pretty minor thing.   Best of all, it’s FreeBSD-based and conducive to hacking.

A colleague of mine recently encountered mysterious issues with SSL connections that dropped large numbers of packets, while cleartext pages loaded fine.  After a bit of digging, he found that decreasing his DSL router’s MTU size from 1410 to 1400 seemed to do the trick.

I did some looking around, and found this page from Primus Telecom (Australia) that describes the problem well.

When you access a website or essentially do anything on the Internet, your computer places the information into packets, the size of which is determined by the MTU (Maximum Transmission Unit). On an Ethernet network the default MTU size is 1500 bytes, which is what most routers on the Internet will accept, the problem however occurs when we introduce protocol overheads.

Because there are a number of different protocols your data packets may be encapsulated into, the size of the MTU can increase at different places in the network. If the packet is already close to 1500 bytes when it leaves your ADSL router, it may become larger than 1500 by the time it gets to its destination, which means it will be fragmented, or split up.

Encryption protocols generally can’t handle packet fragmentation, though this is more by design, rather than as a fault, as fragmentation may introduce a point of insecurity, and allow the encryption to be broken or intercepted.

The overhead mentioned consists of datagram encapsulation, for example, and is added by routers along the way.

When using SSL / SSH, the sending machine will set the IP “do not fragment” (DF) header bit to “1″.  Ideally, traffic is sent via the largest size that does not fragment; RFC 1191 describes a technique to use the DF header to discover the PMTU (path MTU, this maximum size.)  Lowering it on first hop after your sending machine will do the trick, though. ]]> http://www.chakraborty.ch/standards/ssl-ssh-and-mtu-problems/feed/ 2