It turns out that if you don't enable security, your network will be insecure. OK, sarcasm aside, it's not unreasonable to expect at least a little bit of privacy when connecting to a public Wi-Fi hotspot. You're on somebody else's network, and you need to take responsibility for your own security.

When connecting to a public hotspot, a VPN or some other kind of end-to-end encryption is a must. Even with Wi-Fi security enabled, your data is only protected as far as the wireless access point to which you are connected. When you are in your corporate office, connecting to your own network's access points, this is plenty. The problem with a public hotspot is that the network operator controls the access point, so once your data enters the wired network, it is vulnerable. In this case, your data need to be protected all the way from your laptop back to your corporate servers.

Here at Corriente, our own remote access methods are simple. Rather than rely on an IPSEC VPN and all its inherent headaches, we use application-layer encryption. For instance, all remote email access is SSL secured, using the SSL support built into the email client. Any service we use that doesn't natively support an encrypted layer (like our source code control system) is tunneled through SSH. All this keeps the bad guys at bay while still allowing us to get some work done while on the road.

ISO meetings are taking on the flavor of Cold War era diplomatic summits. China walked out of a recent Wi-Fi security standards meeting in protest over the group's refusal to fast track China's WAPI proposal. WAPI is China's alternative to 802.11i, and the fear amongst all non-Chinese Wi-Fi developers is that the encryption specified in the protocol contains a backdoor that can be opened by the Chinese government.

Fortunately, WAPI is a complete non-starter everywhere outside of China. My main beef — in addition to using encryption algorithms created by the Chinese government — is that Wi-Fi product vendors must "partner" with Chinese companies in order to sell WAPI products. This entails giving Chinese companies closely guarded microchip designs, not a attractive prospect given the Chinese record on intellectual property protection.

The Sysinternals guys have create Rootkit Revealer, a new freeware software application. Rootkit Revealer can, as its name suggests, detect the presence of rootkits (malware that that hides itself be means of hidden files and patched system APIs) on your system. The new software performs a low-level scan of the system, below the level at which a rootkit hides. It then performs a second, high-level scan and compares the results. Anything that shows up in the low-level scan but not the high-level is something that is trying to hide. Cool stuff, and you can't beat the price.

I'm always on the lookout for Wi-Fi security breakthroughs, so I read this article with intense interest. Then I read the details, and became far less interested. It looks like a new type of challenge-response authentication protocol. It doesn't solve any problem that hasn't already been solved a dozen different ways, and being patented is going to get it put into many systems when so many patent-free protocols are available. I think the only reason that this "delayed password disclosure protocol" is getting any attention at all is that they have tied it to the recent hullabaloo over "evil twins".

Evil twin protection exists today in the form of WPA security. WPA Personal provides mutual authentication without password disclosure through its 4-way handshake, while WPA Enterprise uses a TLS tunnel that first authenticates the server before sending any password data through its encrypted channel. Even then, WPA Enterprise typically uses MS-CHAPv2 as the password protocol inside the tunnel, which provides mutual authentication without password disclosure even without the TLS tunnel.

While the whole Paris Hilton Sidekick hack is amusing, it's also demonstrative of how dumbing-down security for the sake of making products easier to use has its pitfalls. Now it turns out that by simply faking your caller ID, you can access the voice mail of phone users who have enabled "auto voicemail login". This is the feature that allows you to access your voice mail from your own phone without having to enter your PIN. Oh, and the original Paris address book hack came about due to a poorly chosen password. [watch out for the links — this is Paris Hilton we're talking about, so they are mostly not safe for work].

The real question to arise from all of this is "who in the hell wants to call Victoria Gotti?" Based on the 30 seconds I've seen of her — a promo advertising her show "Growing Up Gotti" — I think she has to rank among the most unpleasant people on the planet.

Help Net Security has released details of a Mac OS X web server exploit that can be used to reveal the source code of PHP and other web applications. This is troublesome because a typical PHP application includes things like database server passwords. Apple has already patched the vulnerability in Security Update 2004-12-02.

