Monthly Archives: March 2010

You are browsing the site archives by month.

Microsoft Word 2007 Freezing Upon Exit

Recently, my Word 2007 program started experiencing some weird behavior.  When I had a document open and would go to close Word, I’d be greeted by this:

Also, since I’m running Windows 7, when I tried to Right-click the Word icon that I pinned to my taskbar and open a recently opened document, Word would open, but not the document.  I would have to explicitly open the document from within the application.

Initial reports I read pointed to a recently installed patch, but instead of going through my “Programs and Features” uninstalling patches one-by-one, I found an even easier solution on Ed Bott’s blog.

NOTE: The following instructions deal with editing the Windows Registry, which is not for the incautious or faint of heart. It would be a good idea to back up your Registry and/or create a restore point before trying this.

If I haven’t scared you off, open Regedit, navigate to HKCUSoftwareMicrosoftOffice12Word and delete the “Data” Key.  (I did export the “Data” key first, just to be on the safe side.) After deleting the key, Word appeared to open and close properly.  I right-clicked the Word icon on my taskbar, chose a document to open and it opened right up. So far, so good.

I then merged the backed-up reg key back into the registry and tried opening that same recently-used document from the task bar – Word opened, no document.  Then upon closing Word, it crashed again.

From the information in Ed’s blog entry, the cause appears to be related to having Word running at the time a particular “Important” update is applied to the system. Removing this reg key fixed it right up! I saved at least 30 minutes by avoiding having to uninstall and reinstall Office.

Compelled Certificate Creation Attacks

Last October, we published a three-part series on SSL certificates: what they are, how they work, and how they’re used to secure transactions over the Web. You’ll find the series listed in our “Security” category. For most of us, this process has worked pretty well for a long time. But I recently ran across a paper by Christopher Soghoian and Sid Stamm that points out a vulnerability that, frankly, hadn’t really occurred to me before.

NOTE: I’ve chosen to place a copy of this paper on our own Web site, because I believe that the material is important enough that I wanted to ensure that it would be available even if the link I used to find it should no longer be valid. I believe that this is permissible under the Creative Commons Attribution license cited by the authors.

As we discussed in the previous series, the security of the public key infrastructure (“PKI”) that we’ve come to rely on ultimately depends on the trustworthiness of the Certificate Authorities (“CAs”) that grant the certificates. In general, a public CA (e.g., VeriSign) assumes some responsibility for verifying the identity of the person or organization requesting an SSL certificate. The level of verification performed depends on the type of certificate purchased. A small business purchasing a certificate that will be used to secure their Outlook Web Access site can get one pretty cheaply, and typically the issuer will only require that the requester be able to reply to an email message sent to the domain in question. On the other hand, Bank of America will go through a much more detailed process to get an “Extended Validation” certificate for one of their on-line banking servers (as well they should).

But if a bad guy could somehow obtain, from a trusted CA, a certificate for a Bank of America server, and then trick a user into visiting their fake BofA Web server, there would be no easy way for the user to know that something bad was going on - because the browser would indicate that a valid SSL session had been established.

Of course, any CA that knowingly issued such a certificate would risk irreparable harm to its reputation, punitive lawsuits, and potentially have its trusted status revoked by the major Web browser manufacturers. But, as Soghoian and Stamm point out in their paper, there are no technical restrictions that would prohibit a CA from doing so. So the integrity of the entire PKI and the security of millions of users’ communications ultimately depends on hundreds of CAs around the world choosing to do the right thing.

Now, I’m not particularly worried about VeriSign or GoDaddy, because I’m pretty sure they’re not going to cooperate in something like this without a court order (more on that later). But I didn’t realize that Microsoft, Apple, and Mozilla (Firefox) all include a number of national government CAs in their default “trusted root certification authorities” databases. For example, Microsoft’s program includes the governments of France, Korea, Latvia, Serbia, Tunisia, Turkey, and Uruguay, just to name a few. I’m sure that these government CAs are included for all the best reasons. But I’m not sure that I’m particularly comfortable with the idea of having my browser, by default, trust the government of Turkey with the blanket power to issue SSL certificates for any Web site. Correction - I’m sure that I’m not comfortable with that!

