Cns Unit-Iv Web Security

Download as pdf or txt
Download as pdf or txt
You are on page 1of 12

CNS UNIT-IV

Web Security
Usage of internet for transferring or retrieving the data has got many benefits like speed, reliability,
security etc. Much of the Internet's success and popularity lies in the fact that it is an open global
network. At the same time, the fact that it is open and global makes it not very secure. The unique
nature of the Internet makes exchanging information and transacting business over it inherently
dangerous. The faceless, voiceless, unknown entities and individuals that share the Internet may or may
not be who or what they profess to be. In addition, because the Internet is a global network, it does not
recognize national borders and legal jurisdictions. As a result, the transacting parties may not be where
they say they are and may not be subject to the same laws or regulations.

For the exchange of information and for commerce to be secure on any network, especially the Internet,
a system or process must be put in place that satisfies requirements for confidentiality, access control,
authentication, integrity, and non-repudiation. These requirements are achieved on the Web through the
use of encryption and by employing digital signature technology. There are many examples on the
Web of the practical application of encryption. One of the most important is the SSL protocol.

A summary of types of security threats faced in using the Web is given below:

Web Security Threats:


Table 16.1 provides a summary of the types of security threats faced when using the Web. 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; Part Four of
this book addresses the issue of system security in general but is also applicable to Web system
security. Issues of traffic security fall into the category of network security and are addressed in this
chapter.
Secure Socket Layer/Transport Layer Security:
Secure Socket Layer (SSL) provides security services between TCP and applications that use TCP. The
Internet standard version is called Transport Layer Service (TLS).
SSL/TLS provides confidentiality using symmetric encryption and message integrity using a message
authentication code.
SSL/TLS includes protocol mechanisms to enable two TCP users to determine the security mechanisms
and services they will use.

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 consensus was
reached to submit the protocol for Internet standardization, the TLS working group was formed within
IETF to develop a common standard. This first published version of TLS can be viewed as essentially
an SSLv3.1 and is very close to and backward compatible with SSLv3.

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 protocols, as illustrated in
Figure 16.2.
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 defined as part of
SSL: the Handshake Protocol, The Change Cipher Spec Protocol, and the Alert Protocol. These SSL-
specific protocols are used in the management of SSL exchanges and are examined later in this section.
Two important SSL concepts are the SSL session and the SSL connection, which are defined in the
specification as follows.
 Connection: A connection is a transport (in the OSI layering model definition) that provides a
suitable type of service. For SSL, such connections are peer-to-peer relationships. The
connections are transient. Every connection is associated with one session.
 Session: An SSL session is an association between a client and a server. Sessions are 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.

There are a number of states associated with each session. Once a session is established, there is a
current operating state for both read and write (i.e., receive and send). In addition, during the
Handshake Protocol, pending read and write states are created. Upon successful conclusion of the
Handshake Protocol, the pending states become the current states.

A session state is defined by the following parameters.


 Session identifier: An arbitrary byte sequence chosen by the server to identify an active or
resumable session state.
 Peer certificate: An X509.v3 certificate of the peer. This element of the state may be null.
 Compression method: The algorithm used to compress data prior to encryption.
 Cipher spec: Specifies the bulk data encryption algorithm (such as null,AES, etc.) and a hash
algorithm (such as MD5 or SHA-1) used for MAC calculation. It also defines cryptographic
attributes such as the hash_size.
 Master secret: 48-byte secret shared between the client and server.

 Is resumable: A flag indicating whether the session can be used to initiate new connections.

A connection state is defined by the following parameters


 Server and client random: Byte sequences that are chosen by the server and client for each
connection.
 Server write MAC secret: The secret key used in MAC operations on data sent by the server.
 Client write MAC secret: The secret key used in MAC operations on data sent by the client.
 Server write key: The secret encryption key for data encrypted by the server and decrypted by
the client.
 Client write key: The symmetric encryption key for data encrypted by the client and decrypted
by the server.
 Initialization vectors: When a block cipher in CBC mode is used, an initialization vector (IV) is
maintained for each key. This field is first initialized by the SSL Handshake Protocol.
Thereafter, the final cipher-text block from each record is preserved for use as the IV with the
following record.
 Sequence numbers: Each party maintains separate sequence numbers for transmitted and
received messages for each connection. When a party sends or receives a change cipher spec
message, the appropriate sequence number is set to zero. Sequence numbers may not exceed 2 64
– 1.
SSL Record Protocol
The SSL Record Protocol provides two services for SSL connections:
 Confidentiality: The Handshake Protocol defines a shared secret key that is used for
conventional encryption of SSL payloads.
 Message Integrity: The Handshake Protocol also defines a shared secret key that is used to form
a message authentication code (MAC).

Figure 16.3 indicates 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 before being delivered
to higher-level users.
The first step is fragmentation. Each upper-layer message is fragmented into blocks of 214 bytes
(16384 bytes) or less. Next, compression is optionally applied. Compression must be lossless and may
not increase the content length by more than 1024 bytes.1In SSLv3 (as well as the current version of
TLS), no compression algorithm is specified, so the default compression algorithm is null.
The next step in processing is to compute a message authentication code over the compressed data.
For this purpose, a shared secret key is used.

SSL Handshake Protocol Message Types


The exchange is initiated by the client, which sends a client_hello message with the following
parameters:
 Version: The highest SSL version understood by the client.
 Random: A client-generated random structure consisting of a 32-bit timestamp and 28 bytes
generated by a secure random number generator. These values serve as nonces and are used
during key exchange to prevent replay attacks.
 Session ID: A variable-length session identifier. A nonzero value indicates that the client wishes
to update the parameters of an existing connection or to create a new connection on this session.
A zero value indicates that the client wishes to establish a new connection on a new session.
 CipherSuite: This is a list that contains the combinations of cryptographic algorithms supported
