35 Web Security :SSL and TLS

Learning Objectives

• To identify variety of threats and web security issues

• To identify need for security

• Keep security simple

• Detect intrusions with the help of security mechanism

Introduction

The World Wide Web is widely used by businesses, government agencies, and many individuals. But the Internet and the Web are extremely vulnerable to compromises of various sorts, with a range of threats as shown. These can be described as passive attacks including eavesdropping on network traffic between browser and server and gaining access to information on a Web site that is supposed to be restricted, and active attacks including impersonating another user, altering messages in transit between client and server, and altering information on a Web site. The web needs added security mechanisms to address these threats and we focus on security at the transport layer: SSL/TLS, HTTPS, and SSH.

1.Web Security Considerations

World Wide Web is fundamentally a client/server application running over the Internet and TCP/IP intranets. The Web presents new challenges not generally appreciated in the context of computer and network security:

The Internet is two way. Unlike traditional publishing environments, even electronic publishing systems involving Teledex, voice response or fax-back, the Web is vulnerable to attacks on the Web servers over the Internet.

The Web is increasingly serving as a highly visible outlet for corporate and product information and as the platform for business transactions. Reputations can be damaged and money can be lost if the Web servers are subverted.

Although Web browsers are very easy to use, Web servers are relatively easy to configure and manage, and Web content is increasingly easy to develop, the underlying software is extraordinarily complex. This complex software may hide many potential security flaws. The short history of the Web is filled with examples of new and upgraded systems, properly installed, that are vulnerable to a variety of security attacks.

A Web server can be exploited as a launching pad into the corporation’s or agency’s entire computer complex. Once the Web server is subverted, an attacker may be able to gain access to data and systems not part of the Web itself but connected to the server at the local site.

Casual and untrained (in security matters) users are common clients for Web-based services. Such users are not necessarily aware of the security risks that exist and do not have the tools or knowledge to take effective countermeasures.

1.1 Web Security Threats

One way to group these threats is in terms of passive and active attacks. Passive attacks include eavesdropping on network traffic between browser and server and gaining access to information on a Web site that is supposed to be restricted. Active attacks include impersonating another user, altering messages in transit between client and server, and altering information on a Web site. Another way to classify Web security threats is in terms of the location of the threat: Web server, Web browser, and network traffic between browser and server. Issues of server and browser security fall into the category of computer system security.

1.2 Web Traffic Security Approaches

A number of approaches to provide Web security are possible. The various approaches that have been considered are similar in the services they provide and, to some extent, in the mechanisms that they use, but they differ with respect to their scope of applicability and their relative location within the TCP/IP protocol stack.

Figure 1.1 illustrates this difference. One way to provide Web security is to use IP Security. The advantage of using IPsec is that it is transparent to end users and applications and provides a general-purpose solution. Further, IPsec includes a filtering capability so that only selected traffic need incur the overhead of IPsec processing.

Another relatively general-purpose solution is to implement security just above TCP. The foremost example of this approach is the Secure Sockets Layer (SSL) and the follow-on Internet standard known as Transport Layer Security (TLS). At this level, there are two implementation choices. For full generality, SSL (or TLS) could be provided as part of the underlying protocol suite and therefore be transparent to applications. Alternatively, SSL can be embedded in specific packages. For example, Netscape and Microsoft Explorer browsers come equipped with SSL, and most Web servers have implemented the protocol.

2. Secure Socket Layer (SSL)

Netscape originated SSL. Version 3 of the protocol was designed with public review and input from industry and was published as an Internet draft document. Subsequently, when a consenses was reached to submit the protocol for Internet standardization, the TLS working group was formed within the IETF to develop a common standard.

2.1 SSL Architecture

SSL is designed to make use of TCP to provide a reliable end-to-end secure service. SSL is not a single protocol but rather two layers of protocol, as shown in Figure 2.1. The SSL Record Protocol provides basic security services to various higher-layer protocols. In particular, the Hypertext Transfer Protocol (HTTP), which provides the transfer service for Web client/server interaction, can operate on top of SSL. Three higher-layer protocols are also defined as part of SSL: the Handshake Protocol, Change Cipher Spec Protocol, and Alert Protocol. These SSL-specific protocols are used in the management of SSL exchanges.

Two important SSL concepts are the SSL connection and the SSL session:

•    Connection: A connection is a network transport that provides a suitable type of service, such connections are transient, peer-to-peer relationships, associated with one session.

•   Session: An SSL session is an association between a client and a server, created by the Handshake Protocol. Sessions define a set of cryptographic security parameters, which can be shared among multiple connections. Sessions are used to avoid the expensive negotiation of new security parameters for each connection.

2.2 SSL Record Protocol

SSL Record Protocol defines two services for SSL connections:

• Message Integrity: The Handshake Protocol also defines a shared secret key that is used to form a message authentication code (MAC), which is similar to HMAC.

• Confidentiality: The Handshake Protocol defines a shared secret key that is used for conventional encryption of SSL payloads. The message is compressed before being concatenated with the MAC and encrypted, with a range of ciphers being supported. P-515

Figure 2.2 shows the overall operation of the SSL Record Protocol. The Record Protocol takes an application message to be transmitted, fragments the data into manageable blocks, optionally compresses the data, applies a MAC, encrypts, adds a header, and transmits the resulting unit in a TCP segment. Received data are decrypted, verified, decompressed, and reassembled and then delivered to higher-level users. Figure 2.3 illustrates the SSL record format. IT consisting of the following fields:

    Content Type (8 bits): The higher layer protocol used to process the enclosed fragment.

Major Version (8 bits): Indicates major version of SSL in use. For SSLv3, the value is 3.

Minor Version (8 bits): Indicates minor version in use. For SSLv3, the value is 0.

Compressed Length (16 bits): The length in bytes of the plaintext fragment. The maximum value is 214 + 2048.

2.3 Change Cipher Spec Protocol

The Change Cipher Spec Protocol is one of the three SSL-specific protocols that use the SSL Record Protocol, and it is the simplest. It consists of a single message (Figure 2.4a), which consists of single byte with the value 1. Its purpose is to cause the pending state to be copied into the current state, which updates the cipher suite to be used on this connection.

2.3 Change Cipher Spec Protocol

The Change Cipher Spec Protocol is one of the three SSL-specific protocols that use the SSL Record Protocol, and it is the simplest. It consists of a single message (Figure 2.4a), which consists of single byte with the value 1. Its purpose is to cause the pending state to be copied into the current state, which updates the cipher suite to be used on this connection.

2.4 Handshake Protocol

The most complex part of SSL is the Handshake Protocol. This protocol allows the server and client to authenticate each other and to negotiate an encryption and MAC algorithm and cryptographic keys to be used to protect data sent in an SSL record. The Handshake Protocol is used before any application data is transmitted. The Handshake Protocol consists of a series of messages exchanged by client and server. The format of the Handshake Protocol shown in Figure 2.4c. Each message has three fields:

    Type (1byte): Indicates one of 10 messages. Table 2.1 lists the defined message types.

Length (3bytes): The length of the message in bytes.

Content (≥ 0 bytes): The parameters associated with this message; these are listed in Table 2.1.

Fig 2.5 shows the initial exchange needed to establish a logical connection between client and server. The exchange can be viewed in 4 phases:

Phase 1. Establish Security Capabilities – This phase is used by the client to initiate a logical connection and to establish the security capabilities that will be associated with it.

Phase 2. Server Authentication and Key Exchange – The server begins this phase by sending its certificate if it needs to be authenticated.

Phase 3. Client Authentication and Key Exchange – The client should verify that the server provided a valid certificate if required and check that the server_hello parameters are acceptable.

Phase 4. Finish – This phase completes the setting up of a secure connection. The client sends a change_cipher_spec message and copies the pending CipherSpec into the current CipherSpec.

3. Transport Layer Security (TLS)

TLS is an IETF standardization initiative whose goal is to produce an Internet standard version of SSL. TLS is defined as a Proposed Internet Standard in RFC 2246. RFC 2246 is very similar to SSLv3. Some of the minor differences in the areas are:

Version Number: The TLS Record Format is the same as that of the SSL Record Format (Figure 2.3), and the fields in the header have the same meanings. The one difference is in the current version of TLS, the Major Version is 3 and the Minor Version is 1.

Message Authentication Code (MAC): There are two differences between the SSLv3 and TLS MAC schemes: the actual algorithm and the scope of the MAC calculation. TLS makes use of the HMAC algorithm defined in RFC 2104.

Pseudo-random Function: TLS makes use of a pseudorandom function referred to as PRF to expand secrets into blocks of data for purposes of key generation or validation. The objective is to make use of a relatively small shared secret value but to generate longer blocks of data in a way that is secure from the kinds of attacks made on hash functions and MACs. In Figure 2.6 illustrate the PRF is based on the following data expansion function.

Alert Codes: TLS supports all of the alert codes defined in SSLv3 with the exception of no_certificate.

Cipher Suites: There are several small differences between the cipher suites available under SSLv3 and under TLS:

• Key Exchange: TLS supports all of the key exchange techniques of SSLv3 with the exception of Fortezza.
• Symmetric Encryption Algorithms: TLS includes all of the symmetric encryption algorithms found in SSLv3, with the exception of Fortezza.