Why? Because the possibility is very real that some government, somewhere, might compel a CA to issue a false certificate that can then be used to perform a “man-in-the-middle” attack for surveillance purposes. In fact, as Soghoian and Stamm point out, there is evidence that this has already been done. (If you want the details on that, read their paper.)

As a result, they are working on a Firefox add-on that is currently known as “CertLock.” Certlock will keep track of the country of origin of the root CA of each Web site you visit, and if, on a return visit, it detects that the certificate being presented chains up to a root CA in a different country, even though your browser may trust that CA, it will warn you. For example, if your banking site uses certificates issued by VeriSign, which is a US-based CA, CertLock will store that information the first time you go to your banking site. If, on some future visit to that banking site, the Web server you hit presents a certificate that - although it appears to be valid - is chained to a root certificate issued by Etisalat in the United Arab Emirates, you’ll get a warning, and a chance to abort the connection.

Is this a perfect solution? No. Admittedly there are some scenarios that won’t be caught - but those are arguably not that significant anyway, with the possible exception of #4 below. To use a few of the examples cited by Soghoian & Stamm:

  1. Assume that the US government compels VeriSign to issue a certificate for use by a law enforcement agency wishing to intercept communications between a suspect located in the US and his/her US-based bank, which uses VeriSign certificates on all its Web servers. CertLock won’t detect that, because the CA issuing the fake certificate is the same CA that issued the legitimate certificates.

    However, if the government can get a court order compelling VeriSign’s cooperation, it could just as easily - and probably more easily - get a court order directly compelling the bank to disclose the suspect’s account information. So there’s little point in the exercise.

    The same holds true if the bank’s legitimate certificates were issued by, say, GoDaddy instead of VeriSign. They’re both US-based CAs, so CertLock won’t detect the attack - but, by the same reasoning, it’s still a moot point.

  2. Assume that a resident of China is accessing his/her online account with a Chinese bank that obtained its legitimate SSL certificates from VeriSign. Assume further that the Chinese government is interested in intercepting the suspect’s online transactions, and compels the China Internet Network Information Center (“CNNIC” - a domestic Chinese CA) to issue a false certificate for the operation.

    In this scenario, CertLock would detect the attack - although, again, it’s an improbable scenario because the Chinese government could just as easily compel the Chinese bank to provide the suspect’s account information.

  3. Assume that a US executive is on a business trip to China, and is attempting to access his/her gmail account from a hotel Internet connection. Once again, the Chinese government could compel CNNIC to issue a false certificate to employ a man-in-the-middle attack, since they have no leverage to compel the assistance of VeriSign, which issued the legitimate SSL certificates. This attack would be detected by CertLock.
  4. Assume that a Chinese executive is on a business trip in the US, and attempts to access his/her Chinese bank account from a hotel Internet connection. If the Chinese bank was using legitimate VeriSign SSL certificates, and if the US government obtained a false certificate from VeriSign, there would be no way for CertLock to detect the attack.
  5. Since American CAs dominate the certificate market, and are used by many foreign organizations, that last scenario is far from hypothetical, and would seem to give the US an edge in potential intelligence-gathering.

    So the bottom line is that the approach taken by CertLock is not perfect. But it’s a step in the right direction, and I’ll be downloading it as soon as I can get my hands on it. In the meantime, particularly if you’re interested in security issues or if your job includes security-related responsibilities, I’d heartily recommend that you download and read the entire paper. Although it’s a bit complex, it’s only 19 pages long, so it shouldn’t take you more than two cups of coffee to get through it.

Potential Port Conflicts with Citrix License Server 11.6.1

A couple months back, I was working on a XenDesktop 3.0 installation.  The customer was having some issues with licensing, so my first thought was to upgrade the license server to the newest version - because historically that’s been the recommended first step in dealing with license issues.  In this case, though, it turned out to break other things - but in the end gave us some very valuable information.