The exploit is based on how Apple mapped the HFS+ file system, which includes multi-forked files, onto the POSIX file access routines, which have no concept of multi-forked files. In order to be able to access data forks and resource forks using these routines, Apple created special file suffixes. Say you have a file called "/Users/chris/stuff.txt", you can access the data fork of the file by opening it as "/Users/chris/stuff.txt/..namedfork/data", and the resource fork by opening the file as "/Users/chris/stuff.txt/..namedfork/rsrc".

This file opening scheme can be exploited because web servers determine how to treat a file based on its file suffix. Thus, the file "example.php" will be sent to the PHP processor and treated as an executable script. However, if an attacker requests the file "example.php/..namedfork/data", the web server will treat it as a text file and simply send its contents to the attacker, exposing whatever secrets may be in the file.

In addition to the Apple fix, 4D has an updated version of WebSTAR available.

One day after the announcement of flaws found in SHA-1, crypto standards groups have started discussing the future.

Microsoft released an update to its anti-spyware software. What's more, Bill Gates announced at this week's RSA Conference that Microsoft will be giving it away for free once the final version ships. He also announced that Microsoft will be developing anti-virus software. My prediction on upcoming announcements: Symantec, McAffee, Kasperksy, et.al. announcing lawsuits regarding anti-competitive behavior.

Bruce Schneier is reporting that a research team has broken SHA-1. This is big news in the world of cryptography. Here's why:

SHA-1 is a hash function. Hash functions, along with cipher algorithms (like DES, RC4, AES, et. al.) and public key algorithms (e.g., RSA, Diffie-Hellman, DSA), are one of the building blocks of modern cryptographic protocols. Hash functions are used to compute a "fingerprint" of a block of data. In a typical crypto protocol, one party uses a hash function to generate a fingerprint of a given chunk of data, digitally signs that fingerprint, then transmits the data and the fingerprint to a second party. The second party takes the chunk of data, and runs the same hash function to generate its own fingerprint. By comparing the two fingerprints, the receiving party can tell whether or not the data has been altered in transit.

To be considered secure for cryptographic use, a hash function must possess two main properties:

• It must be one-way: Given a chunk of data, it must be possible to generate a fingerprint, but given the fingerprint, it must not be possible to generate the data. That is, the hash function is not reversible. If an attacker has access to the fingerprint but not the data chunk, the fingerprint alone should not give any hint as to the contents of the data chunk.
• It must not have collisions: The hash function must always generate the same fingerprint for the same chunk of data, and always generate different fingerprints for different chunks of data. If a slight change is made in the data being fingerprinted, it must result in a completely different fingerprint. Further, it must be infeasible to find two different chunks of data that result in the same fingerprint.

It is with the second property, collision resistance, that SHA-1 has been found lacking. The new attack can find a collision in 2^69 tries, compared with the 2^80 tries that were necessary before this attack was developed. That may not seem like much of a breakthrough, but keep in mind that for each power of 2 you can knock off the running time, you make an attack twice as easy. It would still take either a lot of computing power or a lot of time to find a coliision, but by moving from 2^80 to 2^69, an attack on SHA-1 went from being impractical for everyone to being practical for quite a few organizations. Another thing to keep in mind is that attacks like the one on SHA-1 frequently improve in their effectiveness as more research is performed and the attack is optimized.

The problem is further exacerbated by the fact that hash functions play a critical role in digital signatures, and digital signatures must be strong for years. For instance, many certificate authorities have used SHA-1 in their root certificates, and some of these certificates are valid for decades. If one of these roots is compromised, then every digital certificate signed by one of these roots is compromised.

SHA-1 is the current standard hash function in just about every crypto protocol in widespread use. Coming on the heels of the MD5 attack of last year, this leaves us with no widely deployed hash function that hasn't been proven weak. MD2, MD4, MD5, SHA-0, HAVAL, and RIPEMD-160 all suffer from flaws. SHA-1's successors, SHA-256, SHA-384, and SHA-512 have no major attacks on them, but neither have they been widely deployed nor have they been as scrutinized as the other hash functions.

