Dan Griffin's Blog
Comments on security, PKI, smart cards, cryptography, and entrepreneurship.
Jungle Disk
August 28, 2008
Jungle Disk (JD) is an interesting power tool - it lets you treat Amazon’s S3 “cloud” storage service as a local network drive.
A few things about JD caught my attention. First, it’s cheap - only $20, and that’s after a free 30-day trial. That’s pretty cool.
Second, JD requires users to register directly with Amazon for an S3 account. That’s an interesting tradeoff. On one hand, it greatly simplifies JD’s billing and business model. On the other hand, it limits their target audience to people who are willing, and sufficiently sophisticated, to not only learn about Amazon web services (AWS) but also to sign-up.
Third, I noticed in an early newsgroup post that JD’s creator had added an encryption feature for the data at rest. Then I noticed that they provide sample code for reading and decrypting the data, targetted at those users who, rightly so, are paranoid about not being able to decrypt their data if Jungle Disk goes out of business. This was a nice gesture.
In fact, I now notice that the JD home page says, prominently, “Your data is fully encrypted at all times.” It was this claim that prompted me to sign-up with AWS and install the JD free trial to check things out.
When you first run it, JD prompts for your AWS “access” and “secret” keys. It then stores this data locally in the %userprofile%\AppData\Roaming\JungleDisk\jungledisk-settings.xml file. Interestingly, the AWS secret key is not stored in plaintext form. I see that the JD program binary imports Crypt32!CryptProtectData, so my guess is that they’re using the Windows Data Protection API for this (obviously, only some of this analysis will apply to the Linux version of JD). The DPAPI encryption is based on the Windows logon password. Thus, if you can logon as the user, then you can decrypt his/her DPAPI data. Still, JD has made appropriate use of that feature in this case - nice!
The next thing that JD does during initial configuration is prompt the user to choose between “Standard” and “High” security for the cloud data storage. The High setting requires a user-supplied password, which is then used as the basis for the file encryption key. Unfortunately, Standard is the default, in which case a default password (which appears to be “Bucket Password”) is used. That’s equivalent to no encryption. Yes, the data has been run through a cipher algorithm, but that’s only as good as the secret material used as the basis of the key. No, the problem isn’t that JD provided sample decryption code. The problem is that users need to use strong passwords.
One side note about that sample code, though. There’s heavy use of MD5, including in the key derivation. That’s bad; MD5 is insecure.
Finally, that security settings page also mentions that data in transit is protected by SSL, which is pretty cool. I hadn’t realized that S3 offered HTTPS. That prompted me to do a network capture of copying a reasonably sized (4 MB) local file to the JD drive.
First observation - JD copies data in the background. That’s mostly good, because I’m guessing that the latency for command-line access would be horrible otherwise. On the other hand, that means that, while my brand-new file shows up in a directory listing of the JD drive, it’s not actually fully copied to the cloud yet. However, JD anticipated this challenge by providing a systray application that shows pending transfers. Mine advertises a little more than 300 kilobits per second on a basic DSL connection. Thus, my 4 MB file took around 2 minutes to upload.
Anyway, having confirmed the SSL (TLS, actually; I checked) transfer, I wondered what the data transfer would look like with transport security disabled. Turns out the JD monitor/systray application exposes that option, so I disabled it and copied another file. Sure enough - there’s my AWS access key in plaintext, as well as the signature based on my secret key. More on AWS authentication can be found here.
Permalink | Comments (3)How to get into any club - this is a riot
August 15, 2008
What a huge surprise, right?
Over the course of building a Microsoft Message Queue based C# application recently, I’ve picked up some best practices. I also found quite a few MSMQ/C# resources on the web that either didn’t do what I wanted or were too outdated to apply. It’s also possible that they were just wrong from the beginning.
My environment is this: a workgroup-based Windows Server 2003 Standard machine, .NET 3.5, and two C# applications. One sends messages, and one receives and processes messages using asynchronous routines. The test user is a local administrator.
The first thing I tried was to run this scenario on my Vista SP1 development machine. Big mistake. The machine is domain joined, but the first time I installed the MSMQ components I forgot to select the checkbox for AD Integration. At this point, my code for using a private queue wasn’t working correctly yet. Then I realized what had happened, uninstalled the MSMQ components, reinstalled with AD support, and tried again. No luck. In fact, after the reboot, the MSMQ components aren’t present at all! I’ve tried several times; the installation rolls back at some point after I authorize the reboot, and afterward, it’s as though it never happened. You kind of get the impression that MSMQ is more of a server SKU component. Has anyone else seen this?
I abandoned Vista, moved to the WS03 machine, and started making forward progress. I quickly learned that the Message Queuing node in the Computer Management MMC is your best friend. Click Start | right-click My Computer | Manage | Computer Management (Local) | Services and Applications | Message Queuing. If you create a queue like mine below and pump some messages into it, you’ll subsequently see a Private Queues | myqueue | Queue messages sub-node, where you can inspect all of the messages. More on what I learned from that in a second. There’s lots of other stuff you can do in that snap-in node; play with it for a bit if you’re new to the technology.
It’s true that workgroup machines really do only support private queues. The reason is that the information for registering and finding public queues is stored in Active Directory, and of course, Microsoft wants to give you lots of reasons to deploy AD. Actually, the workgroup machine limitation is pretty common knowledge, but I saw lots of posts confusing the syntax of private queues. This worked fine for me:
private static string queuePath = @".\Private$\MyQueue";
Then queuePath can be passed directly to the System.Messaging.MessageQueue constructor, for example. Contrary to what I read elsewhere, the explicit DIRECT syntax is not required.
On a related note, the MessageQueue.Exists method (when passed the above string, for example) does work on private queues. I saw lots of posts claiming that it only works on public queues. Not so.
Next: nearly every example on the web shows the use of the MessageQueue.Send method with simple, intrinsic types. In fact, they pretty much all use “string”. One source of potential confusion about Send is that it takes an argument of type object. So, as evidenced by those examples, it’s legal to pump pretty much anything through there.
But best practice is actually to use the Message type and send that. Your payload should be the body; you can pass it to the Message constructor. The key here is that Message has various attributes that are critical for debugging, including UseDeadLetterQueue, UseTracing, UseJournalQueue, and Label. In fact, the latter - Label - is visible in the “Queue messages” display in the MMC pane that I mentioned above. That alone is a huge help for debugging, because you can identify what’s sitting in the queue just with a quick glance.
There’s more, though. I’m sending custom class objects through the queue, but I was originally trying to do so with without encapsulating them in a Message, and it just wasn’t working (messages were stuck in the queue). I didn’t try all possible permutations of the following to identify the exact cause, but I now recognize all of these things as best-practice.
When I opened some of the undelivered messages in the MMC snap-in and examined the payload, I noticed that the XML formatter was being used by default, and that the type was correct. But the private class data fields were missing. The documentation for the XML formatter indicates that, by default, it should pickup all private and public members of a serializable class, excluding those members explicitly marked non-serializable. But my data fields, all marked private and implicitly serializable, were being excluded. Changing them to public fixed that problem.
Next, although I couldn’t find this stipulation in the official docs, there seems to be a requirement, at least when using the XML formatter (again, that’s the default), to specify the allowed types to be passed in the message body. This is done via code such as the following:
queue.Formatter = new XmlMessageFormatter(targetTypes);
where targetTypes is an array of all of the possible types you want to support in your message body. It’s natural to define a common interface for those message-type classes to implement, but I found that you can’t just specify the interface type to the XmlFormatter constructor, above. Actually, I was getting inconsistent results here; some of the inherited types were working and some weren’t (i.e. couldn’t be delivered). Explicitly listing all of the class types in the targetTypes array fixed that.
Thus, even though the XML formatter is the default, any implementation of reasonable complexity is going to have to set it explicitly, due to the requirement of listing your types. As an aside, for small messages in a scenario such as this, XML is way overkill. Don’t be surprised if your messages are ten times the size they’d be versus using the binary formatter.
One thing I thing I found frustrating is the lack of solid, asynchronous MSMQ programming examples in the Microsoft documentation. From the perspective of the designers of the CLR, what are the implementation patterns that are expected to yield the best throughput?
My approach is a simple one. I expect the most load to be on my message receiving side. On the main thread of the receiving application, I perform the following operations:
- Open or create the queue
- Create a stop event
- Add a ReceiveCompleted event handler
- Initiate the first BeginReceive
- Wait for the stop event to be signalled
In the ReceiveCompleted event handler, I first grab the caller context, since that’s where I store the queue reference, among other data. Then call EndReceive on the queue to get the message. Then, before handling the message, immediately call BeginReceive again. That’s a critical step, because it allows other threads to continue to take incoming messages in parallel. If a Stop message is received from the sender, set the stop event and the main thread ends.
One final note: various resources on the web indicate that other settings changes must be made in order to get basic MSMQ scenarios working. For example, DTC and DCOM settings. For this scenario, that’s not required.
Permalink | Comments (0)Open Vulnerability Assessment System
August 14, 2008
Just announced is a new, open-source alternative to Nessus, which went closed source about two years ago and has continued to make people irritated by bumping up the subscription price of their vulnerability feed (even for non-for-profit use!).
Check out the announcement here.
Permalink | Comments (0)A sweet piece of hardware
August 12, 2008
I rarely blog about purchases or computer equipment unless something is either really good or really bad. Just wanted to drop a note that the NetGear HD/Gaming 5 Ghz Wireless-N Kit fits the former category. I literally took the two APs out of the box, plugged them in, and they just worked. Not only that, but they arrived three days earlier than expected from Amazon!
I bought them to support working from a room that currently lacks CAT-5 support. I had previously been using an old 802.11b router from LinkSys. But copying even small network files was a challenge, and streaming music while I work was impossible in that configuration. Making matters worse was the fact that I was using the in-box WiFi driver on my Vista laptop, along with the built-in (laptop) antenna. Not a recipe for success or reliability, even though the distance is only about 25 feet.
To bring up the new NetGear, I plugged the first unit directly into a CAT-5 wall socket that runs upstream. Then I plugged the other one into a four-port switch which it now shares with the laptop. I prefer that because the presence of the switch makes it easier to temporarily connect other computers at this desk if I need to.
One of the best features? As part of the auto-configure process implemented by the NetGear APs, the upstream one immediately detected the presence of an existing DHCP server. As a result, it’s now easier to ensure that my Vista laptop always has the same IP, regardless of whether there’s a wireless link between it and the internet.
Now high-fidelity audio streams flawlessly from elsewhere on the LAN, and has no noticeable effect on the connectivity of other apps. Copying really big files, such as ISO downloads from the internet, is still painful. But the state of the art is such that, if you need to copy big files, then you need to invest in Gb ethernet, and I’ve come to terms with that …
Permalink | Comments (0)Increased demand forecast for physical security systems
August 6, 2008
This post is one of a few that references a Freedonia Group market research report that came out this Spring.
Unfortunately, I wasn’t able to get my hands on a full copy of the report at my local university business library. But the summary is that the market for physical security systems is expected to grow almost 8% annually for the next four years.
Permalink | Comments (0)Hyper-V has a convenient feature that allows you to take a screenshot of whatever the selected guest OS is displaying in the viewer window.
Just popped into my head that that’s another way to circumvent Rights Management Services. For example, to duplicate protected emails and documents. After all, the image is copied to the host’s clipboard; the guest isn’t aware of the action, so it can’t block it. Anyone tried this?
Permalink | Comments (0)It’s fairly old news now that Kevin Johnson, the former President of the Microsoft platforms division - basically, Jim Allchin’s replacement - left MIcrosoft to be CEO of Juniper Networks. This post was one my favorites on the subject. I also like the comment I read somewhere that, compared to Johnson’s old job, Juniper might as well be Jupiter. I happen to disagree with that, but it’s clever.
Early in his tenure as President at Microsoft, Johnson made a comment that really struck me. A concern shared among a lot of conscientious folks on the Windows engineering team, myself included, was that the team was too big for its own good. This was before codename-Longhorn became Vista and that whole mess, a devolution that proved our concern valid like nothing else could have.
Anyway, at the time, Johnson said something to the effect that he agreed, and that he felt it would be wise to reassign engineers to other projects. It was a candid comment for someone at his level. An over-simplification of a complex problem, of course. Nevertheless, I remember thinking to myself, “Wow, this guy really knows what’s going on in the trenches.”
In retrospect, the Windows team, like most of those behind products that are successful in the market, seems to only grow. And the other problem - the Windows release cadence - doesn’t seem to be improving either.
The impression is therefore that KJ made an initial splash, but not much after that. He did well enough to earn a mid-sized CEO gig: probably less than he was dreaming about, but still not bad.
One more thing: some commenters have suggested that he left because the failed Yahoo bid meant he wasn’t getting Ballmer’s job. The situation is more complex than that.
On one hand, much to the chagrin of Microsoft’s shareholders, Ballmer wasn’t fired by the board after just a year or two. It was thus obvious that his successor, whoever it was going to be, was going to have a long wait. Performance apparently isn’t a factor in keeping the top job.
On the other hand, at this point, Ballmer’s open-ended stay is also secured by the fact that there aren’t stronger candidates waiting in the wings. If it was going to be KJ, too much of his reputation was staked on Yahoo. And the other potential future CEO, Eric Rudder, isn’t prepared yet.
Permalink | Comments (0)