Client Certificate Types: TLS defines the following certificate types to be requested in a certificate_request message: rsa_sign, dss_sign, rsa_fixed_dh, and dss_fixed_dh. These are all defined in SSLv3. In addition, SSLv3 includes rsa_ephemeral_dh, dss_ephemeral_dh, and fortezza_kea. TLS does not include the Fortezza scheme.

Certificate_Verify and Finished Messages: In the TLS certificate_verify message, the MD5 and SHA-1 hashes are calculated only over handshake_messages. Recall that for SSLv3, the hash calculation also included the master secret and pads.

Cryptographic Computations: The pre_master_secret for TLS is calculated in the same way as in SSLv3. As in SSLv3, the master_secret in TLS is calculated as a hash function of the pre_master_secret and the two hello random numbers.

Padding: In  SSL,  the  paddingaddedpriortoencryptionofuserdatais  the minimum amount required so that the total size of the data to be encrypted is a multiple of the cipher’s block length. In TLS, the padding can be any amount that results in a total that is a multiple of the cipher’s block length, up to a maximum of 255 bytes.

4. Secure Electronic Transactions (SET)

SET is an open encryption and security specification designed to protect credit card transactions on the Internet. SETv1 emerged from a call for security standards by MasterCard and Visa in 1996. Beginning in 1996, there have been numerous tests of the concept, and by 1998 the first wave of SET-compliant products was available. SET is not itself a payment system, rather it is a set of security protocols and formats that enables users to employ the existing credit card payment infrastructure on an open network, such as the Internet, in a secure fashion. In essence, SET provides three services:

• Provides a secure communications channel among all parties involved in a transaction.

• Provides trust through the use of X.509v3 digital certificates.

• Ensures privacy because the information is only available to parties in a transaction when and where necessary.

4.1 SET Requirements

SET specification lists the following business requirements for secure payment processing with credit cards over the Internet and other networks:

●   Provide confidentiality of payment and ordering information: It is necessary to assure cardholders that this information is safe and accessible only to the intended recipient. Confidentiality also reduces the risk of fraud by either party to the transaction or by malicious third parties. SET uses encryption to provide confidentiality.

●   Ensure the integrity of all transmitted data: That is, ensure that no changes in content occur during transmission of SET messages. Digital signatures are used to provide integrity.

• Provide authentication that a cardholder is a legitimate user of a credit card account: A mechanism that links a cardholder to a specific account number reduces the incidence of fraud and the overall cost of payment processing. Digital signatures and certificates are used to verify that a cardholder is a legitimate user of a valid account.

• Provide authentication that a merchant can accept credit card transactions through its relationship with a financial institution: This is the complement to the preceding requirement. Cardholders need to be able to identify merchants with whom they can conduct secure transactions. Again, digital signatures and certificates are used.

• Ensure the use of the best security practices and system design techniques to protect all legitimate parties in an electronic commerce transaction: SET is a well-tested specification based on highly secure cryptographic algorithms and protocols.

• Create a protocol that neither depends on transport security mechanisms nor prevents their use: SET can securely operate over a “raw” TCP/IP stack. However, SET does not interfere with the use of other security mechanisms, such as IPSec and SSL/TLS.

• Facilitate and encourage interoperability among software and network providers: The SET protocols and formats are independent of hardware platform, operating system, and Web software.

4.2 Key Features of SET

• To meet the requirements just outlined, SET incorporates the following features:.
  • Confidentiality of information
  • Integrity of data
  • Cardholder account authentication
  • Merchant authentication

4.3 SET Participants

Figure4.1 indicates the participants in the SET system, being:

• Cardholder: The purchasers interact with merchants from personal computers over the Internet.

• Merchant: A person or organization that has goods or services to sell to the cardholder.

• Issuer: A financial institution, such as a bank, that provides the cardholder with the payment card.

• Acquirer: A financial institution that establishes an account with a merchant and processes payment card authorizations and payments.

• Payment gateway: A function operated by the acquirer or a designated third party that processes merchant payment messages.

• Certification authority (CA): An entity that is trusted to issue X.509v3 public-key certificates for cardholders, merchants, and payment gateways.

4.4 SET Transaction

The sequence of events that are required for a transaction.

•       The customer opens an account: The customer obtains a credit card account, such as MasterCard or Visa, with a bank that supports electronic payment and SET.

•       The customer receives a certificate: After suitable verification of identity, the customer receives an X.509v3 digital certificate, which is signed by the bank.

•       Merchants have their own certificates: A merchant who accepts a certain brand of card must be in possession of two certificates for two public keys owned by the merchant: one for signing messages, and one for key exchange.

•       The customer places an order: This is a process that may involve the customer first browsing through the merchant’s Web site to select items and determine the price.

•       The merchant is verified: In addition to the order form, the merchant sends a copy of its certificate, so that the customer can verify that he or she is dealing with a valid store.

