Monday, May 31, 2010

How Developers “Extended” the Vail Launchpad

Vail LaunchpadIf you’re a developer and you’re interested in writing something for Windows sHome Server, our Lead Developer Dileep has another tip for you on how to extend the Vail launch pad.  Dileep has had a previous post on the location of the SDK for Vail and how you can get involved.

Most recently, Dileep appeared back on the Home Server blog with how to extend the launchpad, and when you should extend the Launchpad.  You can read that blog post here.

If you haven’t been on the forums already, I did a forum post on why we created the Launchpad, with feedback from you, the customer.  Dileep extended on this, copied here for your reading convenience.

What is Launchpad?

Launchpad is a light weight and extensible client-based user interface that we built for Vail. It was born out of a couple of pain points that our customers experienced from Home Server v1. While Home Server v1 provided the ability for developers to add what we call ‘administrative’ or ‘server management’ tasks to the Admin console, it did not provide any means by which a day-to-day or non-administrative task could be presented to users in a coherent manner that resonates its association with Home Server. As a result we started seeing add-ins for day-to-day consumption of home server capabilities that were deployed to Admin Console, but did not belong there since they were not administrative tasks. We realized that there is a need for providing a coherent and consistent grouping as well as entry point for home server related tasks that everyone in the household can perform from their client PCs. This was the first pain point.

The second one, and perhaps the more significant one of the two, was the limitation around having matching usernames and passwords on the server and the PCs. If you recall, in Home Server v1 we require users to create user accounts on the server that had the same username and password as that of the client PCs so that they can seamlessly access the shared folders on the server as soon as they login to their PCs. This generated lot of confusion with consumers, as was evident from the feedback that we got. With Vail, Launchpad acts as the login UI for signing the user onto the server, thereby granting them access to the Server shares and other platform services exposed via the SDK. We no longer have the requirement to have the user accounts matching on server and client, instead users can use Launchpad to ‘sign-in’ to the server with any user account and password combination that was set up in Dashboard!

In short, Launchpad serves the following purposes:

  1. It is the entry point for the day-to-day tasks related to Windows Home Server from the client PCs.

  2. It eliminates the need for matching usernames and passwords setup between server and client, and eliminates the password sync dialogs.

  3. It Provides a logical and centralized location where all home server related tasks are exposed, resulting in much better awareness of home server and its capabilities.

  4. It allows everyone in the household to have visibility to developers' add-ins, than just home server administrators.

So, if you’re a developer, head on over to Dileep’s full post, and start coding up some cool apps that will make users love your add-in, and increase the value of Vail.  I know I’ll appreciate it when we ship!

Monday, May 17, 2010

Understanding SSL Certificates for client to server encryption

Back in January I made a post, which I called Part 1 of Understanding Certificates.  In this post I talked primarily about how the server is authenticated to the client by using a “root” certificate that the client already trusts, thus establishing a trust relationship with a website you are at without actually having been there before.  If you haven’t read it, it’s a good overview on how that works.

In this Part 2, I want to talk about the encryption between client and server.

Part 1 was all about authentication of the server, this part (2) is going to talk about the encryption portion.  Encryption is important on many networks to prevent prying eyes from seeing the data being sent.  The larger and/or more un-trusted the network, the greater the need for encryption.  The Internet of course being the largest of all public and un-trusted networks.

First the easy stuff, when you go to an SSL based website, you’re using the prefix of HTTPS in your browser.  Additionally, many mainstream browsers such as Internet Explorer or Firefox will show a “Lock” symbol to show that your connection is locked, and safe:

Internet Explorer

(Internet Explorer)

(Fire Fox)

Each browser will show it differently, but I think most of the mainstream one will use a little lock icon.  You might also see different colours (Red means bad, white or Green mean good).  While we’re on the subject of colours.  Some SSL certificate providers will provide you with extra security and extra validation, which will make the address bar go green.  In the captures above it’s important to note that Firefox and Internet Explorer use a completely different certificate store.  Internet Explorer uses the built-in Windows Certificate store, while Firefox manages its own.  There are pros and cons to each approach, but both are just as secure.

So how secure are you?

Well, in the details of the certificate, you can check out the encryption level of the certificate by looking at the public key:

Public Key