First, a little background information.  XenDesktop uses an agent on the virtual workstation images that communicates with a server piece called the Desktop Delivery Controller (“DDC”).  This agent/server communication happens on TCP port 8080.

Unfortunately, in this specific case, the Citrix License Service was running on the same server as the DDC service. And in the latest version of the license server service, Citrix changed the port that the License Management Console uses to communicate with the license server to…yeah, you guessed it: 8080.

This conflict prevented the XenDesktop machines from checking into the DDC, so the DDC, which, as you might infer from its name, is the broker service that controls the delivery of virtual desktops to client devices that request them, viewed them all as “offline”.  It therefore believed that there were no virtual desktops available, so no connection requests were being serviced. In technical terms, this is what we call a “bad thing.”

The solution in this case was to change the port that the License server and License Management Console communicate on to port 8082 – which just happens to be the port it used in previous versions… hmm…

It should be noted that this can affect more than just XenDesktop Agents.  Port 8080 is heavily used for other Citrix functions, such as the XML service.  Why Citrix would change the license service to port 8080? Why do people jump out of perfectly good airplanes? Guess it seemed like a good idea at the time…to somebody, anyway.

Once we started digging for it, we found detailed steps on editing the license server configuration in the License Server 11.6 readme, and it’s obvious from the text that Citrix knew using port 8080 could cause conflicts:

When you install the license server components, version 11.6.1, on the same server as other Citrix products, the License Management Console is configured to use port 8080, by default, which may conflict with the other Citrix products (for example, they may use the Citrix XML Service which may use 8080 as well). To resolve this issue:

  1. Navigate to C:Program FilesCitrixLicensingLMCtomcat
  2. Open the file in Wordpad.
  3. Replace the port number (8080) in the following line with 8082:
    <Connector port=”8080″ protocol=”HTTP/1.1″
    connectionTimeout=”20000″ redirectPort=”8443″/>
  4. Save the file.
  5. Reboot the server.

The other way we could have solved the problem, of course, would have been to move the license service to a server that had no other Citrix components running on it. We generally recommend that as a best practice, if at all possible (although we realize that sometimes it isn’t).  It just makes things easier in the long run.

Citrix Branch Repeater VPX Is Here

Earlier this month, we wrote about the Citrix push to virtualize many of their hardware appliances, the release of the Access Gateway VPX, and the pending release of a virtualized version of the Citrix Branch Repeater - their WAN optimization appliance.

The Branch Repeater VPX is now available. As you might expect, it is less expensive than its hardware counterparts, although, like its hardware counterparts, it is licensed based on the WAN bandwidth capacity it can handle. Here’s how it breaks down at the MSRP level:

Branch Repeater VPX Model 2 (2 Mbps): $4,000
Branch Repeater Model 200 (2 Mbps): $6,000

Branch Repeater VPX Model 10 (10 Mbps): $7,000
Branch Repeater Model 300 (10 Mbps): $10,000+ (depending on options)

Branch Repeater VPX Model 45 (45 Mbps): $13,000
Citrix Repeater 8540 (45 Mbps): $19,500

Furthermore, and this is a major change, all versions of the Branch Repeater VPX (even the $4,000 Model 2) will support the Branch Repeater Plug-in for the Citrix Receiver, meaning that they will accelerate connections from individual PC clients running the Repeater Plug-in. If you’re using physical appliances, you must, at a minimum, have a Citrix Repeater Model 8520, which lists for $11,500. That’s very good news for smaller customers.

As is the case with the Access Gateway VPX, the Branch Repeater VPX depends on the underlying HA functionality of XenServer to provide High Availability. (Note that Citrix has stated its intent to support other hypervisors, but the initial release is only supported on XenServer.)