So how does this relate to Wi-Fi security like WPA Enterprise? Hash functions are used in several places in the protocol:

• At the RADIUS level, the response authenticator, which proves that the RADIUS packet has not been tampered with, uses MD5. However, the Message-Authenticator attribute, which performs the same function for EAP-based RADIUS authentication (like that in WPA Enterprise), uses HMAC-MD5, a keyed hash function that is not currently vulnerable to attack.
• TLS records are hashed using HMAC-SHA1, which, according to the Schneier article, is not vulnerable.
• TLS session keys are derived using a combination of HMAC-SHA1 and HMAC-MD5, so again, not vulnerable.
• Servers are authenticated using digital certificates that incorporate a hash function in their digital signature. This is the primary vulnerability with regards to Wi-Fi security.
• For EAP-TLS, where clients authenticate themselves using a digital certificate, their certificate is vulnerable in the same manner as the server's. During the TLS handshake the client proves that it hold the private key associated with its certificate by signing SHA-1 and MD5 hashes of the TLS handshake messages. This is not a concern for the immediate future, as it would require both hashes to be breakable in real time.
• Finally, the password protocols use hash functions: CHAP and EAP-MD5-Challenge use MD5, while MS-CHAP-V2 uses MD4. These are encrypted inside the TLS channel, greatly diminishing their vulnerability to attack.

Right now, there is precious little detail about the nature of the new SHA-1 attack, but you can expect to start seeing major changes in crypto protocols in the near future in response to it. After the MD5 attack was published last year, those of us in the crypto community took a lot of comfort in knowing that MD5 was already being phased out and that SHA-1 was a viable replacement. With this new attack, there is no immediate replacement, and crypto products are going to require re-engineering.

Microsoft is working on Internet Explorer 7. It "will be the most secure browser we’ve ever released." A beta will ship this summer, and it looks like it will require Windows XP with Service Pack 2.

Rule number one for software developers creating anti-piracy schemes for their products: in your zeal to keep your product off the warez sites, don't piss off your paying customers.

Software products that require online activation should give users a grace period in case they don't have internet connectivity or face some other kind of problem with activation. This is the model Microsoft follows with Windows XP: after installation, you have 30 days before the product stops functioning.

We aren't using any kind of activation scheme because we, as software consumers, don't like having it foisted upon us. Speaking for myself, there are two things I don't like about activating software online: I don't know what information the software is sending back to the vendor, and if the vendor goes out of business and I need to re-install the software, I'm out of luck.

We've been lucky and have not had a significant problem with our own software being pirated. If we do ever have a widespread problem with piracy, my tune on software activation may change. Knock on wood, that day will never come.

eWeek reports that Wi-Fi users are confused by poor Wi-Fi product documentation and support. As a result, they often misconfigure their Wi-Fi security settings or never enable security at all. The article cites as the main source of confusion the "inconsistent nomenclature and presentation of the basic components".

We've run into the same problem here. When writing product documentation or customer communications, we've had to consider how to refer to our Wi-Fi capabilities. For instance, do we call the protocol enabled by Elektron "WPA Enterprise", "WPA-802.1X", or "WPA-RADIUS". They're all the same thing, but different people might know one term but not another. We've settled on "WPA Enterprise", because that the official term coined by the Wi-Fi Alliance, but if you read our stuff carefully you'll notice we occasionally drop the other terms in there as well to make sure we've covered all of our bases.

The Wi-Fi Alliance has a nice glossary of terms if you ever get stuck.

SC Magazine has a good overview of the standards and organizations involved with Wi-Fi security.

Of course, standards are meaningless if developers don't bother to follow them. Microsoft co-developed the standard for PEAP, and later had to publish a second document that basically said, "gee, we know we said to do PEAP this way, but here's how we actually do it. Our bad!"

Now they are at work on a third version of PEAP, apparently because having two versions of PEAP is not enough. Meanwhile, Cisco — which co-developed PEAP in the first place — goes off on its own and develops EAP-FAST. I vote that we all agree to use TTLS and call it a day.

