Recently in security Category

I was recently asked why AIR fetches a Thawte CRL (from http://tss-geotrust-crl.thawte.com/ThawteTimestampingCA.crl) every time an application is installed--even if the application was signed with a certificate from another CA. It turns out there is a good reason for this, and the clue is in the URL itself.

By default, all AIR application signatures are timestamped. Timestamps are created by a timestamp server, and are themselves signatures. When AIR validates the timestamp signature, it downloads the CRL associated with the timestamp signing certificate--just like it would when validating any other signature. And the Thawte timestamp server uses a certificate that--no surprise here--has a CRL hosted by Thawte.

This default is easy to override using the "-tsa" option to the AIR file packaging tool, adt. A value of "-tsa none" turns off timestamps entirely. To specify an alternate timestamp server, specify the URL of that server after the -tsa flag.

For more on AIR code signing, including why timestamping is used, take a look at Code Signing in Adobe AIR.

New to the AIR 1.5.2 release (and the corresponding Flash Player, 10.0.32) is the LocalConnection.isPerUser property. Note that you'll need to update your application's namespace to .../1.5.2 to access this property. Here's why you should do that.

LocalConnection provides local (i.e., on the same machine) communication between SWFs and AIR applications. It operates via a shared memory segment that's visible to all processes that use the mechanism.When LocalConnection was first implemented on Mac OS, it used a memory segment that is visible to all processes running on the machine. This was reasonable at the time, but problematic now that Mac OS is a multi-user operating system. The unfortunate result is that LocalConnection can be used to communicate across user accounts on Mac OS.

To address this a new, per-user implementation has been implemented on Mac OS. You should always use this mode; it's safer. To do that, set LocalConnection.isPerUser = true on every LocalConnection object you create.

Unfortunately, AIR can't do this for you transparently. The problem is that, if it did, you could get into a situation where version skew breaks use of LocalConnection. For example, this can occur if an application is running on AIR 1.5.2 and attempts to communicate with a SWF in the browser running on Flash Player 9. Until both sides are updated, there's no way to use the isPerUser = true option. By adding an API and making this an option, we've given you a chance to migrate to this option without breaking anything along the way.

This issue is specific to Mac OS. Windows and Linux use a user-scoped LocalConnection in all cases, regardless of the isPerUser setting. You can safely set LocalConnection.isPerUser = true everywhere and be confident that the Windows and Linux behavior won't change.

Final note: The default setting of this property is likely to change to true in a future release, in order to be consistent with our general philosophy of defaulting to safe behavior.

Most certification authorities will issue certificates only to businesses. This can be a drag for individuals publishing applications on their own. If you're in that camp, you may want to take a look at ChosenSecurity's AIR code signing certificates, which are available to individuals.

No, I'm not receiving anything from ChosenSecurity for posting this.

GlobalSign is currently running a discount on Adobe AIR code signing certificates, selling one-year certificates for $99.

If your applications are publicly available, you should be using a CA-issued certificate, such as one from GlobalSign, VeriSign, or Thawte. This price is a discount of $130, making this a good time to make the switch. See Code Signing in Adobe AIR for more on why this matters, and Switching Certificates for information on how to transition from your current certificate to a new one.

For those who are wondering, no, I'm not receiving anything from GlobalSign for posting this.

Passwords remain de rigueur for authenticating clients, but applications with stricter security requirements may require an additional authentication factor. Adobe AIR-based applications can use client-side Transport Layer Security (TLS, also still referred to as SSL) authentication to add this second factor.

Many developers are familiar with the use of TLS in the HTTPS protocol to establish the identity of the server to which a client is connected. The server uses a private key to assert its identity, which is in turn validated via a trusted certificate installed on the client machine. What is less well known is that TLS authentication can be symmetric. The same certificate-based validation scheme can be used to authenticate both the server to the client and the client to the server.

The setup details will vary based on which web server and operating systems you're running. Still, here's a sketch of the steps involved to get it working. On the server:

1. Create or select a certificate authority that will issue certificates for each client machine.
   
2. Configure your web server to require TLS client authentication.
   
3. Configure your web server to trust, for TLS authentication purposes, certificates issued by your certificate authority.
   

Then, for each client:

1. Generate a private key for the client.
   
2. Generate a certificate signing request for the client, based on this key.
   
3. Create, using your certificate authority, a signed certificate for the client.
   
4. Install this certificate into the system trust store on the client.
   

Note that none of these steps are specific to AIR. AIR uses the underlying OS network stack for HTTP, HTTPS, and TLS support. All AIR TLS connections use the system trust store to look up certificates and access private keys. This helps produce consistent behavior across all applications on your machine, whether they are built on AIR or not. If you have an existing enterprise solution in place for managing the trust store, it also means you can re-use this solution to distribute and maintain certificates and keys for AIR applications, too.

The certificates used in TLS client authentication, by virtue of being installed on and tied to a specific machine, authenticate by proving something you have. This makes them a perfect complement to passwords, which are something you know. Together, they create a reasonable and available two-factor authentication scheme for your AIR applications.