Its not easy to determine by looking at a file extension whether it would carry a certificate or not. I am writing this article to help myself . Next time I can directly jump to my blog instead searching endlessly what does a specific file extension corresponds to.

I will be discussing file extensions related to certificates . This would give you some idea on what are the different types of certificates that exist. My area of expertise is in IIS, so I would be discussing related to that mostly.

SSL certificates are being used for various purposes such as:

v Authentication, The digital certificate is a common credential that provides a means to verify the identity of either the sender or the recipient.

v Privacy, which ensures that information, is only available to the intended audience. Certificates enable privacy of transmitted data using a number of different methods

v Encryption, which disguises information so that unauthorized readers are unable to decipher the message. On computers, sensitive data in the form of e-mail messages, files on a disk, and files being transmitted across the network can be encrypted using a key.

v Digital signatures, it provides strong evidence that the data has not been altered since it was signed and it confirms the identity of the person or entity who signed the data.

Different types of Certificates:

Different file format exists for certificates based upon how they are encoded and what information store. They can be classified as ones that contain the private key and the ones that doesn’t. We have many certificate file types that are supported on Windows. The most commonly used file type which allows private key to be exported is the .pfx/.p12 extension.

Certificate Signing Request (.csr)

This file type is sued by applications to submit requests to the Certification Authority or CA. The request can be base64 encoded as shown below and is enclosed between "-----BEGIN NEW CERTIFICATE REQUEST-----" and "-----END NEW CERTIFICATE REQUEST-----".

 Base64-encoded X.509 Certificate (.cer or .crt)

The Base64 format supports storage of a single certificate. This format does not support storage of the private key or certification path. They are Base64 encoded ASCII files. The encoded string is enclosed between "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----". Right click and open a certificate (exported in the base 64 format) in a notepad:

This file type is used more often for exporting certificates.

DER-encoded binary X.509 Certificate (.cer, .der or .crt)

The Distinguished Encoding Rules (DER) format supports storage of a single certificate. This format does not support storage of the private key or certification path.

DER is on of the encoding formats defined by ASN.1 in X.690. It is a variant or a subset of BER. You can refer the following Wiki article for further read:

• http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules#DER_encoding
• http://tools.ietf.org/html/rfc2986#ref-14
• http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf

Cryptographic Message Syntax Standard (PKCS#7) Certificate (.p7b, .p7r or .spc)

The PKCS #7 format supports storage of certificates and all certificates in the certification path. A PKCS #7 file typically has a .p7b file name extension, but this is not always the case. This again doesn’t support storage of private keys. It is generally used by the CA to provide certificate chain to clients.

However as in the case of any other data file, the creator has the authority to use the existing .p7b extension or change it as desired.

Personal Information Exchange Format (PKCS#12) Certificate (.pfx or .p12)

The Personal Information Exchange format (PFX, also called PKCS #12) defines a file format that can be used for secure storage of certificates (containing both private and public keys), and all certificates in a certification path, protected with a password-based symmetric key. PFX is a predecessor to PKCS#12.

The PKCS #12 formats is the only file format that can be used to export a certificate and its private key. A PKCS#12 certificate containing a private key is shown below:

Certificate containing a private key

Certificate Revocation List (.crl extension)

The Certificate Revocation List or CRL is a file type that identifies whether a certificate has been revocated or not. These files are provided by CA’s. The client browser while accessing a site on HTTPS will use the CRL Distribution Points field in the certificate to download the CRL. Here is one example:

Certificate from login.live.com depicting the CRL Distribution Points

NOTE: Not all certificates may have CRL distribution points. One good example is a Self-Signed certificate.

Now, once the client (browser) gets the CRL information from the server certificate, it downloads the CRL file and checks the list to ensure that the current certificate is not part of that list. The CA can make the CRL available for download to the client, via HTTP, FTP or any other protocol. Here is the downloaded CRL from the CA:

CRL file downloaded from the CA

Microsoft serialized certificate store (.sst)

This is one of the most rarely used file types. This format allows storage of multiple certificates in one single file. Typically it contains the ROOT CA certificates. It is the only file type which allows to save the certificate store. It preserves the properties of the certificate stores. There is another extension viz. “.STO”. However, I have rarely seen the usage of either of these file types.

Not much documentation is available except this:

http://msdn.microsoft.com/en-us/library/dd921035(v=office.12).aspx

Certificate Trust List (.stl)

Certificate Trust List is generally used during SSL/TLS handshake when Client Certificate Authentication comes in to picture. During SSL Handshake the server sends the client the list of the distinguished CA names that it supports as a part of Server Hello message. The Client uses this list to draw up a list of client certificates that is issued by any of the CA’s in the list i.e., only those client certificates which are issued by any of the CA’s in the CTL will be populated. Below is an example of how a CTL looks like

Privacy-enhanced Electronic Mail (.pem)

PEM format is a refinement of base64 encoding. It has been documented in the following RFC’s:

• RFC 1421: Part I: Message Encryption and Authentication Procedures
• RFC 1422: Part II: Certificate-Based Key Management
• RFC 1423: Part III: Algorithms, Modes, and Identifiers
• RFC 1424: Part IV: Key Certification and Related Services

This file format is typically used by OpenSSL to make Private Key available from a .pfx/.p12 file. So this is more widely used in the UNIX/LINUX world and not much in Windows. Once extracted to PEM format, this is how it looks:

The two headers ”Proc-Type“ and “DEK-Info” specify the type of encryption. The string following afterwards with “5XAtC...” is Base64-encoded, encrypted, ASN.1-encoded object. Sometimes it also referred to as Base-64 encoded DER Certificate.

It is very similar to the PFX file format and can contain any/all of the following information in one single file.

• Issued Public Certificate (Client/Server)
• Intermediate CA Certificate
• Root CA certificate
• Private Key

A single PEM file can also be split into multiple PEM files each containing a part of the original PEM file.

PEM for storing Public Key

This format can also be used for storing only the public key information of a certificate. I found this article: http://www.bo.infn.it/alice/introgrd/certmgr/node20.html, which talks about extracting only the public part of the certificate. Even in this case the file is a Base-64 encoded string enclosed between "-----BEGIN PUBLIC KEY-----" and "-----END PUBLIC KEY-----".

I have personally never encountered any situation or a usage scenario where the public key information of the certificate had to be extracted.

Private Key(.key)

This file format contains the private key of the certificate. On Windows  there is no mechanism available to extract only the private key from the certificate, as it is not required. However, OpenSSL allows only the Private Key to be extracted from the certificate. If you open the file in a notepad, you would find that it is a Base-64 encoded string enclosed between "-----BEGIN RSA PRIVATE KEY-----" and "-----END RSA PRIVATE KEY-----".

This is more widely used in JAVA & UNIX world.

More on Certificates:

When a certificate request is created for a website in IIS 6, corresponding private key is also created. The requests are stored under the Certificate Enrollment Requests store under Computer account. This contains the private key information corresponding to the request raised.

Once you have submitted the request to the CA. It will process the request and provide a certificate in .cer, crt or .der extension (DER or Base64 encoded). Now the pending request can be processed in the IIS Manager by installing the certificate which was provided by the CA.

Consider, if somehow the request for the certificate was lost i.e., the request under the Certificate Enrollment Requests was removed. Now if you install the certificate on the website you are bound to see some issues due to the missing key information. The SSL handshake will not complete and you will see a “Page cannot be displayed error message” on the browser.

By default a .cer file doesn’t contain a private key. The notion of such file is that the private key already exists on the server and during installation the binds to the certificate. Now since the request (private key) no longer exists the server doesn’t know how to decrypt the information received from client (encrypted using the public key). However, we are not totally helpless. We can try to retrieve the private key for the certificate. Here are the steps to do it:

1. Import the certificate to the personal store of computer account.

2. Now double click the certificate and go to the Details tab. Select the Thumbprint section and copy the value as shown below:

3. We will use certutil tool to map the private key to the certificate. Open a command prompt and execute the following:

If the command is successful then you will see a confirmation message as shown below:

More information on certutil tool can be found here:
http://technet.microsoft.com/en-us/library/cc772898%28WS.10%29.aspx

Scenarios:

Sometimes the web-administrator has to install the same certificate across various servers in a load balanced server. So, continuing from the above scenario let’s assume the web-admin has to install the cert on other 12 servers. Manually copying the .cer file to every server and running the above command is quite tedious.

Why can’t we export the certificate along with the private key to the other servers and then install it? Well, it can be done, provided the private key has been marked as exportable. Generally, you would see this if the certificate was renewed again with the private key not being exported earlier.

Go to the websites on which the certificate has been installed.

1. Right click and select Properties-> Directory Security-> View Certificate.
2. Now go to the details tab and click on “Copy to File…”
3. Click on Next, you will now see a window provided with 2 radio buttons

• Yes, export the private key
• No, do not export the private key

Now you have a SSL certificate containing the Private Key. You can copy this to other servers and then install it on the website. You may also choose to install the certificate programmatically on IIS using the KB article 313624.

Log Parser is one of the most powerful tools available for parsing IIS logs. It can effectively parse GB’s of data in effective time. Below is the download link:

Download Log Parser 2.2

These are the few Log parser queries using the command line interface. I have used  it most of the time. I have used DataGrid as the output format. More details on the input and the output format can be found here: http://technet.microsoft.com/en-us/scriptcenter/dd919274.aspx

Below are the different type of queries:

Search for total number of static files that were requested:

Total No. of Entries in the IIS logs:

Dumping out entries based upon responses:

Adding the requested resource (cs-uri-stem) to the above query: 

Client IP that was logged against a specific cs-host the most:

Client IP that requested most no. of times:

Searching for specific HTTP Response Code:

Counting the No. of file extensions requested:

Dumping out details for a specific file type:

NOTE: Replace <Log File Path> with the location where the log files are store. Assuming they are stored at location: C:\Logs. Here is one e.g.:

LOGPARSER "SELECT count(*) as hits from C:\Logs\ex101003" -i:IISW3C -o:DataGrid -q:off

Alternatively, you can run this query on all the files within the folder using a wild-card:

LOGPARSER "SELECT count(*) as hits from C:\Logs\ex*" -i:IISW3C -o:DataGrid -q:off

As you can see we can write more flexible queries to extract further information.

I will be publishing more in future when I get time.

More Information:

KB Article on Log Parser: http://support.microsoft.com/kb/910447.

More on Log Parser by Rahul Soni: http://blogs.msdn.com/b/rahulso/archive/category/14624.aspx

Log Parser Examples: http://technet.microsoft.com/en-us/library/ee692659.aspx

Forensic Log Parsing with Microsoft’s Log Parser: http://www.symantec.com/connect/articles/forensic-log-parsing-microsofts-logparser

        Secure Socket Layer (SSL) and its successor Transport Layer Security (TLS) are protocols which use cryptographic algorithms to secure the communication between 2 entities. It is just a secure layer running on top of HTTP.

        Several versions of SSL have been released after its advent in 1995 (SSL 2.0 by Netscape communications, SSL 1.0 was never released). Here is the list:  

• SSL 1.0, 2.0 and 3.0
• TLS 1.0 (or SSL 3.1, released in 1999)
• TLS 1.1 (or SSL 3.2, released in 2006)
• TLS 1.2 (or SSL 3.3, released in 2008)

        SSL was changed to TLS when it was handed over to IETF for standardizing the security protocol layer in 1999. After making few changes to SSL 3.0, IETF released TLS 1.0. TLS 1.0 is being used by several web servers and browsers till date. What I have never understood, is there have been newer versions released after this, with the latest being TLS 1.2 released in 2008.

        However, in spite of the newer versions the internet industry continues to use the decade long old protocol TLS 1.0. What is more shocking is that there are few web servers out there which still support, SSL 2.0. Now, someone should seriously consider blocking these protocols on server side.

        Now let’s come to the point, on Windows the support for SSL/TLS protocols is tied to the SCHANNEL component. So, if a specific OS version doesn’t support a SSL/TLS version, this means it remains unsupported.

All the windows components/applications abide by this rule and can support only those protocols which are supported at the OS level. For e.g.: IIS and Internet Explorer.

Below table should give you a good understanding of what protocols are supported on Windows OS.     

       You could cross-check this yourself. Open IE 8 or IE 9 on any of the Operating systems listed above. In IE, go to Tools menu -> Internet Options -> Advanced. Scroll to the bottom i.e., to the Security section. You would see the list of SSL protocols supported by IE. Now one thing you should remember is IE supports only those security protocol versions, which is supported by the underlying SCHANNEL component of the OS.

       So if you are running IE 9 on Windows Server 2008 and Windows Server 2008 r2, then you could quickly check this all by yourself. Below is a snapshot from my machine running IE 9 on Windows 7.

Supported SSL protocols under “Advanced” tab of IE 9 on Windows 7

        Among web servers again, IIS 7.5 is the only which supports TLS 1.1 and TLS 1.2. As of now Apache doesn’t support these protocols as OPENSSL doesn’t include support for them. Hopefully, they’ll catch up to the industries new standards.

Hope you find this information helpful. Please let me know if you find any discrepancies.

Two researchers recently discovered a known vulnerability that existed in CBC based ciphers, but was considered theoretically impractical, until then. This vulnerability exists in all CBC based ciphers used in SSL V3/TLS 1.0. The researchers Juliano Rizzo and Thai Duong demonstrated proof-of-concept code called BEAST (Browser Exploit Against SSL/TLS) at the Ekoparty security conference held in late September, 2011.

If you don’t remember, these 2 are the same guys who last year discovered the “Padding Oracle” crypto attack in ASP.NET.

I will try to be as explanatory as possible. One of the researchers (Thai Duong) has published this on his blog here: http://vnhacker.blogspot.com/2011/09/beast.html. This blog contains a video link demonstrating the attack.

After this Microsoft released a Security Advisory article and a HOTFIX addressing the vulnerability on 26^th September 2011.

http://technet.microsoft.com/en-us/security/advisory/2588513
http://support.microsoft.com/kb/2588513

INTRODUCTION

Now, before we proceed ahead, we need to understand few semantics of SSL in order to understand this vulnerability. As I aforementioned, this vulnerability exists in all CBC based ciphers used in SSL V3/TLS 1.0.

I also want to mention that I referred few things from internet, mostly from Wikipedia, and what I remember from my college days. I am glad I was one of the few that opted for Cryptography as one of the topics back in my engineering days.

SSL Protocol: These are the following list of protocols which have been released till date:

• SSL 1.0, 2.0 and 3.0
• TLS 1.0 (or SSL 3.1, released in 1999)
• TLS 1.1 (or SSL 3.2, released in 2006)
• TLS 1.2 (or SSL 3.3, released in 2008)

NOTE: Windows Server 2008 R2 and Windows 7 are the only 2 OS which support TLS 1.1 and TLS 1.2 as of now. All the OS’s before this don’t support these 2 protocols.

Please refer the following blog post by me on support for SSL/TLS protocols on Windows.
http://blogs.msdn.com/b/kaushal/archive/2011/10/02/10218922.aspx

CIPHERS: Ciphers are cryptographic algorithms used for performing encryption/decryption. A “Plain text” is fed as input to CIPHERS to generate an encrypted text also known as “Cipher text”. There are 2 kinds of Ciphers generally used during SSL handshake:

• Block Ciphers, like AES and DES
• Stream Ciphers, like RC4

CBC (Cipher-block chaining): It is a symmetric key algorithm, used for encryption/decryption. It is also referred as a block cipher. It firsts partitions the input message into separate cipher blocks of equal length. The nth or the last block sometimes may have to be padded to match the cipher’s block length. Now these blocks are encrypted one at a time.

In CBC, the plain text is XOR’d with the Initialization vector (IV) in the first block and with the cipher texts of the previous blocks before undergoing encryption. The IV is generally sued to make each message unique. Here is where the problem arises. I will explain this in the later section.

The below images below explain the encryption/decryption. The images from articles on Wikipedia helped me draw out these images in a colorful way, however they lacked continuity. So I used few dotted lines to indicate continuation of cipher operations.

The dotted lines below indicate continuity from 1st and second blocks to the nth block and vice-versa.

Encryption in CBC Mode
Courtesy:  http://en.wikipedia.org/wiki/File:Cbc_encryption.png

Decryption in CBC Mode
Courtesy: http://en.wikipedia.org/wiki/File:Cbc_decryption.png 

SSL Handshake: SSL handshake is too big of a topic to be discussed here. Anyways we don’t need to discuss the complete handshake, What we need to know is, the 2 communicating entities, client and the server, decide on a common SSL/TLS protocol and cipher (Block Ciphers or Stream Ciphers) that they will be used to perform the encryption/decryption. The public key cryptography is used to decide these and during the latter part of the handshake, they decide on symmetric keys and perform encryption/decryption using the generated symmetric key and the ciphers decided earlier.

I invested some time and chalked out the image below. This explains the SSL handshake between client and server. This in reference to the Microsoft KB article 257951 on SSL handshake.

Chosen Plain-text recovery attack:

One of the methods used by the attackers, in order to gain access to the secret key being used by the communicating entities involved in a SSL handshake. In this method, the attacker choses arbitrary plain-texts and obtains corresponding cipher texts. The attacker makes predictive guesses depending upon the obtained cipher text, to form the original plain text.

This sounds unrealistic, as the attacker has to make predictions in order to crack it. However, modern day cryptography has become lot more easier as there are powerful hardware and software, capable of performing millions of calculations per second.

BEAST: Discussing the vulnerability

Remember the use of implicit IV’s while XOR’ing the plain text for successive blocks after the first block. This was a problem. The thing is that IV’s are supposed to be unique. Since the cipher text of the previous block is used as an IV in the current block mode of operation, the uniqueness is actually lost, and as I know that my previous cipher text is the IV for the current block.

• This vulnerability was addressed in TLS 1.1 and TLS 1.2, by usage of “Explicit IV’s” for each block. Hence, TLS 1.1 and TLS 1.2 are not susceptible to this attack. I will once again emphasize on the fact that this vulnerability is seen only in CBC based Ciphers like AES, DES and Triple DES.
  
• OPENSSL addressed this in TLS 1.0 by inserting TLS packets with zero-length payloads and random padding. However, this solution is disabled by default due to incompatibility with certain SSL stacks.
  
• I’m not going to discuss how the attack works, please refer the blog article by one of the researchers: http://vnhacker.blogspot.com/2011/09/beast.html. They use the Chosen plain text recovery attack, a known attack which was considered to be theoretically impossible until they cracked it.
  
• There are few catches here:
  • This attack is not easily implemented. It cannot be cracked by just observing the encrypted traffic.
  • The attacker should know in prior which  secure site is being browsed.
  • The attacker has to implement a Man-in-the-Middle attack in order to do this. So the attacker has to be within the same network where this attack has to be implemented.
  • Multiple requests have to be sent across the wire before he could crack it i.e., he has to mix his traffic with the SSL traffic that the entities are communicating to each other without either of them realizing it.
  • This only lets the attacker to guess one plain text block at a time.

Workaround/Solutions

Server Side Fix:

1. Prioritize the RC4 cipher suites rather than CB. RC4 is a stream cipher, since the attack is effective against CBC based Ciphers.
   
   • Go to Start, click on run and type “gpedit.msc”.
   • Go to Local Computer Policy --> Administrative Templates --> Network --> SSL Configuration Settings
   • Move “TLS_RSA_WITH_RC4_128_SHA” to the top of the priority list. The GUI suggests how to modify the settings.
     
     How to modify this setting:
     
     • Open a blank notepad document.
     • Copy and paste the list of available suites into it.
     • Arrange the suites in the correct order; remove any suites you don't want to use.
     • Place a comma at the end of every suite name except the last. Make sure there are NO embedded spaces.
     • Remove all the line breaks so that the cipher suite names are on a single, long line.
     • Copy the cipher-suite line to the clipboard, and then paste it into the edit box. The maximum length is 1023 characters.
       
2. Enable TLS 1.1 and/or TLS 1.2 on servers running Windows 7 or Windows Server 2008 R2. Refer Microsoft Knowledge Base Article 2588513 to use the automated Microsoft Fix it solution to enable or disable this workaround for TLS 1.1.

Warning:Web clients that don’t support TLS 1.1 or 1.2 will perform the SSL negotiation with lower SSL/TLS versions, voiding the workaround. So better implement both the workarounds on IIS 7.5.

The above KB article adds the following registry key when run on server side:

NOTE: Unfortunately the above solution doesn’t apply to Windows Server 2003/Windows XP, the cipher suites prority is hard coded. On Windows Server 2003, they will probably have to disable the CBC based ciphers; however this might cause incompatibility with clients trying to connect to these servers.

Browser Side Fix:

Among browsers as of now only 2 of them include support for TLS 1.1 and TLS 1.2

• IE 8/IE 9, running on Windows 7 or Windows Server 2008 R2.
• Opera V10 onwards.

IE, like IIS relies on SCHANNEL for encryption or decryption, hence it supports only those protocols that are supported by the underlying OS. However, this is not true for non-Microsoft products; they have their own implementation and include support for these protocols specifically.

1. Enable TLS 1.1 and/or 1.2 in Internet Explorer on systems running Windows 7 or Windows Server 2008 R2. To change the default protocol version to be used for HTTPS requests, perform the following steps:
   
   
   • On the Internet Explorer Tools menu, click Internet Options.
   • In the Internet Options dialog box, click the “Advanced” tab and scroll to the bottom.
   • In the Security category, select the Use TLS 1.1 and/or Use TLS 1.2 checkboxes.
   • Click OK.
   • Exit and restart Internet Explorer.
   
   Note: See Microsoft Knowledge Base Article 2588513 to use the automated Microsoft Fix it solution to enable or disable this workaround for TLS 1.1.
   
   
   Warning:Web servers that don’t support TLS 1.1 or 1.2 will perform the SSL negotiation with lower SSL/TLS versions, voiding the workaround.
   
2. Set Internet and Local intranet security zone settings to "High" to block ActiveX Controls and Active Scripting in these zones. These may render many web-sites non-functional. So if you don’t want to block ActiveX Controls and Active Scripting for such sites, then add sites that you trust to the “Trusted Sites Zone”.
   
3. Clear cookies and don’t navigate to HTTP and HTTPS websites at the same time. First, clear all cookies. Then, while browsing close all HTTP Web sites, including sites that mix HTTP and HTTPS, before and during use of HTTPS. Finally log out of all HTTPS Web sites that require authentication before resuming the HTTP traffic.

Recommended reading on this:

• Microsoft Security Advisory (2588513): Vulnerability in SSL/TLS Could Allow Information Disclosure
  http://technet.microsoft.com/en-us/security/advisory/2588513
  http://support.microsoft.com/kb/2588513
  
• Is SSL broken? – More about Security Advisory:
  http://blogs.technet.com/b/srd/archive/2011/09/26/is-ssl-broken-more-about-security-advisory-2588513.aspx
  
• BEAST:http://vnhacker.blogspot.com/2011/09/beast.html

The irony is that major internet browsers (Chrome, Firefox and Safari) still don’t provide support for TLS 1.1 and TLS 1.2. They continue to use a security protocols which is a decade old. Its been 5 years since TLS 1.1 was released, yet this hasn’t been implemented by them.

Even OpenSSL doesn’t include support for TLS 1.1/TLS 1.2, so as a result, even Apache doesn’t support these protocols. Hopefully, they would realize the importance of security and adopt these new IETF standards.

Its time that we move on and adapt the new security protocols. I guess the time has arrived.

Recently, I ran into issues while writing an ASP.NET 4.0 application. I tried to remember if I had meddled with anything or deleted any components by mistake.

This was the error I get when trying to compile my application:

Could not load file or assembly 'Microsoft.VisualStudio.Web.Runtime, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.

Below is the exception message seen in the browser:

I couldn’t remember doing any such destructive activity.

I tried a couple of troubleshooting steps, I changed the target framework to .NET 3.5 and I was able to compile my application successfully. So, obviously the issue was with ASP.NET 4.0 applications only.

I started searching forums to see if someone had encountered this issue. Looks like I was not the only one.

Seems the issue was due to a component called “Microsoft Page Inpector - Visual Studio vNext”

Forum Link: http://social.msdn.microsoft.com/Forums/en-US/vssetup/thread/92823976-be85-43af-9efa-6b28f441fd6b/ 

Supposedly, Page Inspector on Visual Studio 2010 (RTM or SP1) will cause this problem. Page Inspector is only supported on the Visual Studio 11 Developer Preview, because it requires new components that only exist in ASP.NET 4.5.

Page Inspector's installer is supposed to block if you don't have the Developer Preview installed, but apparently that's not happening. I remember installing this component via Web Platform installer.

Don’t ask me the reason why I installed it, I just did it.

So, the resolution was to uninstall this component.

1. Go to "Programs and Features"
2. Type "Page Inspector" and bingo, this would list it. It is listed as "Microsoft Page Inspector - Visual Studio vNext"
3. Uninstall the component.

As soon as I uninstalled the component, the error went away. Relief!

Out of curiosity, I tried installing it again via the Web Platform Installer, looks like it does prompt the user for a warning message before installing it.

I wonder if this prompt was thrown earlier. Anyways, this is fixed for now.

Until then, CYA

Most of the time I write blogs to help myself find things easily. It is easier to search things when you know where to search them for. So I thought of blogging this topic as I keep encountering it more often and then spend quite some time figuring out what the fix was.

Many of you have already encountered this, while configuring IIS Client Certificate Mapping (either one-to-one or Many-to-one) in IIS 7/7.5 via configuration editor, when you specify the username and password section, the password is displayed in clear text.

As you can see in the above image, the password is displayed in clear text in the IIS GUI.

This problem was around for sometime until the PG decided to introduce a patch to address this.

In IIS 7, they introduced a path to fix this problem: http://support.microsoft.com/kb/2412005

For IIS 7.5, this issue was addressed in Windows Server 2008 R2 SP1.

After we install the patch, the password is no longer seen in clear text and remains hidden. We love those asterisks, don’t we?

Earlier I had posted a blog explaining the BEAST vulnerability observed in TLS 1.0 & SSL 3.0. Here is the blog link: http://blogs.msdn.com/b/kaushal/archive/2011/10/03/taming-the-beast-browser-exploit-against-ssl-tls.aspx

Microsoft released MS12-006 patch last week to address BEAST. As usual, after this update, we were bombarded with cases.

After applying this update, supposedly many applications were in a broken state (mostly 3rd party). Everyone was blaming MS (as usual) for the problem. I don’t think most of them understood what this patch was all about. Reading further you would realize what broke the applications.

The security patch implemented a solution which was present in the RFC documentation and is as per the RFC 2246. Below is a snippet from the rfc:

Now, I need not explain what the BEAST vulnerability is all about. You can refer my blog for this.

MS12-006 FIX for BEAST

1. The security patch mainly addresses the vulnerability in protocols TLS 1.0 & SSL 3.0.
   
2. The BEAST vulnerability is addressed by splitting (or fragmenting) the application data in to SSL records in the fashion 1/(n-1). This is explained in RFC2246 (section 6.2.1 Fragmentation).

This is where the problem arises, most of the applications haven’t implemented the RFC correctly. They assume that the application data will be packed into a single packet. Whenever the data is split into records, they don’t understand the response and leads to incompatibility between them.

Please refer this link for supported protocols on Windows OS: http://blogs.msdn.com/b/kaushal/archive/2011/10/02/support-for-ssl-tls-protocols-on-windows.aspx

Addressing the compatibility issues

KB2643584 was introduced to address the compatibility issues caused by the MS12-006 security patch.

1. It contains fixit links to enable TLS 1.1 protocol for IE (Client) and Windows based Servers.
   NOTE: This is applicable to Windows 7 and Windows Server 2008 R2 only.
   
   
2. Disable the fragmentation/splitting of records which causes the in-compatibility. This is done via a editing the registry. Below are the steps to change the registry:
   
   • Click Start, click Run, type regedit in the Open box, and then click OK.
   • Locate and then click the following subkey in the registry:

     HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL

   • On the Edit menu, point to New, and then click DWORD Value.
   • Type SendExtraRecord for the name of the DWORD, and then press ENTER.
   • Right-click SendExtraRecord, and then click Modify.
   • In the Value data box, type 2 to disable the split record in schannel, and then click OK.
   • Exit Registry Editor.

Today I got a interesting issue to work with. While working on a issue I ran into a corrupt installation of DebugDiag 1.2. Whenever we tried installing or uninstalling it it threw the following error:

so I ran a check to see what that error code meant. Here is the output:

I kept clicking on “OK” button only to see it prompt me again. The only way to kill it was to go to the task manager.

1. Under Applications tab right click DebugDiag and select “Go To Process”
2. This took me to DebugDiag.exe
3. Right click the process and select either “End Process” or “End Process Tree”

I was stuck in this awful situation where I had to fix this installation issue. Everyone knows how painful troubleshooting these issues could be.

Instead of wasting time trying to think what to do next, I pinged my colleague Mourad. He was my saviour for the day. He suggested me to go through the following blog link:

http://blogs.msdn.com/b/astebner/archive/2011/11/23/10241056.aspx

I am not to going to discuss the capabilities of this tool. So, here I was with this link. As there the server didn’t have direct access to internet, we had to download the portable fix it content on another machine and then copy it on to the server and launch it from there.

This was the first time I was using this tool. So we were supposed to go to the URL:

http://support.microsoft.com/mats/Program_Install_and_Uninstall

We had to click on a small link below the Run buttton which read “Advanced-Download to run on a different or disconnected computer”. This would expand the link and provide us a Download button.

Now we downloaded the file called “MicrosoftFixit-protable.exe” and ran it. It downloaded all the contents into a single folder. We copied this folder on to the server and ran it from there.

• Ran the "Launch Fix it.exe".
• Selected "All Problem areas" and clicked on "Run Now" for "Fix problems with programs that can't be installed or uninstalled".
• Selected "Debug Diagnostics 1.2" from the given list and clicked on Next.
• Clicked on "Yes, try uninstall"

I thought I was done as this Fixit tool would take care of it. But alas, it again threw the same error prompt.

It was the same behavior. Clicking on “OK” never really helped, the issue still exists. However, when I killed the DebugDiag.exe process via the task manager, the uninstallation completed.

Yo-hoooooooo! DebugDiag is uninstalled successfully. Now I could install it again with no issues.

Phew! That was quick, otherwise it could have been more painful.

Hope this article helps someone who runs into this issue.

In the past I have blogged about various certificate file extensions along with their usage. Here is the link: http://blogs.msdn.com/b/kaushal/archive/2010/11/05/ssl-certificates.aspx

I use blogs as reference so that they can refer the content and I need not repeat the same thing every time. Saves time and helps others too.

This time I thought of writing another blog explaining the difference between Client Certificates and Server Certificates. Something which is not clearly understood by everyone. I will be discussing this strictly in context of IIS only. (There are several types of certificates. you will come to know later )

One of my colleagues, David Dietz has already published a KB article relating to this:

IIS and client certificates: http://support.microsoft.com/kb/907274

The above documentation is good enough to understand the difference between client and server certificates along with error messages associated with them.

Lets start off in an Layman’s language and then I’ll discuss it in complete depth.

• How are Client and Server Certificates different?

Server Certificates: Server Certificates are used to identify a server. Typically they are issued to hostnames, which could be a machine name (like “PIIS-SVR01”) or a host-header (like “www.Microsoft.com”). Both client and server certificates have the “Issued to” section. For a server certificate the “Issued to” section’s value would specify the hostname for which it has been issued.

Server Certificates serve the purpose of encrypting and decrypting the content.

Read the highlighted text in the above certificate, it says “Ensures the identity of a remote computer” i.e., “localhost”. This is a self-signed certificate i.e., one issued a certificate to itself. (To be precise where the “Issued to” and the “Issued by” value is same. In the real world only Root-CA’s have self-signed certificates).

Server certificates are stored in the Personal store of the “Local Computer” account.

Note: Certificates can be put in the personal store of a user account. However IIS will always search for the server certificate in the personal store of computer account.

Client Certificates: Client certificates as the name indicates are used to identify a client or a user. They are meant for authenticating the client to the server. In case of a client certificate the value of this field would be set to a users name.

Yes, I know it is a certificate too, but it is not used for encryption or decryption of data, but represents a user identity. Below is a Client Certificate which I issued to myself using my CA (KAUSHAL-CA).

Client Certificate

As seen above, the line is more than enough to inform you about the purpose of the certificate.  It reads “Proves your identity to a remote computer”. Here ‘your’ means the user (Kaushal in this context).

• How are Client and Server Certificates Similar?

The only similarity between them is the keyword “Certificate”. They both contain public and private keys. For that matter, every certificate contains a public and a private key.

• How does IIS distinguish between Client and Server Certificates?

The above explanation was good enough to explain a user on how to identify client and server certificates. However, this is not how IIS determines it. The best way of determining the purpose of a certificate is to look at its “Enhanced Key Usage” field. (this is a optional field and may not be seen for all the certificate types).

The Enhanced Key Usage field specifies what can the public key of the certificate be used for. If the value is set to “Client Authentication(1.3.6.1.5.5.7.3.2)”then you know what it is used for.

For Server Certificates the value of this filed would be set to:
“Server Authentication (1.3.6.1.5.5.7.3.1)”.’

Every certificate has a Object Identifier (OID) associated with it. If you observed the OID for server certificate is “1.3.6.1.5.5.7.3.1” and for Client Certificate it is “1.3.6.1.5.5.7.3.2”.

Here is a snippet from RFC 3280

• How do I know what is the Enhanced Key Usage value for that certificate?  

Double click on the certificate to view it. FYI, it opens with “Crypto Shell Extensions”.

Go to the Details tab and select “Extension Only” from the “Show” drop down box as shown below:

This is a clear indication of the intended purpose of the certificate.

• Can I use a Server Certificate as a Client Certificate or Vice-Versa?

NO is the answer to this question and its very obvious. If you try importing a client certificate to the IIS 7/7.5 you will receive the following error:

Note: There are certificates which can be issued for multiple purposes like the one shown below. This is meant for both Client and Server Authentication.

Hope this cleared some doubts!

Recently I had to troubleshoot a issue where we were getting the following error message while browsing a website hosted on IIS.

As always I captured a FREB trace to determine the entry point of failure. FREB always come in handy during troubleshooting such issues.

Please refer the following link on how to configure FREB: http://learn.iis.net/page.aspx/266/troubleshooting-failed-requests-using-tracing-in-iis

Looking at the above error, I tried changing the application pool bitness, but that didn’t help. I was still stuck with the same error.

IIS was configured as per the following article on IIS.NET: http://www.iis.net/ConfigReference/system.webServer/cgi

We also had an ISAPI and CGI restriction entry for the path where the page was stored on disk.

For e.g: If the page is stored under location: C:\inetpub\wwwroot\CGI\test.cgi, then there would be a entry in applicationhost.config under <isapiCgiRestriction> as shown below:

So the problem was that the page was scripted using PERL. So the above article cannot be used as a reference. Instead we need to download PERL and configure it on the server.

So we downloaded and installed Perl from the below link: http://www.activestate.com/activeperl/downloads

The default installation location is: C:\Perl64. Once installed, we added the handler mapping for .cgi and pointed it to “C:\Perl64\bin\perl.exe”.

Assuming the issue was resolved, I happily browsed the page again. Now I was greeted with a different message altogether.

After searching on forums I found the answer to my problem.

The handler mapping should be set to the following: “C:\Perl64\bin\perl.exe "%s" %s”.

Look at the example given below:

Note: While adding the script map entry you would be prompted to add a entry in ISAPI and CGI restriction list. When prompted click on the “YES” button.

More Information:

The characters “%s” %sare case sensitive; they must be in lower-case. If set to “%S” %S the following error would be received:

You could also refer the following link on how to configure ActivePerl for IIS: http://www.activestate.com/blog/2010/06/setting-iis-activeperl 

http://docs.activestate.com/activeperl/5.10/bin/ap-iis-config.html

During troubleshooting several issues we are required to generate dumps on a specific exception. We generally use Debug Diag to do so. Not many are familiar with the tool and hence find it difficult to use it to capture the data.

This time I’ll discuss how to use DebugDiag to generate memory dumps on First Chance Exceptions. Please go through the following blog if you want to know what a first chance exception is:

http://blogs.msdn.com/b/davidklinems/archive/2005/07/12/438061.aspx

I’ll be using Debug Diag v1.2, below is the download link:

http://www.microsoft.com/en-us/download/details.aspx?id=26798

Download and install the tool corresponding to the bitness of the server and not the process i.e., for 32 bit machines download x86 and for 64 bit download x64.

The default installation folder is “C:\Program Files\DebugDiag”

There are 2 ways to capture FIRST CHANCE EXCEPTION dumps of a process.

• Method 1: Generate a dump for all First Chance Exception or
• Method 2: Target a specific First chance exception (Recommended)

Method 1: Generate a dump for all First Chance Exception

This is the easiest way to capture a dump for any exception that is raised within the process, However this captures unnecessary data and a lot of junk data is generated and hence is never recommended. Below are the steps to configure the same:

1. Launch Debug Diag
2. In the Rules tab select Crash and click on Next
           
3. In “Select Target Type” select “A specific process” and click on Next.

Note: If the target is a web application hosted on IIS then, choose either “All IIS/COM+ related processes” or “A specific IIS web application pool”.

4. In “Select Target” select the target process and click on Next.
   
        
   
5. In “Advanced Configuration (Optional)” under “Unconfigured First Chance Exceptions” set the following:
   
1. Action type for unconfigured first chance exceptions: Full Userdump
2. Action Limit for unconfigured first chance exceptions: 10
   
   
   
6. Click on Next twice and then click on Finish to activate the rule.

This will generate a dump for any unconfigured exception that may occur inside the target process. The file name will be in the following format:

<ProcessName>__<ApplicationPool>__PID__<PIDValue>__Date__<DateValue>__Time_<TimeValue>__First chance exception <Exception_Code>.dmp

Example:

w3wp__DefaultAppPool__PID__10032__Date__05_09_2012__Time_12_52_51PM__406__First chance exception 0XE0434352.dmp

Method 2: Target a specific First Chance Exception (Recommended)

Follow the above method until step 5. Here we will target a specific First Chance Exception. I will be targeting OOM exception for my example/

1. In “Advanced Configuration (Optional)” click on the Exceptions… button.
   
   
   
2. In “First chance Exception Configuration” click on “Add Exception…”
3. In “Configure Exception” select the Exception code from the LHS and since we are targeting OOM, specify the details as shown below:
   
1. .NET Exception Type: System.OutOfMemoryException
2. Action Type: Full Userdump
3. Action Limit: 3
   


NOTE: The Exception type is case sensitive. Ensure it is entered correctly. For more details please visit the following link: http://msdn.microsoft.com/en-us/library/system.systemexception.aspx

4. Click on Ok and then click on “Save & Close”.
   
5. Click on Next twice and then click on Finish to activate the rule.

The dumps created by this rule will be in the following format:

<ProcessName>__PID__<PID>__Date__<DateValue>__Time_<TimeValue>__First Chance <ExceptionName>.dmp

Example:

w3wp__PID__2364__Date__05_09_2012__Time_12_59_51PM__406__First Chance System.OutOfMemoryException.dmp

Until then. Adios!

One of the cool features of Windows 8 is the improved set of PowerShell commandlets that have been shipped with it. There are several of them which could have made the task a lot easier for the server admins.

In here I will be discussing about one of the commandlets using which we can create a self-signed SSL Certificate. Yes, I mean self-signed and a SAN Certificate.

What you also need to know is that there are no lengthy procedures, it is a simple command with few parameters which adds to the simplicity.

So here are few pre-requisites that I could think of,

• Windows PowerShell and PowerShell ISE needs to be installed.
• OS is either Windows Server 2012 or Windows 8. (I’m not aware if this cmdlet has been back-ported to previous OS versions, I hope they do)
• The Windows PowerShell help menu is updated (Well this is not a necessity, but it will help if this is done.)

Commandlet Name: New-SelfSignedCertificate

Syntax:

New-SelfSignedCertificate [-CertStoreLocation <String>] [-CloneCert <Certificate>] [-DnsName <String>] [-Confirm <SwitchParameter>] [-WhatIf <SwitchParameter>] [<CommonParameters>]

Scenario

Consider you need to create a self-signed SAN certificate for the following hostnames:

• www.test.com
• www.test.edu
• www.test.testing.com

Using the above commandlet the cert can be issued and automatically placed in the personal store of My Computer Account.

Here is the command that we need to execute to generate the cert.

This will install the self-signed cert in the Personal store of machine account.

Note: Certificate wouldn’t be trusted. Place the certificate in the Trusted Root CA store and the error will go away.

So this is what the certificate looks like:

It can’t get easier than this.

Another thing worthwhile mentioning is the help menu, which is very descriptive. I have pasted the entire help menu content for the above commandlet below

The good thing is that it also provides descriptive examples.

        Recently one of my colleagues came across with an interesting question. He questioned why he couldn’t see the “Content-Encoding” header in the IE HTTP debugger but was able to view it in the Fiddler.

        First of all, Fiddler and IE are two different products. Their functionality should not be compared at any point of time. I will try to explain as to why we don’t see the above header in the IE HTTP debugger but we can view it in the Fiddler.

        To demonstrate this, I will set-up a simple repro. I’m going to use IIS 7.5 (the latest version) to demonstrate this. Enable Compression in IIS as shown below:

        Now, browse the website. For me its the default web site, so I access it over http://localhost. Hit F12 key to launch IE Developer Tools window or IE HTTP Debugger or whatever you call it. Go to the Network tab and click on “Start Capturing”.

        Now Launch Fiddler, and click on Clear Cache, so that nothing is served from the cache. Now when I browse to localhost, the traffic is capture by both the IE HTTP Debugger and the Fiddler. Lets take a look at both.

Here is the output from Fiddler:

        For those of you who are not familiar with fiddler, to inspect the HTTP traffic after gathering the trace, click on the Inspectors tab as shown above. The upper portion consists of Request headers and the below portion consists of Response headers.

        We can see that the Server Response contains the “Content-Encoding: gzip” header in the HTTP Response. For the readers I have also highlighted a portion of the image in blue which reads as “Response is encoded and may need to be decoded before inspection. Click here to transform”.

        We will re-visit this again, but before that lets take a look at what we see in IE for the same request. Below is what we see in the IE debugger.

        Select the URL which reads http://localhost and click on “Go to detailed view”. Here select “Response Headers”. You will see that the Content-Encoding header is missing. Interesting right? you will start wondering why the difference in behaviour.

Reason

        The reason we don’t see the Content-Encoding header in IE because it decodes (or decompresses) the response and then reads the header values. It needs to decode the HTTP response as it needs to do this to perform Script debugging and Inspect HTML Elements and CSS Rules. (Probably it would have been better if it read the Response Headers before decoding them so that we look at the complete HTTP Response)

        Even in fiddler, you get a option to decode the HTTP Response for the encoded responses. However, once you decode the HTTP Response (Click on “Click here to transform” in the above image), the response is encoded and the Content-Encoding header vanishes from the HTTP Response.

Response Headers in Fiddler before Decoding:

Response Headers in Fiddler after Decoding:

        Just to Let you folks know, the debugger that comes with Firefox reads the Response headers before they are processed.

Below Snapshot is from Firefox HTTP debugger:

        Some may question as to why cant IE do it. Well, these are different products and have different implementations. No one actually uses the browser for traffic monitoring, you have better tools to do so, like Network Monitor and WireShark. The HTTP debugger was designed mainly for Script Debugging and Inspection of HTML Elements.

        Hopefully, the IE HTTP Debugger may become capable of reading the HTTP Response headers before they are parsed or may be it wont. The answer lies in the future.

Until then CIAO!

        Windows 8 was RTM’d last week and as a curious soul I upgraded to RTM. Once done, I was loading my machine with all the tools that I use everyday. This includes the networking tools like Network Monitor and WIRESHARK. Both have their own advantages. I was able to install Network Monitor without any issues. However, I ran into problem when I was trying to install WIRESHARK on Windows 8. I was always greeted with the following error:

WinPCap installer error on Windows 8

Go to this page to download the WIRESHARK Installer: WIRESHARK

Running it as administrator doesn’t help either. Well, selecting either of the options won’t help. So here is what we need to do.

Solution

        It’s a simple solution. We need to run the WinPCap installer in Windows 7 compatibility mode. Most of you would have got this hint. For those who haven’t please refer the below instructions.

        I am going to use 7-Zip to simplify our approach. You could download it from here: Download 7-Zip. I am using 7-Zip as it allows to extract contents from a installer file.

1. Install 7-zip and extract the WinPCap installer file to any other folder on to your disk. If you open the archive, you can see the WinPCap installer file as shown below:
   
2. Right click the exe and select Properties.
3. Go to the Compatibility tab.
4. Click on “Change Setting for all users”
5. Select the check box “Run this program in compatibility mode for” and select Windows 7 from the drop down as shown below:
   
6. Also check the option to run this program under the privilege of an administrator.
7. Click on Ok and then run WinPCap installer again. You will again see a warning as we saw earlier.
8. Click the 2nd option “Run the program without getting help”, this will take you through the rest of the installation.

Voila! It is installed successfully.

The same has been suggested as a solution in the WIRESHARK discussion forums too. I have outlined the steps for simplicity.

One of the biggest problems with IIS on the previous versions of IIS was in regards to scalability. This restriction was at the OS level at the kernel mode. There is nothing much that we could do to address this in IIS. One cannot bind more than one Certificate to a combination of <IP:Port>. The workarounds were:

None of this was an ideal workaround. You could read more about this restriction here:
http://blogs.msdn.com/b/anilpras/archive/2012/05/23/server-certificate-bindings-and-its-restrictions-in-iis-6-0-amp-iis-7-x.aspx

This has been finally addressed in Windows 8 and here are the solutions.

• Server Name Indication or SNI
• Central Certificate Store or CCS

For SNI: http://learn.iis.net/page.aspx/1096/iis-80-server-name-indication-sni-ssl-scalability/

Also refer the Wiki article: http://en.wikipedia.org/wiki/Server_Name_Indication

For CCS: http://learn.iis.net/page.aspx/1091/iis-80-centralized-ssl-certificate-support-ssl-scalability-and-manageability/

The result of this change is that now you would see 2 additional entries under the following registry key as shown below:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters

Let’s discuss these keys a little bit:

1.    SslBindingsInfo:
        This legacy registry key was also present in earlier version of Windows prior to Windows 8. The bindings were of the type IP:Port. Only one certificate could be associated with an entry (or that key) and hence the limitation. We could add multiple SSL bindings by creating multiple combination of IP:Port and then associating each with a SSL Server Certificate.

        The problem was that it was not feasible to have multiple ports open on the server. The ideal choice was always going to be the default SSL 443. So this suggests that we need to have more IP Addresses on the server. In the real world, this is not an acceptable solution and hence we had to use SAN or Wild Card certificates.

2.    SslSniBindingsInfo:
        This isnew inWindows 8 and is not available in previous Windows Versions. The bindings are of the type Hostname:Port. As the previous one, only one certificate could be bound to Hostname:Port key.

       In this case we don’t have to use additional IP Addresses. We can use the hostname present in the certificate and then continue using the default SSL Port 443. Since Hostnames are always unique, 2 bindings could never have the same certificate.

3.    SslCcsBindingsInfo:
        This is new in Windows 8 and was not available in earlier versions of Windows. True SSL Scalability was achieved with this. This reads the certificates from a File Share. There is only one binding for a specific port and you could have multiple Site listening on this binding. The Server certificate is loaded based on hostname section available from the Client Hello at run time. If you try to list out the SSL bindings then this is how it would look:

       This allows you to configure multiple sites on a single binding, as the certificates are loaded at run time. The management of certificates is also easier as we can have multiple certificates read from a central file location. If a certificate expires we can just update the certificate on that particular file share.

I will blog in more detail on how this works with scenarios to help this understand better. There is more to the Central Certificate Store and I will blog multiple posts with more detailed explanation.

You can read more on IIS 8 here:

http://weblogs.asp.net/owscott/archive/2012/03/01/what-s-new-in-iis-8.aspx
http://learn.iis.net/page.aspx/1087/what39s-new-in-iis-80-for-windows-8/
http://technet.microsoft.com/en-us/library/hh831725.aspx

Until then. Adios!

Here is the link: SSL Scalability with IIS 8.

In this blog I will discuss specifically about Server Name Indication aka SNI. We will learn how scalability is achieved through this.

During SSL handshake when the client sends a HTTPS request (Client Hello) to the web server, the HTTP headers are not available to the server. Once the SSL handshake is completed the client will encrypt the headers and send the encrypted HTTP request to the server. Therefore server cannot access the HTTP headers or the content until the request is encrypted. Hence, the problem.

Before decrypting the request the only information available to the server will be the IP Address and the Port number. This is available through the TCP headers as only the HTTP headers are encrypted. This leads to the limitation of only one certificate can be bound to a combination of <IPAddress>:<Port>.

Legacy SSL handshake between client and IIS 7.x and earlier

NOTE: The Public key cryptography is used to decide on a symmetric key (session key), which is then used by the client and the server for both encryption and decryption of the HTTP Headers and the content body. If you realized by now, SSL handshake involves both asymmetric encryption and symmetric encryption. Symmetric encryption is used for encryption of the actual data.

All the SSL bindings on Windows OS prior to Windows Server 2008 R2/Windows 7 can be found under following registry key:

HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\SslBindingInfo

Even if the client provides the server name in the client hello, the server wasn’t capable of using it. This is addressed in IIS 8. To solve this problem associated with SSL/TLS, IETF added a new TLS extension called Server Name Indication. It is mentioned in the following RFC’s

• RFC 3546– Section 3.1
• RFC 4366– Section 3.1
• RFC 6066– Section 3

You could also read about SNI on Wikipedia.

As mentioned in the above RFC’s a TLS extension called ServerName was introduced to tackle this problem. Below is a snippet from RFC 6066.

East Lake                  Standards Track                      [Page 5]

RFC 6066              TLS Extension Definitions               April 2011

3. Server Name Indication

Now the client can send the hostname it wants to access over https as a part of client hello. This helps the server to associate the client hello to a specific request and thus we overcome the limitation which was imposed earlier.

If you were to capture a network trace of SNI complaint browser accessing a HTTPS site you could see this extension as part of the client hello. I captured a Wireshark trace while accessing https://www.outlook.com. I filtered the trace by SSL and searched for Client Hello.

snapshot of a SSL trace in Wireshark 

***IMPORTANT***

One important thing to note here is that SNI is part of the Client Hello. So it is the client browsers that need to support this extension. Most of the current day browsers support SNI.

However, there are few browsers out there that don’t support SNI. For example, on Windows OS any version of IE running on Windows XP or lower versions do not support SNI. Vista onwards support for SNI was included for IE 7 and higher. There is a good list on Wikipedia on browsers that provide support for SNI. Below is a snippet from Wikipedia:

List of SNI Compliant Browsers:

So far I was trying to explain the basics of SNI. We need to know this to understand the server side solution for this.

NOTE: SNI is available only on IIS 8 and may be future versions. It is not available on any of the previous versions of IIS like IIS 7.x, IIS6 etc.

SNI on IIS 8

IIS 8 supports Server Name Indication. This is enabled by defaultand no separate installation is required. Now while adding a HTTPS binding for a website on IIS 8, the option to enable SNI is available. This is how the UI looks like:

There are 2 things to remember when enabling SNI for a specific site on the server.

• Selecting the above option enforces the site to use SNI i.e., it will expect the client to send a server_name as the part of the Client Hello during SSL handshake. If the server_name extension is not present then the SSL handshake would fail.
• The hostname has to be provided, this is a strict mandate. The server will use this information to associate an incoming request to a specific site.

 How does the IIS know if a specific binding uses SNI?

When a SSL bindings is added for a site, there is also a small change in the configuration file i.e., the applicationhost.config. This is how the binding section looks like:

The highlighted attribute called sslFlagsis. This attribute tells IIS what type of binding it is. This flag can be thought of as a doing an OR operation on 2 variables x and y. Below table would give you a gist of what this flag signifies.

Changes in Registry

In IIS 8 we have a new registry key where all the SNI bindings are stored. I had mentioned this in my previous blog post. This location of this registry key is

HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\SslSniBindingInfo

Executing the following command “netsh http show sslcert” will read this key and show a formatted output as shown below:

So now we have 3 types of SSL bindings:

1. IP:Port– Legacy SSL binding.
2. Hostname:Port– SSL binding using SNI. (new in IIS 8)
3. Central Certificate Store– SSL binding using Central Certificate Store. I will discuss this in detail in my next blog. (new in IIS 8)

There is a small problem that the administrators have to take care of while configuring SSL bindings to use SNI. If a non-SNI compliant browser connects to a site on which SNI is enforced, as I mentioned earlier the SSL handshake would fail.

To tackle this there is a fall-back mechanism in IIS where the it would try to determine a binding with the combination of IP:Port, if this is not present, then the SSL handshake fails. For this the IIS admin has to configure a binding which neither uses SNI nor CCS.

If legacy binding doesn’t exist, then the IIS UI will throw an alert as shown below. This message is a warning saying that there is no legacy binding, so in case of a failure the SSL handshake would fail.

SSL Handshake between a SNI compliant browser and SNI Compliant Server

Below are the steps involved during SSL handshake between a SNI compliant Client and a site hosted on IIS 8 on which a SSL binding is configured to use SNI.

1. The client and the server establish a TCP connection via TCP handshake.
2. The client sends a Client Hello to the server. This packet contains the specific protocol version, list of supported cipher suites along with the hostname (let’s say www.outlook.com provided its a SNI compliant browser). The TCP/IP headers in the packet contain the IPAddress and the Port number.
3. The server checks the registry (legacy bindings) to find a certificate hash/thumbprint corresponding to the above combination of IP:Port.
4. If there is no legacy binding for that IP:Port, then server uses hostname information available from the Client Hello checks the registry to find a certificate hash corresponding to the above combination of Hostname:Port. The server checks the below key to find the combination:
   HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\SslSniBindingInfo
5. If the above step fails i.e., if the server couldn’t find a corresponding hostname:port, then it would use the IPAddress available to search for a legacy SSL binding for that IPAddress and PORT. (If this is absent then the SSL handshake would fail)
6. Once it finds a match, the crypto API’s are called to retrieve the Server Certificate based on the thumbprint/certificate hash from the certificate store. The retrieved certificate is then added to the Server Hello and sent to the client.

More Information:

You could refer the following links on additional information on this topic:

http://en.wikipedia.org/wiki/Server_Name_Indication

http://learn.iis.net/page.aspx/1096/iis-80-server-name-indication-sni-ssl-scalability

http://blogs.iis.net/yaminij/archive/2012/06/25/sni-server-name-indication-readiness-tool-draft.aspx

One of my article has been published on IIS.NET on how to troubleshoot SSL related issues. Here is the link:

Troubleshooting SSL related issues (Server Certificate)

There is another article written by my colleague few years ago. Here is the link to that:

http://blogs.msdn.com/b/saurabh_singh/archive/2007/09/05/troubleshooting-ssl-related-issues-with-iis.aspx

Let me know if there are any additional scenarios that you want me address in this.

CIAO!

There is a known problem on IIS where the IP Address is leaked in the content-location header of the HTTP response. There is a fix for this and its documented here:

http://support.microsoft.com/kb/834141

The above KB also mentions that the issue might still occur even after using the above fix. It is discussed in detail in the “Mitigating Factors” section. Below is a snippet from the above article:

So in real world the admins run a PCI scan on the server and it reports the server is vulnerable as it is leaking IP Address and suggests to follow the above support article.

However, even after applying the above fix, the issue is still seen as the scanners use a custom client which issue HTTP Requests over HTTP/1.0 protocol. The problem is here with the protocol and not with the product.

In the Mitigating factors section discussed above, it states 2 reasons why the issue is seen even after applying the fix. The first reason comes into picture for HTTP/1.0 protocol. There was a limitation in this protocol which assumed the client would send the hostname as a part of the HTTP Request, but never enforced it. This is the problem, since it assumes, if the incoming request doesn’t contain a hostname it would send back the response containing the IP Address of the server in the content-location header. This issue shouldn’t be seen in HTTP/1.1 as it mandates that the client should send the hostname as part of the HTTP Request.

Now, the questions is what is the fix?

ANSWER: Reject all HTTP/1.0 requests. This is the ideal solution as HTTP/1.0 protocol is obsolete and none of the current day browsers use this version.

Next questions is, how do we implement this on IIS?

ANSWER: Firstly, this issue is seen on all versions of IIS. As every server will support the protocol. So you will have to disable it. Going by the IIS versions,

For IIS 7.0 and higher:

Please refer the following blog on how to fix this issue on IIS 7.0 & higher:

http://www.asprangers.com/post/2012/02/09/IIS-7-IP-Address-revealed-on-redirection-requests-on-HTTP10-protocol.aspx

In the above article, they have used the URL Rewrite Module reject HTTP/1.0 requests.

For IIS 6:

There is no simple solution available on IIS 6. One way is to write a isapi filter which would reject all incoming requests. Below is a sample code to do the same.

• Create a Empty C++ Project in Visual Studio 2005.
• Add a .cpp file to the project and name it HttpVersionBlocker.cpp (or a name of your choice)
• As we know, we need to define 2 important functions, GetFilterVersion and HttpFilterProc.
• Below is the code snippet. Copy this to the above .cpp file

#include<afxcoll.h>

#include<stdio.h>

#include<afxisapi.h>

#include<afx.h>

#include<stdlib.h>

//-------------------------------------------------------

// This function is the entry point to the ISAPI Filter 

//-------------------------------------------------------

BOOL WINAPI _stdcall GetFilterVersion(HTTP_FILTER_VERSION *pVer)

{

        pVer->dwFlags = (SF_NOTIFY_PREPROC_HEADERS ); 

        pVer->dwFilterVersion = HTTP_FILTER_REVISION; 

        strcpy_s(pVer->lpszFilterDesc, "HTTP/1.0 Blocker"); 

returnTRUE; 

}

//-------------------------------------------------------

// This function will be invoked on every request 

//-------------------------------------------------------

DWORD WINAPI __stdcall HttpFilterProc(HTTP_FILTER_CONTEXT *pfc, DWORD NotificationType, VOID *pvData) 

{ 

char buffer[256];

    DWORD buffSize = sizeof(buffer);

    HTTP_FILTER_PREPROC_HEADERS *p;

switch (NotificationType)  

    {

case SF_NOTIFY_PREPROC_HEADERS :

      p = (HTTP_FILTER_PREPROC_HEADERS *)pvData;

      BOOL bHeader = p->GetHeader(pfc,"version",buffer,&buffSize); 

      CString Version(buffer);

if(Version.Find("HTTP/1.0") != -1) 

      {

// If HTTP/1.0 then Request, then change the URL

            p->SetHeader(pfc, "url", "/Rejected:HTTP/1.0_is_not_supported");

      }

return SF_STATUS_REQ_HANDLED_NOTIFICATION; 

    }

return SF_STATUS_REQ_NEXT_NOTIFICATION; 

}

• Go to Project properties and change the configuration type to Dynamic Library (.dll).
• Add a new file and call it HttpversionBlocker.def. copy paste the below section into it:

• Build the project.
• This will generate the HttpVersionBlocker.dll
• Configure this as an Isapi filter in IIS. You can refer the below link to do this: Installing ISAPI Filters (IIS 6.0)

Alternatively, if one is not comfortable with coding there is another option. There is a 3rd party product that I’ve used in the past to achieve the same result. It is called WebKnight. Here is the link: http://www.aqtronix.com/?PageID=136.

This product is kind of a Application Firewall and can be used to block incoming requests on IIS.

The product can be downloaded freely, while they charge for the support.

You can try it at your own risk.

I don’t have much understanding of the product and neither do we support it so I’ll best leave it here.

NOTE: Neither of the solutions for IIS 6 is supported by Microsoft, as this is a problem with the protocol and not IIS.

It is not possible to install IIS on a non-system drive. Well “not possible” may be too restrictive, I would say it is not recommended or not supported to do so.

At CSS we see a lot of issues relating to the above topic. One needs to relocate (or even Install) the IIS related folder to other drive than system drive.

They say that it is a Security Vulnerability. This is the confusing part. What is this Vulnerability?

• The important point is how the web-application is configured and not where IIS is installed. None of the application will ever have access to the IIS related folders.
• Consider a scenario where you configure your application to run under the context of an administrator or Local System. If the application is compromised, then the entire server is compromised.
• Irrespective of where the application is installed, if it is not configured properly, then it is of now use where or how you install the web-app.

The recommended suggestion is to configure your application on a non-system drive, so that in case if there is a compromise, it doesn’t have access to system drive.

NOTE: W3WP.exe cannot access the IIS Installation folders or Data directories. You can restrict access to folders on the server via NTFS permissions.

It is neither supported nor recommended to delete or re-locate the original IIS directories. A support article has been issued to address this situation.

Here is the link: http://support.microsoft.com/kb/2752331 

This contains the script that can be used to relocate the IIS data directories to a non-system drive keeping the original directories intact.

There have been many occasions where a event corresponding to SChannel is logged in the System event logs which indicates a problem with the SSL/TLS handshake and many a times depicts a number. The logging mechanism is a part of the SSL/TLS Alert Protocol. These alerts are used to notify peers of the normal and error conditions. The numbers especially, play a trivial role in understanding the problem/failure with the SSL/TLS handshake.

SChannel logging may have to be enabled on the windows machines to get detailed SChannel messages. Please refer the following article to do so: http://support.microsoft.com/kb/260729

Below is an example of one such event:

These warnings sometimes are very helpful in troubleshooting SSL related issues and provide important clues. However, there is not much documentation available on the description of the alert codes.

These alert codes have been defined precisely in TLS/SSL RFC’s for all the existing protocol versions. For example lets consider the RFC 5246 (TLS 1.2). This RFC corresponds to the latest protocol version and it defines the alert messages.

Follow this link: http://tools.ietf.org/html/rfc5246#appendix-A.3

Below is a snippet from the above RFC describing the various alert messages:

There is MSDN article which describes these messages more briefly. Here is the link: http://technet.microsoft.com/en-us/library/cc783349%28v=ws.10%29.aspx.

However, the article never mentions the alert codes while explaining the messages. For simplicity, I have created a simpler table combining both the MSDN documentation and the RFC for usability. Below is the table:

There were few articles that I found while searching that contain additional alert codes. However, I don’t find these to be part of the RFC. Here is one: http://botan.randombit.net/doxygen/classBotan_1_1TLS_1_1Alert.html

It includes additional alerts like 110, 111, 112, 113, 114, 115. You can browse the above link for further reading.

Hope someone finds the above table useful. It may not help you in solving any issue but would provide useful pointers.

Until then, Ciao!