Naomi Graychase wrote about us in Wi-Fi Planet. For the record, it is indeed our standard policy not to enslave programmers.

Actually, the title here is a little misleading. These two browsers are still subject to the browser IDN vulnerability; it's the preference that turns off IDN that is fixed. Mozilla and its derivatives have long had preference option to turn off IDN support (and thus turn off the vulnerability), but there was a bug that prevented the option from working. Even with IDN support switched off, IDN was still turned on. That bug is fixed in a new version released today.

Internet Explorer got a brief reprieve from its security blues yesterday when it was the only major browser not vulnerable to the IDN/UTF-8 phising problem, but the fun didn't last. Today Microsoft released a slew of security patches, eight of which are marked "critical", including Microsoft Security Bulletin MS05-014, Cumulative Security Update for Internet Explorer.

If you watched the Super Bowl, you probably caught the Napster ads touting the fact the for $15 per month*, you can get the same amount of music for which you would pay $10,000 at the iTunes Music Store. John Gruber took the time to read the fine print behind the asterisk.

And now to segue into what makes this a post about wireless technology: over the weekend I caught a commercial from an outfit called Dirty Hippo that is giving away "free" ringtones and screen savers for cell phones. I don't normally pay attention to commercials like these (in fact, thanks to Tivo, I hardly watch commercials at all), but a little blurb at the end about "call us to cancel the service" caught my eye. If their content is free, then why would I need to cancel their service? Because it's not free, it's $1.99/week. Their website is great: "Free Ringtone* For Just $1.99 p/w".

In that vein, I am pleased to announce that Elektron is now free* for just $299.99 per copy.

The Shmoo Group has discovered a gaping security hole in browsers that support UTF-8 encoded domain names. This allows an attacker to spoof a legitimate website, and could lead even savvy web users to fall prey to phishing scams.

In a nutshell, the attack uses a specially formatted URL to direct the user to the attacker's page while displaying a different, legitimate-looking URL in the browser's URL field.

An example attack is given that sends users to what is apparently PayPal's site (at least, the browser says "www.paypal.com"), but is really the group's own, fake site.

The UTF-8 hole is a result of the fact that International Domain Names (IDN) will be resolved differently then they will be rendered visible to the user. The PayPal attack works because the name used, "www.pаypal.com", will be converted to "www.xn--pypal-4ve.com" before being resolved, while it will be converted to "www.paypal.com" before being displayed in the brower's URL field. The first 'a' in paypal is actually the unicode character #1072, which looks like an 'a' when displayed in most fonts. The Shmoo folks registered the "www.xn--pypal-4ve.com" name and now host their "PayPal" site there.

It gets worse: UserTrust issued an SSL certificate to the false website, so when you connect via HTTPS, the certificate checks out. It looks exactly as if you had connected to the secure version of PayPal's site.

Ironically, the fact that Internet Explorer has not had an update in a long while means that it does not support IDN, and thus is not vulnerable to this exploit.

This is an extremely serious break, and I'm sure that Apple and the Mozilla engineers are working on a fix as I write this.

I normally love Michael Howard's blog, but while describing a really cool feature in Microsoft's forthcoming compiler, he slips in this nugget, referring to a class stack smashing bug:

He's right, in a setuid program, this would be particularly bad. That said, most programs are not setuid (a UNIX feature that allows an administrator to configure a program to always launch with root privileges, regardless of the privileges of the user actually launching the program). Apple actively discourages the practice, and provides programmers with APIs to avoid having to use setuid. Mac OS X users are familiar with the "This application requires administrator access, please type your password" dialogs. That dialog is there so that program does no need to be setuid.

But that's not the half of it — saying that "the code can only run as you" means that for more than a few Windows users, the code is running as Administrator. Many (most?) Windows users log in to their computers as Administrator or as a user that is a member of the Administrator's group. So not only are most Mac OS X and Linux programs not running with elevated privileges, most Windows programs are.

