Network and cyber security imp notes PDF

Title Network and cyber security imp notes
Author Zayn arjun
Course Network and Cyber Security
Institution Visvesvaraya Technological University
Pages 49
File Size 5.4 MB
File Type PDF
Total Downloads 66
Total Views 283

Summary

Module – 11) Write the comparison of Threats on the Web. 08M Table 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 se...


Description

Network and Cyber Security

17EC835

Module – 1 1) Write the comparison of Threats on the Web. 08M Table 1.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. Table 1.1: A Comparison of Threats on the Web

Active attacks include imp server, and altering inf terms of the locatio and server.

ther user, altering messages in transit between client and Web site. Another way to classify Web security threats is in : Web server, Web browser, and network traffic between browser

2) Describ Two im sp

tion and SSL session in detail. (08M June-2019) (08M Dec-2019) oncepts are the SSL session and the SSL connection, which are defined in the llows. tion: A connection is a transport (in the OSI layering model definition) that provides a table 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 several 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 writes states are created. Upon successful conclusion of the Handshake Protocol, the pending states become the current states. Dept. of ECE, GAT, Bengaluru-560098

Page 1

Network and Cyber Security

17EC835

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 connec A connection state is defined by the following parameters ➢ Server and client random: Byte sequences that are chosen by the server and h connection. ➢ Server write MAC secret: The secret key used in MAC operations on da server. ➢ Client write MAC secret: The secret key used in MAC operations on he client. ➢ Server write key: The secret encryption key for data encrypted b nd decrypted by the client. ➢ Client write key: The symmetric encryption key for ed by the client and decrypted by the server. ➢ Initialization vectors: When a block cipher in CB , an initialization vector (IV) is maintained for each key. This field is fir y the SSL Handshake Protocol. Thereafter, the final cipher-text block from s preserved for use as the IV with the following record. ➢ Sequence numbers: Each party m rate sequence numbers for transmitted and received messages for each co n a party sends or receives a change cipher spec message, the appropriate s er is set to zero. Sequence numbers may not exceed 264 – 1. 3) Explain the opera Dec-2019)

ecord protocol with a neat sketch. (08M June-2019) (04M

Figure 1.1: SSL Record Protocol Operation 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. Dept. of ECE, GAT, Bengaluru-560098

Page 2

Network and Cyber Security

17EC835

➢ Message Integrity: The Handshake Protocol also defines a shared secret key that is used to form a message authentication code (MAC). Figure 1.1 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 by (16384 bytes) or less. Next, compression is optionally applied. Compression must be lossles may not increase the content length by more than 1024 bytes. In SSLv3 (as well as th version of TLS), no compression algorithm is specified, so the default compression algo The next step in processing is to compute a message authentication code over the ta. For this purpose, a shared secret key is used. 4) Explain the four phases of Handshake protocol with a diagram. (0 9) (10M Dec2019) The most complex part of SSL is the Handshake Protocol. This p the server and client to authenticate each other and to negotiate an encryption ithm and cryptographic keys to be used to protect data sent in an SSL record. T Protocol is used before any application data is transmitted. The Handshake Protocol consists of a ser s exchanged by client and server. Each message has three fields: ➢ Type (1 byte): Indicates one of 10 me 1.2 lists the defined message types. ➢ Length (3 bytes): The length of th bytes. ➢ Content (≥ 0bytes): The para ated with this message; these are listed in Table 1.2.

Figure: Handshake Protocol Table 1.2: SSL Handshake Protocol Message Types

Dept. of ECE, GAT, Bengaluru-560098

Page 3

Network and Cyber Security

17EC835

F Figure 1.2 shows the initia server. The exchange ca

dshake Protocol Action ded to establish a logical connection between client and having four phases.

PHASE 1: Establis abilities This phase is u a logical connection and to establish the security capabilities that will be associate exchange is initiated by the client, which sends a client_hello message. PHASE entication and Key Exchange The this phase by sending its certificate if it needs to be authenticated; the message c a chain of X.509 certificates. The certificate message is required for any agreed-on ge method except anonymous Diffie-Hellman. Note that if fixed Diffie-Hellman is used, tificate message functions as the server’s key exchange message because it contains the er’s public Diffie-Hellman parameters. In Phase-2 server may send certificate, key exchange, and request certificate. Server signals end of hello message phase. PHASE 3: Client Authentication and Key Exchange This phase provides client authentication to the server. ➢ The client verifies the server certificates and checks whether the server_hello parameters are acceptable. Dept. of ECE, GAT, Bengaluru-560098

Page 4

Network and Cyber Security

17EC835