by the client, in decreasing order of preference. Each element of the list (each cipher suite)
defines both a key exchange algorithm and a CipherSpec; these are discussed subsequently.
 Compression Method: This is a list of the compression methods the client supports.

SSL Alert Protocol

The SSL Alert Protocol signals problems with an SSL session.

Alert messages convey the severity of the message and a description of the alert.
Upon transmission or receipt of a fatal alert message, both parties immediately close the
connection.

The client and the server must communicate that the connection is ending to avoid a truncation attack.
Either party may initiate the exchange of closing messages.
Normal termination occurs when the close_notify message is sent.
This message notifies the recipient that the sender will not send any more messages
on this connection.
The session becomes unresumable if any connection is terminated without a
proper close_notify message.

The following error alerts are defined:


unexpected_message
An inappropriate message was received. This alert is always fatal and should never be observed in
communication between proper implementations.
bad_record_mac
This alert is returned if a record is received with an incorrect message authentication code. This message is
always fatal.
decompression_failure
The decompression function received improper input (e.g. data that would expand to excessive length). This
message is always fatal.
handshake_failure
Indicates the sender was unable to negotiate an acceptable set of security parameters given the options
available. This is a fatal error.
no_certificate
May be sent in response to a certification request if no appropriate certificate is available.
bad_certificate
A certificate was corrupt, probably contained a digital signature that did not verify correctly.
unsupported_certificate
A certificate was of an unsupported type.
certificate_revoked
A certificate was revoked by its signer.
certificate_expired
A certificate has expired or is not currently valid.
certificate_unknown
Some unspecified issue arose in processing the certificate, rendering it unacceptable.
illegal_parameter
A field in the handshake was out of range or inconsistent with other fields. This is always fatal.

Transport Layer Security


TLS was released in response to the Internet community’s demands for a standardized
protocol. TLS (Transport Layer Security), defined in RFC 2246, is a protocol for establishing a secure
connection between a client and a server. TLS (Transport Layer Security) is capable of
authenticating both the client and the server and creating a encrypted connection between the two.
Many protocols use TLS (Transport Layer Security) to establish secure connections, including HTTP,
IMAP, POP3, and SMTP. The TLS Handshake Protocol first negotiates key exchange using an
asymmetric algorithm such as RSA or Diffie- Hellman. The TLS Record Protocol then begins
opens an encrypted channel using a symmetric algorithm such as RC4, IDEA, DES, or 3DES.
The TLS Record Protocol is also responsible for ensuring that the communications are not altered in
transit. Hashing algorithms such as MD5 and SHA are used for this purpose. RFC 2246 is very similar
to SSLv3. There are some minor differences ranging from protocol version numbers to generation of
key material.

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

Message Authentication Code: Two differences arise one being the actual algorithm and the other
being scope of MAC calculation. TLS makes use of the HMAC algorithm defined in RFC 2104. SSLv3
uses the same algorithm, except that the padding bytes are concatenated with the secret key rather than
being XORed with the secret key padded to the block length. For TLS, the MAC calculation
encompasses the fields.
Secure Shell Protocol (SSH)
The salient features of SSH are as follows −

SSH is a network protocol that runs on top of the TCP/IP layer. It is designed to replace the TELNET which
provided unsecure means of remote logon facility.

SSH provides a secure client/server communication and can be used for tasks such as file transfer and e-mail.

SSH2 is a prevalent protocol which provides improved network communication security over earlier version
SSH1.

SSH Defined
SSH is organized as three sub-protocols.

Transport Layer Protocol − This part of SSH protocol provides data confidentiality, server (host) authentication,
and data integrity. It may optionally provide data compression as well.

Server Authentication − Host keys are asymmetric like public/private keys. A server uses a public key
to prove its identity to a client. The client verifies that contacted server is a “known” host from the
database it maintains. Once the server is authenticated, session keys are generated.

Session Key Establishment − After authentication, the server and the client agree upon cipher to be
used. Session keys are generated by both the client and the server. Session keys are generated before user
authentication so that usernames and passwords can be sent encrypted. These keys are generally replaced
at regular intervals (say, every hour) during the session and are destroyed immediately after use.

Data Integrity − SSH uses Message Authentication Code (MAC) algorithms to for data integrity check.
It is an improvement over 32 bit CRC used by SSH1.

User Authentication Protocol − This part of SSH authenticates the user to the server. The server verifies that
access is given to intended users only. Many authentication methods are currently used such as, typed passwords,
Kerberos, public-key authentication, etc.

Connection Protocol − This provides multiple logical channels over a single underlying SSH connection.
SSH Services:
SSH provides three main services that enable provision of many secure solutions. services are briefly described as
follows −

Secure Command-Shell (Remote Logon) − It allows the user to edit files, view the contents of directories, and
access applications on connected device. Systems administrators can remotely start/view/stop services and
processes, create user accounts, and change file/directories permissions and so on. All tasks that are feasible at a
machine’s command prompt can now be performed securely from the remote machine using secure remote logon.

Secure File Transfer − SSH File Transfer Protocol (SFTP) is designed as an extension for SSH-2 for secure file
transfer. In essence, it is a separate protocol layered over the Secure Shell protocol to handle file transfers. SFTP
encrypts both the username/password and the file data being transferred. It uses the same port as the Secure Shell
server, i.e. system port no 22.

Port Forwarding (Tunneling) − It allows data from unsecured TCP/IP based applications to be secured. After
port forwarding has been set up, Secure Shell reroutes traffic from a program (usually a client) and sends it across
the encrypted tunnel to the program on the other side (usually a server). Multiple applications can transmit data
over a single multiplexed secure channel, eliminating the need to open many ports on a firewall or router.

You might also like