One problem when you administer a network is securing data that is being sent between applications across an untrusted network. You can use TLS/SSL to authenticate servers and clients and then use it to encrypt messages between the authenticated parties.
The Transport Layer Security (TLS) protocol, Secure Sockets Layer (SSL) protocol, versions 2.0 and 3.0, and the Private Communications Transport (PCT) protocol are based on public key cryptography. The Security Channel (Schannel) authentication protocol suite provides these protocols. All Schannel protocols use a client/server model.
In the authentication process, a TLS/SSL client sends a message to a TLS/SSL server, and the server responds with the information that the server needs to authenticate itself. The client and server perform an additional exchange of session keys, and the authentication dialog ends. When authentication is completed, SSL-secured communication can begin between the server and the client using the symmetric encryption keys that are established during the authentication process.
For servers to authenticate to clients, TLS/SSL does not require server keys to be stored on domain controllers or in a database, such as the Microsoft Active Directory directory service. Clients confirm the validity of a server’s credentials with a trusted root certification authority’s (CA’s) certificates, which are loaded when you install Microsoft Windows Server 2003. Therefore, unless user authentication is required by the server, users do not need to establish accounts before they create a secure connection with a server.
History and Standards for TLS and SSL
SSL was developed by Netscape Communications Corporation in 1994 to secure transactions over the World Wide Web. Soon after, the Internet Engineering Task Force (IETF) began work to develop a standard protocol that provided the same functionality. They used SSL 3.0 as the basis for that work, which became the TLS protocol. The implementation of the TLS protocol in Windows Server 2003 closely follows the specification defined in Request for Comments (RFC) 2246, The TLS Protocol Version 1.0. For more information about TLS, see RFC 2246 in the IETF RFC database.
TLS and SSL are most widely recognized as the protocols that provide secure HTTP (HTTPS) for Internet transactions between Web browsers and Web servers. TLS/SSL can also be used for other application level protocols, such as File Transfer Protocol (FTP), Lightweight Directory Access Protocol (LDAP), and Simple Mail Transfer Protocol (SMTP). TLS/SSL enables server authentication, client authentication, data encryption, and data integrity over networks such as the World Wide Web.
Differences between TLS and SSL
Although there are some slight differences between SSL 3.0 and TLS 1.0, this reference refers to the protocol as TLS/SSL.
Note
Although their differences are minor, TLS 1.0 and SSL 3.0 are not interchangeable. If the same protocol is not supported by both parties, the parties must negotiate a common protocol to communicate successfully.
TLS Enhancements to SSL
The keyed-Hashing for Message Authentication Code (HMAC) algorithm replaces the SSL Message Authentication Code (MAC) algorithm.
HMAC produces more secure hashes than the MAC algorithm. The HMAC produces an integrity check value as the MAC does, but with a hash function construction that makes the hash much harder to break. For more information about the HMAC, see “Hash Algorithms in The Handshake Layer in TLS/SSL Architecture” in How TLS/SSL Works.
TLS is standardized in RFC 2246.
Many new alert messages are added.
In TLS, it is not always necessary to include certificates all the way back to the root CA. You can use an intermediary authority.
TLS specifies padding block values that are used with block cipher algorithms. RC4, which is used by Microsoft, is a streaming cipher, so this modification is not relevant.
Fortezza algorithms are not included in the TLS RFC, because they are not open for public review. (This is Internet Engineering Task Force (IETF) policy.)
Minor differences exist in some message fields.
Benefits of TLS/SSL
TLS/SSL provides numerous benefits to clients and servers over other methods of authentication, including:
Strong authentication, message privacy, and integrity
Interoperability
Algorithm flexibility
Ease of deployment
Ease of use
Strong authentication, message privacy, and integrity
TLS/SSL can help to secure transmitted data using encryption. TLS/SSL also authenticates servers and, optionally, authenticates clients to prove the identities of parties engaged in secure communication. It also provides data integrity through an integrity check value. In addition to protecting against data disclosure, the TLS/SSL security protocol can be used to help protect against masquerade attacks, man-in-the-middle or bucket brigade attacks, rollback attacks, and replay attacks.
Interoperability
TLS/SSL works with most Web browsers, including Microsoft Internet Explorer and Netscape Navigator, and on most operating systems and Web servers, including the Microsoft Windows operating system, UNIX, Novell, Apache (version 1.3 and later), Netscape Enterprise Server, and Sun Solaris. It is often integrated in news readers, LDAP servers, and a variety of other applications.
Algorithm flexibility
TLS/SSL provides options for the authentication mechanisms, encryption algorithms, and hashing algorithms that are used during the secure session.
Note
Data can be encrypted and decrypted, but you cannot reverse engineer a hash. Hashing is a one-way process. Running the process backward will not create the original data. This is why a new hash is computed and then compared to the sent hash.
Ease of deployment
Many applications use TLS/SSL transparently on a Windows Server 2003 operating system. You can use TLS for more secure browsing when you are using Internet Explorer and Internet Information Services (IIS) and, if the server already has a server certificate installed, you only have to select the check box.
Ease of use
Because you implement TLS/SSL beneath the application layer, most of its operations are completely invisible to the client. This allows the client to have little or no knowledge of the security of communications and still be protected from attackers.
Limitations of TLS/SSL
There are a few limitations to using TLS/SSL, including:
Increased processor load
This is the most significant limitation to implementing TLS/SSL. Cryptography, specifically public key operations, is CPU-intensive. As a result, performance varies when you are using SSL. Unfortunately, there is no way to know how much performance you will lose. The performance varies, depending on how often connections are established and how long they last. TLS uses the greatest resources while it is setting up connections.
Administrative overhead
A TLS/SSL environment is complex and requires maintenance; the system administrator must configure the system and manage certificates.
Common TLS/SSL Scenarios
Many people think of TLS and SSL as protocols that are used with Web browsers to browse the Internet more securely. However, they are also general purpose protocols that can be used whenever authentication and data protection are necessary. For example, you can use TLS/SSL for:
SSL-secured transactions with an e-commerce Web site
Authenticated client access to an SSL-secured Web site
Remote access
SQL access
E-mail
This is not an exhaustive list. In fact, the ability to access these protocols through Security Service Provider Interface (SSPI) means that you can use them for just about any application. Many applications are being modified to take advantage of the features of TLS/SSL.
SSL-secured transactions with an e-commerce Web site
This situation is a typical use of SSL between a browser and a Web server. An example is an e-commerce shopping site where clients need to provide their credit card numbers. The protocol first confirms that the certificate of the Web site is valid, and then sends the client’s credit card information as cipher text. For this type of transaction, where the server’s certificate comes from a trusted source, authentication only occurs for the server. TLS/SSL must be enabled for the Web page, such as an order form, where the data transactions occur.
Authenticated client access to an SSL-secured Web site
Both the client and server need certificates from a mutually-trusted certification authority (CA). With Schannel, client certificates can be mapped on a one-to-one or many-to-one basis to their Windows Server 2003 user or computer accounts, and they can be managed by Active Directory Users and Computers. Users can then be authenticated to a Web site without needing to supply a password.
Many-to-one mapping has several uses. For example, if you want to give several users access to confidential material, you can create a group, map the users’ certificates to the group, and give the group the necessary permissions to the material.
In one-to-one mapping, the server has a copy of the client’s certificate; whenever the client logs in; the server verifies that they are identical. This one-to-one mapping is typically used for private material, such as a banking Web site where only one individual has the right to view a personal account.
Remote access
In this situation, telecommuting is a common use for Schannel. You can use this technology to provide authentication and data protection when users remotely log in to Windows-based systems or networks. Users can more securely access their e-mail or enterprise applications from home or while traveling, reducing the risk of exposure of the information to anyone on the Internet.
SQL access
With Microsoft SQL Server, you can require authentication of the client when connecting to the server running SQL Server. Either the client or server can be configured to require encryption of the data that is transferred between them. Very sensitive information, such as financial or medical databases, can be protected to prevent unauthorized access and disclosure of information about the network.
E-mail
When using Exchange servers, you can use Schannel to help protect data as it moves from server to server on the intranet or Internet. Full end-to-end security might require the use of Secure/Multipurpose Internet Mail Extensions (S/MIME); however, helping to protect data in a server-to-server exchange allows companies to use the Internet to securely transfer e-mail among divisions within the same company, subsidiaries, and partners. This can be done regardless of whether S/MIME is used.
Technologies Related to Schannel
In the Windows Server 2003 operating system, the Schannel Security Support Provider SSP authentication protocol suite contains TLS. The following diagram shows where Schannel fits among these and other technologies in Windows Server 2003. Client applications or server applications use Secur32.dll by way of SSPI calls to communicate with the Local Security Authority Subsystem (LSASS).
Schannel Architecture
Below is a description of the components that participate in TLS/SSL.
Security Subsystem Components used in TLS/SSL Authentication
Component Description
Schannel.dll
The Transport Layer Security (TLS) and Secure Sockets Layer (SSL) authentication protocol. This protocol provides authentication over an encrypted channel instead of a less-secure clear channel.
Lsasrv.dll
The LSA Server service, which both enforces security policies and acts as the security package manager for the LSA.
Netlogon.dll
TLS-relevant services that the Net Logon service performs:
Net Logon passes the user’s certificate information through an SSL-secured channel to the domain controller to map the user certificate to a user account.
Secur32.dll
The multiple authentication provider that implements SSPI.
Ntdsa.dll
The directory service module, which supports the Windows Server 2003 and Windows 2000 replication protocol and LDAP, and manages partitions of data.
The authentication protocol suite is enabled by the Schannel .SSP, which is supported by the SSPI application programming interface (API) that provides the security services for Windows Server 2003 operating systems.
TLS and SSL Dependencies
TLS and SSL depend on several related technologies and resources to function properly. The following section describes these technologies and resources and summarizes how they relate to TLS/SSL authentication.
Operating system
TLS and SSL authentication relies on client functionality that is built into the Microsoft Windows Server 2003 operating system, the Microsoft Windows XP operating system, and the Microsoft Windows 2000 operating system. If a client or server is running an operating system that does not support TLS/SSL, it cannot use TLS/SSL authentication.
TCP/IP network connectivity
For TLS or SSL authentication to occur, there must be TCP/IP network connectivity between the client, and the target server. For more information about TCP/IP, see “TCP/IP Technical Reference.”
Active Directory domain
When a server application requires client authentication, Schannel automatically attempts to map the certificate that is supplied by the client to a user account. You can authenticate users who log on with a client certificate by manually creating mappings, which relate the certificate information to a Windows user account. After you create and enable a certificate mapping, each time a client presents a client certificate; your server application automatically associates that user with the appropriate Windows user account. You must use user accounts in the Active Directory directory service if you wish to use Active Directory certificate mapping. For more information about Active Directory, see “Active Directory Collection.”
Trusted certificate authorities
Because authentication relies on digital certificates, certification authorities (CAs) such as Verisign or Microsoft Certificate Server are an important part of TLS/SSL. A CA is a mutually-trusted third party that confirms the identity of a certificate requestor (usually a user or computer), and then issues the requestor a certificate. The certificate binds the requestor’s identity to a public key. CAs also renew and revoke certificates as necessary. For example, if a client is presented with a server’s certificate, the client computer might try to match the server’s CA against the client’s list of trusted CAs. If the issuing CA is trusted, the client will verify that the certificate is authentic and has not been tampered with. For more information about PKI Technologies, see “PKI Technologies.”
The Transport Layer Security (TLS) protocol, Secure Sockets Layer (SSL) protocol, versions 2.0 and 3.0, and the Private Communications Transport (PCT) protocol are based on public key cryptography. The Security Channel (Schannel) authentication protocol suite provides these protocols. All Schannel protocols use a client/server model.
In the authentication process, a TLS/SSL client sends a message to a TLS/SSL server, and the server responds with the information that the server needs to authenticate itself. The client and server perform an additional exchange of session keys, and the authentication dialog ends. When authentication is completed, SSL-secured communication can begin between the server and the client using the symmetric encryption keys that are established during the authentication process.
For servers to authenticate to clients, TLS/SSL does not require server keys to be stored on domain controllers or in a database, such as the Microsoft Active Directory directory service. Clients confirm the validity of a server’s credentials with a trusted root certification authority’s (CA’s) certificates, which are loaded when you install Microsoft Windows Server 2003. Therefore, unless user authentication is required by the server, users do not need to establish accounts before they create a secure connection with a server.
History and Standards for TLS and SSL
SSL was developed by Netscape Communications Corporation in 1994 to secure transactions over the World Wide Web. Soon after, the Internet Engineering Task Force (IETF) began work to develop a standard protocol that provided the same functionality. They used SSL 3.0 as the basis for that work, which became the TLS protocol. The implementation of the TLS protocol in Windows Server 2003 closely follows the specification defined in Request for Comments (RFC) 2246, The TLS Protocol Version 1.0. For more information about TLS, see RFC 2246 in the IETF RFC database.
TLS and SSL are most widely recognized as the protocols that provide secure HTTP (HTTPS) for Internet transactions between Web browsers and Web servers. TLS/SSL can also be used for other application level protocols, such as File Transfer Protocol (FTP), Lightweight Directory Access Protocol (LDAP), and Simple Mail Transfer Protocol (SMTP). TLS/SSL enables server authentication, client authentication, data encryption, and data integrity over networks such as the World Wide Web.
Differences between TLS and SSL
Although there are some slight differences between SSL 3.0 and TLS 1.0, this reference refers to the protocol as TLS/SSL.
Note
Although their differences are minor, TLS 1.0 and SSL 3.0 are not interchangeable. If the same protocol is not supported by both parties, the parties must negotiate a common protocol to communicate successfully.
TLS Enhancements to SSL
The keyed-Hashing for Message Authentication Code (HMAC) algorithm replaces the SSL Message Authentication Code (MAC) algorithm.
HMAC produces more secure hashes than the MAC algorithm. The HMAC produces an integrity check value as the MAC does, but with a hash function construction that makes the hash much harder to break. For more information about the HMAC, see “Hash Algorithms in The Handshake Layer in TLS/SSL Architecture” in How TLS/SSL Works.
TLS is standardized in RFC 2246.
Many new alert messages are added.
In TLS, it is not always necessary to include certificates all the way back to the root CA. You can use an intermediary authority.
TLS specifies padding block values that are used with block cipher algorithms. RC4, which is used by Microsoft, is a streaming cipher, so this modification is not relevant.
Fortezza algorithms are not included in the TLS RFC, because they are not open for public review. (This is Internet Engineering Task Force (IETF) policy.)
Minor differences exist in some message fields.
Benefits of TLS/SSL
TLS/SSL provides numerous benefits to clients and servers over other methods of authentication, including:
Strong authentication, message privacy, and integrity
Interoperability
Algorithm flexibility
Ease of deployment
Ease of use
Strong authentication, message privacy, and integrity
TLS/SSL can help to secure transmitted data using encryption. TLS/SSL also authenticates servers and, optionally, authenticates clients to prove the identities of parties engaged in secure communication. It also provides data integrity through an integrity check value. In addition to protecting against data disclosure, the TLS/SSL security protocol can be used to help protect against masquerade attacks, man-in-the-middle or bucket brigade attacks, rollback attacks, and replay attacks.
Interoperability
TLS/SSL works with most Web browsers, including Microsoft Internet Explorer and Netscape Navigator, and on most operating systems and Web servers, including the Microsoft Windows operating system, UNIX, Novell, Apache (version 1.3 and later), Netscape Enterprise Server, and Sun Solaris. It is often integrated in news readers, LDAP servers, and a variety of other applications.
Algorithm flexibility
TLS/SSL provides options for the authentication mechanisms, encryption algorithms, and hashing algorithms that are used during the secure session.
Note
Data can be encrypted and decrypted, but you cannot reverse engineer a hash. Hashing is a one-way process. Running the process backward will not create the original data. This is why a new hash is computed and then compared to the sent hash.
Ease of deployment
Many applications use TLS/SSL transparently on a Windows Server 2003 operating system. You can use TLS for more secure browsing when you are using Internet Explorer and Internet Information Services (IIS) and, if the server already has a server certificate installed, you only have to select the check box.
Ease of use
Because you implement TLS/SSL beneath the application layer, most of its operations are completely invisible to the client. This allows the client to have little or no knowledge of the security of communications and still be protected from attackers.
Limitations of TLS/SSL
There are a few limitations to using TLS/SSL, including:
Increased processor load
This is the most significant limitation to implementing TLS/SSL. Cryptography, specifically public key operations, is CPU-intensive. As a result, performance varies when you are using SSL. Unfortunately, there is no way to know how much performance you will lose. The performance varies, depending on how often connections are established and how long they last. TLS uses the greatest resources while it is setting up connections.
Administrative overhead
A TLS/SSL environment is complex and requires maintenance; the system administrator must configure the system and manage certificates.
Common TLS/SSL Scenarios
Many people think of TLS and SSL as protocols that are used with Web browsers to browse the Internet more securely. However, they are also general purpose protocols that can be used whenever authentication and data protection are necessary. For example, you can use TLS/SSL for:
SSL-secured transactions with an e-commerce Web site
Authenticated client access to an SSL-secured Web site
Remote access
SQL access
This is not an exhaustive list. In fact, the ability to access these protocols through Security Service Provider Interface (SSPI) means that you can use them for just about any application. Many applications are being modified to take advantage of the features of TLS/SSL.
SSL-secured transactions with an e-commerce Web site
This situation is a typical use of SSL between a browser and a Web server. An example is an e-commerce shopping site where clients need to provide their credit card numbers. The protocol first confirms that the certificate of the Web site is valid, and then sends the client’s credit card information as cipher text. For this type of transaction, where the server’s certificate comes from a trusted source, authentication only occurs for the server. TLS/SSL must be enabled for the Web page, such as an order form, where the data transactions occur.
Authenticated client access to an SSL-secured Web site
Both the client and server need certificates from a mutually-trusted certification authority (CA). With Schannel, client certificates can be mapped on a one-to-one or many-to-one basis to their Windows Server 2003 user or computer accounts, and they can be managed by Active Directory Users and Computers. Users can then be authenticated to a Web site without needing to supply a password.
Many-to-one mapping has several uses. For example, if you want to give several users access to confidential material, you can create a group, map the users’ certificates to the group, and give the group the necessary permissions to the material.
In one-to-one mapping, the server has a copy of the client’s certificate; whenever the client logs in; the server verifies that they are identical. This one-to-one mapping is typically used for private material, such as a banking Web site where only one individual has the right to view a personal account.
Remote access
In this situation, telecommuting is a common use for Schannel. You can use this technology to provide authentication and data protection when users remotely log in to Windows-based systems or networks. Users can more securely access their e-mail or enterprise applications from home or while traveling, reducing the risk of exposure of the information to anyone on the Internet.
SQL access
With Microsoft SQL Server, you can require authentication of the client when connecting to the server running SQL Server. Either the client or server can be configured to require encryption of the data that is transferred between them. Very sensitive information, such as financial or medical databases, can be protected to prevent unauthorized access and disclosure of information about the network.
When using Exchange servers, you can use Schannel to help protect data as it moves from server to server on the intranet or Internet. Full end-to-end security might require the use of Secure/Multipurpose Internet Mail Extensions (S/MIME); however, helping to protect data in a server-to-server exchange allows companies to use the Internet to securely transfer e-mail among divisions within the same company, subsidiaries, and partners. This can be done regardless of whether S/MIME is used.
Technologies Related to Schannel
In the Windows Server 2003 operating system, the Schannel Security Support Provider SSP authentication protocol suite contains TLS. The following diagram shows where Schannel fits among these and other technologies in Windows Server 2003. Client applications or server applications use Secur32.dll by way of SSPI calls to communicate with the Local Security Authority Subsystem (LSASS).
Schannel Architecture
Below is a description of the components that participate in TLS/SSL.
Security Subsystem Components used in TLS/SSL Authentication
Component Description
Schannel.dll
The Transport Layer Security (TLS) and Secure Sockets Layer (SSL) authentication protocol. This protocol provides authentication over an encrypted channel instead of a less-secure clear channel.
Lsasrv.dll
The LSA Server service, which both enforces security policies and acts as the security package manager for the LSA.
Netlogon.dll
TLS-relevant services that the Net Logon service performs:
Net Logon passes the user’s certificate information through an SSL-secured channel to the domain controller to map the user certificate to a user account.
Secur32.dll
The multiple authentication provider that implements SSPI.
Ntdsa.dll
The directory service module, which supports the Windows Server 2003 and Windows 2000 replication protocol and LDAP, and manages partitions of data.
The authentication protocol suite is enabled by the Schannel .SSP, which is supported by the SSPI application programming interface (API) that provides the security services for Windows Server 2003 operating systems.
TLS and SSL Dependencies
TLS and SSL depend on several related technologies and resources to function properly. The following section describes these technologies and resources and summarizes how they relate to TLS/SSL authentication.
Operating system
TLS and SSL authentication relies on client functionality that is built into the Microsoft Windows Server 2003 operating system, the Microsoft Windows XP operating system, and the Microsoft Windows 2000 operating system. If a client or server is running an operating system that does not support TLS/SSL, it cannot use TLS/SSL authentication.
TCP/IP network connectivity
For TLS or SSL authentication to occur, there must be TCP/IP network connectivity between the client, and the target server. For more information about TCP/IP, see “TCP/IP Technical Reference.”
Active Directory domain
When a server application requires client authentication, Schannel automatically attempts to map the certificate that is supplied by the client to a user account. You can authenticate users who log on with a client certificate by manually creating mappings, which relate the certificate information to a Windows user account. After you create and enable a certificate mapping, each time a client presents a client certificate; your server application automatically associates that user with the appropriate Windows user account. You must use user accounts in the Active Directory directory service if you wish to use Active Directory certificate mapping. For more information about Active Directory, see “Active Directory Collection.”
Trusted certificate authorities
Because authentication relies on digital certificates, certification authorities (CAs) such as Verisign or Microsoft Certificate Server are an important part of TLS/SSL. A CA is a mutually-trusted third party that confirms the identity of a certificate requestor (usually a user or computer), and then issues the requestor a certificate. The certificate binds the requestor’s identity to a public key. CAs also renew and revoke certificates as necessary. For example, if a client is presented with a server’s certificate, the client computer might try to match the server’s CA against the client’s list of trusted CAs. If the issuing CA is trusted, the client will verify that the certificate is authentic and has not been tampered with. For more information about PKI Technologies, see “PKI Technologies.”
No comments:
Post a Comment