•       The order and payment are sent: The customer sends both order and payment information to the merchant, along with the customer’s certificate.

•       The merchant requests payment authorization. The merchant sends the payment information to the payment gateway, requesting authorization that the customer’s available credit is sufficient for this purchase.

•       The merchant confirms the order. The merchant sends confirmation of the order to the customer.

•       The merchant provides the goods or service. The merchant ships the goods or provides the service to the customer.

•       The merchant requests payment. This request is sent to the payment gateway, which handles all of the payment processing.

4.5 Dual Signature

The purpose of the SET dual signature is to link two messages that are intended for two different recipients, the order information (OI) for the merchant and the payment information (PI) for the bank. The merchant does not need to know the customer’s credit card number, and the bank does not need to know the details of the customer’s order, however the two items must be linked in a way that can be used to resolve disputes if necessary. Figure 4.2 shows the use of a dual signature to meet the requirements. The customer takes the hash (using SHA-1) of the PI and the hash of the OI, concatenates them, and hashes the result. Finally, the customer encrypts the final hash with his or her private signature key, creating the dual signature. This can be summarized as: DS=E(PRc, [H(H(PI)||H(OI))]).

4.5.1 Payment Processing

Table 4.1 lists the transaction types supported by SET. In some detail at the following transactions:

• Purchase request
  • Payment authorization
  • Payment capture

Table 4.1 SET Transaction

Types 4.5.2 SET Purchase Request

The purchase request exchange consists of four messages: Initiate Request, Initiate Response, Purchase Request, and Purchase Response. In order to send SET messages to the merchant, the cardholder must have a copy of the certificates of the merchant and the payment gateway. The customer requests the certificates in the Initiate Request message, sent to the merchant. The merchant generates a response and signs it with its private signature key. The cardholder verifies the merchant and gateway certificates by means of their respective CA signatures and then creates the OI and PI. Next, the cardholder prepares the Purchase Request message with Purchase-related information & Order-related information. The Purchase Response message includes a response block that acknowledges the order and references the corresponding transaction number.

In Figure 4.3 shows the details of the contents of the Purchase Request message generated by the customer. The message includes the following:

1. Purchase-related information: This information will be forwarded to the payment gateway by the merchant and consists of PI, dual signature and OI message digest (OIMD).
2. Order-related information: This information needed by the merchant and consists of: OI, dual signature, PI message digest (PIMD).
3. Cardholder certificate: This contains the cardholder’s public signature key.

When the merchant receives the Purchase Request message, it performs the following actions (Figure 4.4):

1.   Verifies cardholder certificates using CA signatures.

2. Verifies dual signature using customer’s public signature key to ensure order has not been tampered with in transit & that it was signed using cardholder’s private signature key.

3. Processes order and forwards the payment information to the payment gateway for authorization.

4. Sends a purchase response to cardholder.

4.5.3 Payment Authorization

The merchant sends an Authorization Request message to the payment gateway consisting of the following:

1. Purchase-related information.

2. Authorization-related information.

3. Certificates.

• The payment gateway performs the following tasks:

1. Verifies all certificates.

2. Decrypts digital envelope of authorization block to obtain symmetric key & then decrypts authorization block.

3. Verifies merchant’s signature on authorization block.

4. Decrypts digital envelope of payment block to obtain symmetric key & then decrypts payment block.

5. Verifies dual signature on payment block.

6. Verifies that transaction ID received from merchant matches that in PI received (indirectly) from customer.

7. Requests & receives an authorization from issuer.

8. Sends authorization response back to merchant.

Having obtained authorization from the issuer, the payment gateway returns an Authorization Response message to the merchant. It includes the following elements:

1.    Authorization-related information.

2. Capture token information.

3. Certificate.

4.5.3 Payment Capture

To obtain payment, the merchant sends a capture request message to the payment gateway, for which the merchant generates, signs, and encrypts a capture request block, including payment amount and transaction ID. The payment gateway receives the capture request message, decrypts and verifies the capture request block and decrypts and verifies the capture token block. It then checks for consistency between the capture request and capture token. It then creates a clearing request sent to the issuer over the private payment network, which causes funds to be transferred to the merchant’s account. The gateway then notifies the merchant of payment in a Capture Response message, which includes a capture response block that the gateway signs and encrypts, plus the gateway’s signature key certificate. The merchant software stores the capture response to be used for reconciliation with payment received from the acquirer.

Summary

In this module, need for web security, SSL/TLS transport layer security protocols, SET secure credit card payment protocols are considered to provide a better security in web. SSL provides secure channel over any TCP based protocol and it has an optional for server authentication with public key cryptography. SSL security provides good randomness and protects server’s private keys.