The Wall Street Journal covers take-it-with-you access points. They cover the D-Link Pocket Router and the Netgear Travel Router. Only passing mention is made of the traveling access point I personally use, the AirPort Express. Streaming audio doesn't do me much good on the road, but its incredibly small form factor means that I can leave it in my laptop bag at all times so I never forget it.

Now that the initial release of Elektron is out and things have started to calm down a little around here, it's time to start figuring out what kinds of things we need to be working on for future releases. One obvious area of concern is Tiger, Apple's forthcoming revision to Mac OS X. We're a member of the Apple Developer Program, so we've got early access to Tiger builds. We're under NDA so we can't discuss specifics about the new OS, but we can touch on some of the subjects that Apple has already made public.

The first task in getting ready for Tiger is to make sure that the existing Elektron installation works. It does — albeit with a slight interface glitch in the Elektron Settings application. This should smooth the upgrade path quite a bit.

We don't want to stop with just being compatible. It would be nice to be able to support some of the new features in Tiger. ACLs don't apply much to Elektron since it's not a file service; ethernet link aggregation (where multiple ethernet interfaces appear as a single interface) comes "for free", that is, we don't need to do anything to our code to get support for this feature; Open Directory enhancements are likewise "for free". The new certificate management functions look promising. As the Apple web site says:

We already have all this support built in to Elektron. It would be nice to be integrated with the operating system's support for certificates. However, because Elektron will need to be compatible with Jaguar and Panther for some time to come, I don't expect that we will be dropping our built in code any time soon.

The really big Tiger news for server developers is the appearance of 64 bit applications. Recompiling your server as a 64 bit application gives you access to a much larger address space -- 16 exabytes rather than the 4 gigabytes available to today's applications. What's more, Tiger development tools allow you to create fat binaries (a term that should be familiar to Mac users who remember the 68K-PPC transition). With a fat binary, a server can run on both 32 and 64 bit versions of Mac OS X, automatically selecting the correct version of its code for the given platform.

But there's a catch: only System.framework will be made 64 bit. Frameworks are bundles of shared libraries that applications use to interface to operating system services (among other things). System.framework includes many of the core functions that a server needs, such as networking (the sockets API) and file handling (the POSIX API). Elektron, however, requires a number of other frameworks to run, most notably DirectoryServices.framework, which Elektron uses to communicate with Open Directory to perform user authentication. Without these frameworks moving to 64 bit, we would have to resort to a complicated, multi-tier application architecture. This is something we don't want to do.

The biggest win with a 64 bit Elektron would be increased computation speed for cryptography operations. The majority of CPU time spent handling a user login is in the RSA private key operations that must be performed to complete the TLS handshake that is part of the PEAP and TTLS login process. These private key operations use multiple precision arithmetic functions — that is, the numbers they are working with are 1024 bits (and up), far larger than the 32 bits supported by the CPU. This means that each arithmetic operation must be broken down into multiple 32 bit chunks. With a 64 bit application, the chunks can be, well, 64 bits in size, significantly reducing the number of chunks, and thus significantly speeding up the operations.

Since we can't go 64 bit, we've decided to skip it and go 128 bit instead. We're working on recoding our crypto routines to use Altivec. We've got an initial version completed, and it can perform an RSA private key operation approximately four times faster than the old code. It probably won't be in the next minor revision of Elektron as we want to test the hell out of it before shipping, but it should be ready "soon".

The moral of this whole story: we're not going to be doing much new for Tiger, because most of the interesting new features we get with no new work on our part. Doesn't mean it won't be great, though. Take a look at the Tiger product page, there is a lot of cool stuff coming.

Steven Levy gets to the bottom of the seemingly non-random shuffle play feature of the iPod. More than once I've had the "did I forget to turn on shuffle play?" experience when starting up a playlist, but statistics is a counter-intuitive science. If your iPod randomly picked a song by one artist in a playlist, it's just as likely to randomly pick the next song by the same artist as it is to pick any other song in the playlist.