➢ Moreover, if all is satisfactory, the client sends a certificate message if the server has requested a certificate. If no suitable certificate is available, the client sends a no_certificate alert. ➢ Next is the client_key_exchange message which has the same parameters as the server-keyexchange message. ➢ Similarly, the client may send a certificate_verify message to provide explicit verification of a client certificate. The client encrypts all the previous messages and master secret with its private key. PHASE 4: Finish This phase completes the setting up of a secure connection. The client sends a change_ciph message and copies the pending CipherSpec into the current CipherSpec. Note that this not considered part of the Handshake Protocol but is sent using the Change Cipher . The client then immediately sends the finished message under the new algo and secrets. The finished message verifies that the key exchange and authenti es were successful. 5) Explain the additional alert codes in TLS over SSL. (04M De TLS supports all of the alert codes defined in SSLv3 with the _certificate. A number of additional codes are defined in TLS; of these, the followin itical. • record_overflow: A TLS record was received with hertext) whose length exceeds 214+1024 bytes, or the ciphertext decrypted t eater than 214+1024 bytes. • unknown_ca: A valid certificate chain or was received, but the certificate was not accepted because the CA certifica e located or could not be matched with a known, trusted CA. • access_denied: A valid certifi ved, but when access control was applied, the sender decided not to proc egotiation. • decode_error: A messa e decoded, because either a field was out of its specified range or the length e was incorrect. • protocol_versio version the client attempted to negotiate is recognized but not supported. • insuffic Returned instead of handshake_failure when a negotiation has failed spec e the server requires ciphers more secure than those supported by the •



d_extension: Sent by clients that receives an extended server hello containing an on not in the corresponding client hello. rnal_error: An internal error unrelated to the peer or the correctness of the protocol makes it impossible to continue. decrypt_error: A handshake cryptographic operation failed, including being unable to verify a signature, decrypts a key exchange, or validates a finished message.

The remaining alerts include the following. • user_canceled: This handshake is being canceled for some reason unrelated to a protocol failure. • no_renegotiation: Sent by a client in response to a hello request or by the server in response to a client hello after initial handshaking. Either of these messages would normally result in Dept. of ECE, GAT, Bengaluru-560098

Page 5

Network and Cyber Security

17EC835

renegotiation, but this alert indicates that the sender is not able to renegotiate. This message is always a warning. 6) Explain connection initiation and connection closure in HTTPS. (06M) Connection Initiation: For HTTPS, the agent acting as the HTTP client also acts as the TLS client. The client initiates a connection to the server on the appropriate port and then sends the TLS ClientHello to begin the TLS handshake. When the TLS handshake has finished; the client may then initiate the first HTTP request. All HTTP data is to be sent as TLS application data. Normal HTTP behavior, including retained connections, should be followed. Connection Closure: An HTTP client or server can indicate the closing of a connection by i the following line in an HTTP record: Connection: close. This indicates that the conne closed after this record is delivered. The closure of an HTTPS connection requires that TLS close the connectio TLS entity on the remote side, which will involve closing the underlying TCP c the TLS level, the proper way to close a connection is for each side to use the TL ol to send a close_notify alert. TLS implementations must initiate an exchange of before closing a connection. A TLS implementation may, after sending a closure a connection without waiting for the peer to send its closure alert, generating a close”. Note that an implementation that does this may choose to reuse the ses uld only be done when the application knows (typically through detecting HTTP m daries) that it has received all the message data that it cares about. 7) Explain SSH Transport layer protocol 2019)

ation, with a neat sketch. (08M June-

Figure 1.3: SSH Transport Layer Protocol Packet Formation Once the connection is established, the client and server exchange data, referred to as packets, in the data field of a TCP segment. Each packet is in the following format (Figure 1.3). • Packet length: Length of the packet in bytes, not including the packet length and MAC fields. • Padding length: Length of the random padding field. Dept. of ECE, GAT, Bengaluru-560098

Page 6

Network and Cyber Security

17EC835

Payload: Useful contents of the packet. Prior to algorithm negotiation, this field is uncompressed. If compression is negotiated, then in subsequent packets, this field is compressed. • Random padding: Once an encryption algorithm has been negotiated, this field is added. It contains random bytes of padding so that that total length of the packet (excluding the MAC field) is a multiple of the cipher block size, or 8 bytes for a stream cipher. • Message authentication code (MAC): If message authentication has been negotiated, this field contains the MAC value. The MAC value is computed over the entire packet plus a sequence number, excluding the MAC field. The sequence number is an implicit 32-bit pac sequence that is initialized to zero for the first packet and incremented for every pack sequence number is not included in the packet sent over the TCP connection. Once an encryption algorithm has been negotiated, the entire packet (excluding the encrypted after the MAC value is calculated. •

8) Discuss sequence of steps involved during message exchange ntication protocols of SSH. (06M Dec-2019) The message exchange involves the following steps. 1. The client sends a SSH_MSG_USERAUTH_REQUEST with ethod of none. 2. The server checks to determine if the user name not, the server returns SSH_MSG_USERAUTH_FAILURE with the partial of false. If the user name is valid, the server proceeds to step 3. 3. The server returns SSH_MSG_USERAUTH_ a list of one or more authentication methods to be used. 4. The client selects one of the authentication methods and sends a SSH_MSG_USERAUTH_REQUE ethod name and the required method-specific fields. At this point, there m ce of exchanges to perform the method. 5. If the authentication su ore authentication methods are required, the server proceeds to step 3, u uccess value of true. If the authentication fails, the server proceeds to step 3 al success value of false. 6. When all thentication methods succeed, the server sends a SSH_MSG SUCCESS message, and the Authentication Protocol is over. 9) Explai The S se

