Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

 

Secure Communication

J.D. Meier, Alex Mackman, Michael Dunner, and Srinath Vasireddy
Microsoft Corporation

Published: November 2002

Last Revised: January 2006

See the "patterns & practices Security Guidance for Applications Index" for links to additional security resources.

See the Landing Page for the starting point and a complete overview of Building Secure ASP.NET Applications.

Summary: This chapter introduces the two core technologies that can be used to provide message confidentiality and message integrity for data that flows across the network between clients and servers on the Internet and corporate intranet. These are SSL and IPSec. It also discusses RPC encryption, which can be used to secure the communication with remote serviced components. (10 printed pages)

Contents

Know What to Secure
SSL/TLS
IPSec
RPC Encryption
Point-to-Point Security
Choosing Between IPSec and SSL
Farming and Load Balancing
Summary

Many applications pass security sensitive data across networks to and from end users and between intermediate application nodes. Sensitive data might include credentials used for authentication, or data such as credit card numbers or bank transaction details. To guard against unwanted information disclosure and to protect the data from unauthorized modification while in transit, the channel between communication end points must be secured.

Secure communication provides the following two features:

• Privacy. Privacy is concerned with ensuring that data remains private and confidential, and cannot be viewed by eavesdroppers who may be armed with network monitoring software. Privacy is usually provided by means of encryption.
• Integrity. Secure communication channels must also ensure that data is protected from accidental or deliberate (malicious) modification while in transit. Integrity is usually provided by using Message Authentication Codes (MACs).

This chapter covers the following secure communication technologies:

• Secure Sockets Layer / Transport Layer Security (SSL/TLS). This is most commonly used to secure the channel between a browser and Web server. However, it can also be used to secure Web service messages and communications to and from a database server running Microsoft® SQL Server™.
• Internet Protocol Security (IPSec). IPSec provides a transport level secure communication solution and can be used to secure the data sent between two computers; for example, an application server and a database server.
• Remote Procedure Call (RPC) Encryption. The RPC protocol used by Distributed COM (DCOM) provides an authentication level (packet privacy) that results in the encryption of every packet of data sent between client and server.

Know What to Secure

When a Web request flows across the physical deployment tiers of your application, it crosses a number of communication channels. A commonly used Web application deployment model is shown in Figure 4.1.

Figure 4.1. A typical Web deployment model

In this typical deployment model, a request passes through three distinct channels. The client-to-Web server link may be over the Internet or corporate intranet and typically uses HTTP. The remaining two links are between internal servers within your corporate domain. Nonetheless, all three links represent potential security concerns. Many purely intranet-based applications convey security sensitive data between tiers; for example, HR and payroll applications that deal with sensitive employee data.

Figure 4.2 shows how each channel can be secured by using a combination of SSL, IPSec and RPC encryption.

Figure 4.2. A typical Web deployment model, with secure communications

The choice of technology depends on a number of factors including the transport protocol, end point technologies, and environmental considerations (such as hardware, operating system versions, firewalls, and so on).

SSL/TLS

SSL/TLS is used to establish an encrypted communication channel between client and server. The handshake mechanism used to establish the secure channel is well documented and details can be found in the following articles in the Microsoft Knowledge Base:

• Q257591, Description of the Secure Sockets Layer (SSL) Handshake
• Q257587, Description of the Server Authentication Process During the SSL Handshake
• Q257586, [Content link no longer available, original URL:"https://support.microsoft.com//default.aspx?scid=kb;[LN];Q257586"] Description of the Client Authentication Process During the SSL Handshake

Using SSL

When you use SSL you should be aware of the following:

• When SSL is applied, the client uses the HTTPS protocol (and specifies an https:// URL) and the server listens on TCP port 443.

• You should monitor your application's performance when you enable SSL.

  SSL uses complex cryptographic functions to encrypt and decrypt data and as a result impacts the performance of your application. The largest performance hit occurs during the initial handshake, where asymmetric public/private-key encryption is used. Subsequently (after a secure session key is generated and exchanged), faster, symmetric encryption is used to encrypt application data.

• You should optimize pages that use SSL by including less text and simple graphics in those pages.

• Because the performance hit associated with SSL is greatest during session establishment, ensure that your connections do not time out.

  You can fine tune this by increasing the value of the ServerCacheTime registry entry. For more information, see article Q247658, HOW TO: Configure Secure Sockets Layer Server and Client Cache Elements in the Microsoft Knowledge Base.

• SSL requires a server authentication certificate to be installed on the Web server (or database server if you are using SSL to communicate with SQL Server). For more information about installing server authentication certificates, see How To: Set Up SSL on a Web Server in the How To section of this guide.

IPSec

IPSec can be used to secure the data sent between two computers; for example, an application server and a database server. IPSec is completely transparent to applications as encryption, integrity, and authentication services are implemented at the transport level. Applications continue to communicate with one another in the normal manner using TCP and UDP ports.

Using IPSec you can:

• Provide message confidentiality by encrypting all of the data sent between two computers.
• Provide message integrity between two computers (without encrypting data).
• Provide mutual authentication between two computers (not users). For example, you can help secure a database server by establishing a policy that permits requests only from a specific client computer (for example, an application or Web server).
• Restrict which computers can communicate with one another. You can also restrict communication to specific IP protocols and TCP/UDP ports.

Note   IPSec is not intended as a replacement for application level security. Today it is used as a defense-in-depth mechanism or to secure insecure applications without changing them, and to secure non-TLS protocols from network-wire attacks.

Using IPSec

When you use IPSec you should be aware of the following:

• IPSec can be used for both authentication and encryption.

• There are no IPSec APIs for developers to programmatically control settings. IPSec is completely controlled and configured through the IPSec snap-in, within the Local Security Policy Microsoft Management Console (MMC).

• IPSec in the Microsoft Windows® 2000 operating system cannot secure all types of IP traffic.

  Specifically, it cannot be used to secure Broadcast, Multicast, Internet Key Exchange, or Kerberos (which is already a secure protocol) traffic.

  For more information, see article Q253169, Traffic That Can and Cannot Be Secured by IPSec, in the Microsoft Knowledge Base.

  Note   Windows Server 2003 removes all default exemptions, except for the Internet Key Exchange (IKE) exemption. Changes to existing IPSec policy designs may be required before you can use the policy on Windows Server 2003. For more information, see article Q810207, "IPSec default exemptions are removed in Windows Server 2003" in the Microsoft Knowledge Base.

• You use IPSec filters to control when IPSec is applied.

  To test the IPSec policies, use IPSec Monitor. IPSec Monitor (Ipsecmon.exe) provides information about which IPSec policy is active and whether a secure channel between computers is established.

  For more information, see the Knowledge Base articles:

  • Q313195, HOW TO: Use IPSec Monitor in Windows 2000
  • Q231587, [Content link no longer available, original URL:"https://support.microsoft.com//default.aspx?scid=kb;[LN];Q231587"] Using the IP Security Monitor Tool to View IPSec Communications

• To establish a trust between two servers, you can use IPSec with mutual authentication. This uses certificates to authenticate both computers.

  For more information, see the following Knowledge Base articles:

  • Q248711, Mutual Authentication Methods Supported for L2TP/IPSec
  • Q253498, HOW TO: Install a Certificate for Use with IP Security

• If you need to use IPSec to secure communication between two computers that are separated by a firewall, make sure that the firewall does not use Network Address Translation (NAT). IPSec does not work with any NAT-based devices.

  For more information and configuration steps, see article Q233256, HOW TO Enable IPSec Traffic through a Firewall in the Microsoft Knowledge Base and How To: Use IPSec to Provide Secure Communication Between Two Servers in the Reference section of this guide.

RPC Encryption

RPC is the underlying transport mechanism used by DCOM. RPC provides a set of configurable authentication levels that range from no authentication (and no protection of data) to full encryption of parameter state.

The most secure level (RPC Packet Privacy) encrypts parameter state for every remote procedure call (and therefore every DCOM method invocation). The level of RPC encryption, 40-bit or 128-bit, depends on the version of the Windows operating system that is running on the client and server computers.

Using RPC Encryption

You are most likely to want to use RPC encryption when your Web-based application communicates with serviced components (within Enterprise Services server applications) located on remote computers.

In this event, to use RPC Packet Privacy authentication (and encryption) you must configure both the client and the server. A process of high-water mark negotiation occurs between client and server, which ensures that the higher of the two (client and server) settings are used.

The server settings can be defined at the (Enterprise Services) application level, either by using .NET attributes within your serviced component assembly, or by using the Component Services administration tool at deployment time.

If the client is an ASP.NET Web application or Web service, the authentication level used by the client is configured using the comAuthenticationLevel attribute on the <processModel> element within Machine.config. This provides the default authentication level for all ASP.NET applications that run on the Web server.

More information

For more information about RPC authentication level negotiation and service component configuration, see Chapter 9, Enterprise Services Security.

Point-to-Point Security

• Point-to-point communication scenarios can be broadly categorized into the following topics:
  • Browser to Web Server
  • Web Server to Remote Application Server
  • Application Server to Database Server

Browser to Web Server

To secure sensitive data sent between a browser and Web server, use SSL. You need to use SSL in the following situations:

• You are using Forms authentication and need to secure the clear text credentials submitted to a Web server from a logon form.

  In this scenario, you should use SSL to secure access to all secured pages (not just the logon page) to ensure that the authentication cookie, generated as a result on the initial authentication process, remains secure throughout the lifetime of the client's browser session with the application.

• You are using Basic authentication and need to secure the (Base64 encoded) clear text credentials.

  You should use SSL to secure access to all pages (not just the initial log on), as Basic authentication sends the clear text credentials to the Web server with all requests to the application (not just the initial one).

  Note   Base64 is used to encode binary data as printable ASCII text. Unlike encryption, it does not provide message integrity or privacy.

• Your application passes sensitive data between the browser and Web server (and vice-versa); for example, credit card numbers or bank account details.

Web Server to Remote Application Server

The transport channel between a Web server and a remote application server should be secured by using IPSec, SSL or RPC Encryption. The choice depends on the transport protocols, environmental factors (operating system versions, firewalls and so on).

• Enterprise Services. If your remote server hosts one or more serviced components (in an Enterprise Services server application) and you are communicating directly with them (and as a result using DCOM), use RPC Packet Privacy encryption.

  For more information about how to configure RPC encryption between a Web application and remote serviced component, see Chapter 9, Enterprise Services Security.

• Web Services. If your remote server hosts a Web service, you can choose between IPSec and SSL.

  You should generally use SSL because the Web service already uses the HTTP transport. SSL also allows you to only encrypt the data sent to and from the Web service (and not all traffic sent between the two computers). IPSec results in the encryption of all traffic sent between the two computers.

  Note   Message-level security (including data encryption) is addressed by the Global XML Web Services Architecture (GXA) initiative and specifically the WS-Security specification. Microsoft provides the Web Services Development Toolkit to allow you to develop message level security solutions.

• .NET Components (using .NET Remoting). If your remote server hosts one or more .NET components and you connect to them over the TCP channel, you can use IPSec to provide a secure communication link. If you host the .NET components within ASP.NET, you can use SSL (configured using IIS).

Application Server to Database Server

To secure the data sent between an application server and database server, you can use IPSec. If your database server runs SQL Server 2000 (and the SQL Server 2000 network libraries are installed on the application server), you can use SSL. This latter option requires a server authentication certificate to be installed in the database server's machine store.

You may need to secure the link to the database server in the following situations:

• You are connecting to the database server and are not using Windows authentication. For example, you may be using SQL authentication to SQL Server or you may be connecting to a non-SQL Server database. In these cases, the credentials are passed in clear text, which can represent a significant security concern.

  Note   One of the key benefits of using Windows authentication to SQL Server is that it means that the credentials are never passed across the network. For more information about Windows and SQL authentication, see Chapter 12, Data Access Security.

• Your application may be submitting and retrieving sensitive data to and from the database (for example, payroll data).

Using SSL to SQL Server

Consider the following points if you use SSL to secure the channel to a SQL Server database:

• For SSL to work, you must install a server authentication certificate in the machine store on the database server computer. The client computer must also have a root Certificate Authority certificate from the same (or trusting) authority that issued the server certificate.
• Clients must have the SQL Server 2000 connectivity libraries installed. Earlier versions or generic libraries will not work.
• SSL only works for TCP/IP (the recommended communication protocol for SQL Server) and named pipes.
• You can configure the server to force the use of encryption for all connections (from all clients).
• On the client, you can:
  • Force the use of encryption for all outgoing connections.
  • Allow client applications to choose whether or not to use encryption on a per-connection basis, by using the connection string.
• Unlike IPSec, configuration changes are not required if the client or server IP addresses change.

More information

For more information about using SSL to SQL Server, see the following resources:

• How To: Use SSL to Secure Communication with SQL Server 2000 in the Reference section of this guide
• Webcast: Microsoft SQL Server 2000: How to Configure SSL Encryption (April 23, 2002)

Choosing Between IPSec and SSL

Consider the following points when choosing between IPSec and SSL:

• IPSec can used to secure all IP traffic between computers; SSL is specific to an individual application.
• IPSec is a computer-wide setting and does not support the encryption of specific network connections. However, sites can be partitioned to use or not use SSL. Also, when you use SSL to connect to SQL Server, you can choose on a per connection basis (from the client application) whether or not to use SSL.
• IPSec is transparent to applications, so it can be used with secure protocols that run on top of IP such as HTTP, FTP and SMTP. However, SSL/TLS is closely tied to the application.
• IPSec can be used for computer authentication in addition to encryption. This is particularly significant for trusted subsystem scenarios, where the database authorizes a fixed identity from a specific application (running on a specific computer). IPSec can be used to ensure that only the specific application server can connect to the database server, in order to prevent attacks from other computers.
• IPSec requires that both computers run Windows 2000 or later.
• SSL can work through a NAT-based firewall; IPSec cannot.

Farming and Load Balancing

If you use SSL in conjunction with multiple virtual Web sites, you need to use unique IP addresses or unique port numbers. You cannot use multiple sites with the same IP address and port number. If the IP address is combined with a server affinity setting in a load balancer, this will work fine.

More Information

For more information, see Q187504, HTTP 1.1 Host Headers Are Not Supported When You Use SSL, in the Microsoft Knowledge Base.

Summary

This chapter described how a combination of SSL, IPSec and RPC encryption can be used to provide an end-to-end secure communication solution for your distributed application. To summarize:

• Channel security is a concern for data passed over the Internet and on the corporate intranet.
• Consider the security requirements of the Web browser to Web server, Web server to application server, and application server to database server links.
• Secure communication provides privacy and integrity. It does not protect you from non-repudiation (for this use, client certificates)
• Channel security options include SSL, IPSec and RPC Encryption. The latter option applies when your application uses DCOM to communicate with remote serviced components.
• If you use SSL to communicate with SQL Server, the application can choose (on a per-connection basis) whether or not to encrypt the connection.
• IPSec encrypts all IP traffic that flows between two computers.
• The choice of security mechanism is dependent upon transport protocol, operating system versions, and network considerations (including firewalls).
• There is always a trade-off between secure communication and performance. Choose the level of security that is appropriate to your application requirements.

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

© Microsoft Corporation. All rights reserved.