This certificate used here for passport is a 1024-bit encryption level.  This means that the keys used to encrypt or decrypt this traffic uses a 1,024 character key length.  That means that in order to decrypt this network traffic, you need 1,024 ASCII based characters in exactly the right order.  That’s a tall order to boot!!  Anything less than 1024 at the time of this printing is not considered industry standard encryption.  Hackers have horse-power to crack 512-bit certificates in just a few weeks, this isn’t new news, this has been done back in 2002!  It also states that even 1024 can be cracked, but it would take a lot longer, given the cracking method used is “Brute Force”. It would take a large number of years to crack this, and you’ll notice if you review your certificates, they are only used for 1 year, and then the key is changed with a new certificate, forcing your hacker to start over.

However, with the introduction of this, 2048-bit certificates are already shipping today.  The bigger the number, the harder it will be to decrypt. What’s the hold up?  Processor power.  Not necessarily in your PC, but on your phone, in your router, even on the server processor!!.  Using higher-level encryption, means that each packet sent over the internet needs to be encrypted on one side, and decrypted on the other.  Does your phone have the processor to deal with higher level of encryption? what about servers that process millions of requests per second, that would double the CPU load for decryption/encryption!  So don’t be surprised if you see 1024-bit for a while longer: it’s still considered industry standard.

You may notice that root or chaining certificates last longer.  This is because their public key is typically not out in the open for all to see, and potentially use to hack.  So it’s generally accepted for these higher certificates to have a longer lifespan.

But how does it work Technically?

Let’s dive into how it works.  When you buy a certificate from a 3rd party, they ask for a CSR (Certificate Signing Request).  The website generating the CSR generates two pieces of information:

  1. The Public Key
  2. The Private Key

The public key is encoded in this request, along with the final public public certificate.  The certificate provider validates that this is in fact the server it’s issuing a certificate for (the more expensive the certificate, the more validation is done).  The private key NEVER EVER leaves the website generating the certificate.  Think of a mailbox that the post office runs that sites outside the convenience store.  the public key is the slot in the top.  Anyone can get access to that to send stuff into the post office, but the key to open and get access to all this sent mail, only the post office has, and never leaves around anywhere.

Once the certificate request is signed, the public key is placed right on the website for all the world to see, and the private key is kept safe inside the certificate store, hidden from view and access only to administrators!

The private key is used to decrypt everything encrypted with the public key, and vice versa.  Additionally, a per-session key is established and everything is encrypted using that as well.  This prevents when the server sends something to the client encrypted with the private key, any listening clients from decrypting it with the very public “public key”. If you want to go deeper,  you can dive into the nitty-gritty details over on Wikipedia on Transport Layer Security.

What if something goes wrong?

If something goes wrong, or something changes, a certificate is revoked.  A client will check the CRL (Certificate Revoke List) embedded in the certificate to see if the current one is still valid.  If a website cert has been compromised, or a name changed, or anything changed, the certificate is revoked and another one issued.  Clients will know which one to use simply by checking the CRL distribution point.


Here we see that Verisign has their CRL hosted up online that anyone can go and see if this cert is revoked or not.  Clients will known not to trust or use a revoked certificate.

imageRemember, if you end up at a site that has a certificate that you don’t trust and your address bar in Internet Explorer is red (after you mistakenly continued onto the website), you’ll still get the encryption between the server and the client, BUT you won’t know for sure you’re talking to the right server.  So you should ALWAYS make sure you do not continue onto these types of servers.  Even if you *think* it’s going to the right place.  Imagine if it’s not, and you logged in with your username and password.  You just gave your username and password to some random site! 

Be careful out there, look for the lock icon (image), look for the https:// in the address-bar, and be  weary sending personal information anywhere!!

Friday, May 07, 2010

Calling All Developers–Windows Home Server “Vail” needs you!

Do moreA few weeks ago, we released the Home Server codename “Vail” public preview.  Along with that came a software development kit.  Like Windows Home Server version 1, the product is extensible, and we need add-in developers!!  We’ve put a great deal of effort into the improvement of the extensibility of the product. 

Over on the Home Server blog, Dileep, our Development Lead talks about how to jump in and get engaged.  Keep your eye on the official blog for updates as it is a planned series to help you get involved.  If you want to jump straight to the SDK, you can download the complete set of information here (You will have to sign in to Microsoft Connect site).  Any questions can be posted in the developer forum.

UPDATE: See what others are saying about the SDK.