tion protocol message exchange. 08M Protocol runs on top of the SSH Transport Layer Protocol and assumes that a ation connection is in use. That secures authentication connection, referred to as a s used by the Connection Protocol to multiplex a number of logical channels. L MECHANISM: All types of communication using SSH, such as a terminal session, are rted using separate channels. Either side may open a channel. For each channel, each side sociates a unique channel number, which need not be the same on both ends. Channels are flow controlled using a window mechanism. No data may be sent to a channel until a message is received to indicate that window space is available. The life of a channel progresses through three stages: opening a channel, data transfer, and closing a channel. Figure 1.4 provides an example of Connection Protocol Message Exchange.

Dept. of ECE, GAT, Bengaluru-560098

Page 7

Network and Cyber Security

17EC835

Figure 1.4: Example of SSH Connection ge exchange. When either side wishes to open a new channel, it cal number for the channel and then sends a message of the form: byte SSH_ L_OPEN string channel uint32 nel uint32 ndow size uint32 mum packet size .... hannel type specific data follows Where uint32 means u integer. The channel type identifies the application for this channel, as describ ly. The sender channel is the local channel number. The initial window size spe ny bytes of channel data can be sent to the sender of this message without adju ndow. The maximum packet size specifies the maximum size of an individua hat can be sent to the sender. For example, one might want to use smaller packe ve connections to get better interactive response on slow links. remote side is able to open the channel, it returns a HANNEL_OPEN_CONFIRMATION message, which includes the sender channel the recipient channel number, and window and packet size values for incoming traffic. wise, the remote side returns a SSH_MSG_CHANNEL_OPEN_FAILURE message with a reason ode indicating the reason for failure. Once a channel is open, data transfer is performed using a SSH_MSG_CHANNEL_DATA message, which includes the recipient channel number and a block of data. These messages, in both directions, may continue as long as the channelis open. When either side wishes to close a channel, it sends a SSH_MSG_CHANNEL_CLOSE message, which includes the recipient channel number.

Dept. of ECE, GAT, Bengaluru-560098

Page 8

Network and Cyber Security

17EC835

10) What is port forwarding? Explain local and remote forwarding. (06M) One of the most useful features of SSH is port forwarding. In essence, port forwarding provides the ability to convert any insecure TCP connection into a secure SSH connection. This is also referred to as SSH tunneling. A port is an identifier of a user of TCP. So, any application that runs on top of TCP has a port number. Incoming TCP traffic is delivered to the appropriate application on the basis of the port number. An application may employ multiple port numbers. SSH supports two types of port forwarding: local forwarding and remote forwarding. Local forwarding allows the client to set up a “hijacker” process. This will intercept select application-level traffic and redirect it from an unsecured TCP connection to a secure SSH t SSH is configured to listen on selected ports.SSH grabs all traffic using a selected port an through an SSH tunnel. On the other end, the SSH server sends the incoming destination port dictated by the client application. With remote forwarding, the user’s SSH client acts on the server’s behalf. T ves traffic with a given destination port number, places the traffic on the corre nds it to the destination the user chooses. A typical example of remote forwardi ing. You wish to access a server at work from your home computer. Because the behind a firewall, it will not accept an SSH request from your home computer. H work you can set up an SSH tunnel using remote forwarding. This involves the fol 1. From the work computer, set up an SSH conne ome computer. The firewall will allow this, because it is a protected outgoin 2. Configure the SSH server to listen on a 22, and to deliver data across the SSH connection addressed to remote port 3. You can now go to your home co onfigure SSH to accept traffic on port 2222. 4. You now have an SSH tunne sed for remote logon to the work server.

Dept. of ECE, GAT, Bengaluru-560098

Page 9

Network and Cyber Security

17EC835

Module – 2 1) Write the summary of PGP services. (06M) Function Digital signature

Table: Summary of PGP Services Algorithms Used Description DSS/SHA or RSA/SHA A hash code of a message is created using SHA1.This message digest is encrypted using DSS or RSA with the sender’s private key and included with the message.

Message encryption

CAST or IDEA or Three-key Triple DES with DiffieHellman or RSA

Compression

ZIP

E-mail compatibility

Radix-64 conversion

A message is encrypted using CAST-128 or IDE 3DES with a one-time session key generated sender. The session key is encrypted u Hellman or RSA with the recipient’s p included with the message. A message may be compre ge or transmission using ZIP. To provide transparenc plications, an encrypted message ted to an ASCII string using radix

ZIP → Compression algorithm CAST→ Design pro IDEA→ International Data Encryption Algorithm Radix64→ It maps arbitrary binary into printable ch 2) With relevant diagram explain the con PG...


Similar Free PDFs