There is also no indication that there will be a virtualized version of the Branch Repeater with Windows Server (hereafter the “BRwWS” to conserve electrons). After a bit of reflection, that probably makes sense. After all, the BRwWS is intended for customers who need to support services like Domain authentication, DNS, DHCP, print services, etc., at branch offices, but do not want to place traditional servers there. If you’re running a virtual appliance, then, by definition, you have at least one (and probably more than one) virtual host at that location. Therefore you are already supporting traditional server hardware there. And you probably already have other virtual servers running on those hosts and providing the needed services (and if you don’t it’s easy enough to stand one up).

One final note about the BRwWS, while we’re on the subject: Branch Repeater with Windows Server 2008 is now available. Therefore, the Branch Repeater with Windows Server 2003 will no longer be sold as of July 31, 2010.

Citrix Subscription Advantage

I’ve noticed a pattern developing: It starts with a renewal notice, usually around 90-days before Subscription Advantage (SA) is set to expire. The reply email comes back within 48 hours: “What is Subscription Advantage?” I answer and then comes question #2: “Why do I need it?” So I think it’s time once again to shed some light on this mystical annual renewal.

Subscription Advantage IS NOT MAINTENANCE!

Subscription Advantage  IS NOT SUPPORT!

Subscription Advantage IS NOT A WARRANTY!

Ok, now that that is out of the way we can focus on what SA is because it is important that you know exactly what you are paying for. Citrix SA is annual license upgrade protection. The first year is included with your license purchase - after that, there’s an annual renewal cost. What does that mean? Well it means that you bought something that is not a set-it-and-forget-it item. Data centers grow and change all time and the tools used in that data center need to change as well. So as the Citrix products evolve (or change names) you as an owner of “upgrade protection” can take advantage of these upgrades, period.

(There is one exception: it is now possible to purchase a bundle of SA and Citrix telephone support for XenApp. We covered this in an earlier blog post.)

The good news is that Citrix SA doesn’t cost as much as traditional “Software Maintenance” from companies that bundle some kind of telephone support with their upgrade protection. The general rule of SA is that it costs about 11% - 13% per year of the cost of the license. In our experience, traditional Software Maintenance that includes support will typically run you 18% - 20% per year for 5 x 8 support, and 25%+ per year for 7 x 24 support.

However, if you have not renewed your SA and wish to upgrade you will need to pay a reinstatement fee or just buy new licenses. Which option is best for you will depend on how long it’s been since you renewed SA. If your SA has been expired for more than a year, it’s going to be pretty expensive to try to get it reinstated.

Citrix upgrades its products often! So what if I have my own Citrix expert on staff and don’t plan on upgrading for 5-6 years anyway? Well, as we all know, life is what happens while you’re making other plans. What about the rest of your data center? Do you not plan to upgrade that in the next 5-6 years either? In many cases old versions of Citrix products will not be compatible with new technology releases. E.g., Citrix just released XenApp 6, which is specifically designed for Windows Server 2008 R2. Earlier versions of XenApp are not compatible with 2008 R2.

Also, Citrix frequently releases “Feature Packs” for older product versions that add functionality (within the technological constraints of the older platform). If your SA is current, you can take advantage of the new features. If not, you…can’t.

Finally, no software company can afford to indefinitely support every product version that they’ve ever released. Everything has a lifecycle. For example, Presentation Server v4.0 hit the “End of Life” point at the end of 2009. That means there is no support available for the product other than the information you may be able to dig out of the Citrix on-line Knowledge Base. Furthermore, all the downloads have been removed, so you have no way to access any security patches, service packs, hotfixes, etc. This is obviously not a good situation for your production environment - so if you’re still running Presentation Server v4.0, you should be working toward upgrading your environment as soon as you possibly can.

Bottom Line: I recommend SA renewal to everyone who buys Citrix licenses. As the person who handles all the renewal notices for our customers, I have, time and time again, seen people try to save a dollar this year but end up spending more then necessary next year. Plus it is just a headache to realize that you need to upgrade - perhaps to solve a problem that (naturally) surfaced after hours or on a weekend - but can’t get the upgrade because your subscription has expired. So, when you get that email notice from me, just remember: I’m really trying to make your life easier by insuring that you’re upgrade rights are protected!