MADIS SARALITA – 5112100038 Keamanan Informasi dan Jaringan (C)
PART 5: NETWORK AND
INTERNET SECURITY
CHAPTER 16
CHAPTER 16
TRANSPORT-LEVEL SECURITY
16.1 WEB SECURITY CONSIDERATIONS
Internet is two way –unlike tradition publishing, it’s vulnerable to attacks
High visibility– public image, reputation, copyrights
Complex software – protocol is simple, but client/server application is complex Vulnerability point – web server can be a launch pad for further attacks
Web Security Threats
Threats Consequences Countermeasures
Integrity Modification of user data
Trojan horse browser Modification of
memory Modification of
message traffic in transit
Loss of information Compromise of
machine
Vulnerabilty to all other threts
Cryptographic checksums
Confidentiality Eavesdropping on the Net
Theft of info from server
Theft of data from client
Info about network configuration Info about which
client talks to server
Loss of information Loss of privacy
Encryption, web proxies
Denial of Service
Killing of user threads
Flooding machine with bogus requests Filling up disk or
memory
Isolating machine by DNS attacks
Disruptive Annoying
Prevent user from getting work done
Difficult to prevent
Authentication Impersonation of legistimate users Data forger
Misrepresentation of user
Belief that false information is valid
Web Traffic Security Approaches
Classify security threats by location: web server, web browser and network traffic. We’re concerned with traffic.
IPsec
Secure Sockets Layer (SSL) Transport Layer Security (TLS) Secure Electronic Transaction (SET)
16.2 SECURE SOCKET LAYER AND TRANSPORT LAYER SECURITY
SSL Architecture
Depends on TCP for end-to-end reliability. Two layers of protocols :
o SSL Record Protocol – basic security services to higher layers.
o Three higher layer protocols - used in the management of SSL exchanges. Two important SSL concepts :
o Connection – peer-to-peer relationships in the transport layer. Every connection is associated with one session.
o Session – an association between a client and a server created by the Handshake Protocol.
- Define a set of cryptographic security parameters, which can be shared among multiple connections.
- Avoid the expensive negotiation of new security parameters for each connection.
SSL statefullness
o Multiple secure connections in a session. o Number of states associated with each session.
o Current operating state for read and write (receive and send). o Pending read and write states created during Handshake Protocol. Parameters of a session state :
o Session identifier – arbitrary byte sequence chosen by the server. o Peer certificate – X.509.v3 digital certificate of peer; may be null. o Compression method
o Cipher spec– algorithms used (AES, MD5). o Master secret – 48 byte shared key.
o Is resumable – session can be used to initiate new connections. Transparent
to end users
Above TCP. Embedded in packages
Parameters of a connection state :
o Server and client random – byte sequences chosen for each connection. o Server/Client write MAC secret – secret key used in MAC operations on data
sent by the server/client.
o Server/Client write key – conventional encryption key. o Initialization vectors – needed for CBC mode.
o Sequence numbers – separate for xmit & recv.
SSL Record Protocol
Provides two important services for SSL connections:
o Confidentiality – Handshake Protocol defines a secret key for conventional encryption of SSL payloads.
o Integrity – Handshake Protocol defines a shared secret key used to form a message authentication code (MAC).
Figure 1. SSL Record Protocol Operation Fragmentation– block of 16K bytes or less.
Compression– optional, must not increase content length beyond 1024 bytes.
Message authentication code (MAC) – uses shared secret key, similar to HMAC algorithm. HMAC
o Effort to develop a MAC derived from a cryptographic hash code. o Executes faster in software.
o No export restrictions. o Relies on a secret key.
o RFC 2104 list design objectives. o Used in Ipsec.
Message authentication code (MAC) – two pads are concatenated in SSLv3 but XORed in HMAC.
SSLv3 was based on original internet draft for HMAC, which used concatenation.
Message
hash(secret_key || 0x5C_pad || hash(secret_key || 0x36_pad || seq_num || compress_type || length || fragment))
Compressed message plus the MAC are encrypted using symmetric encryption.
Can’t increase content length by more than 1K bytes. May use padding – for cipher block.
IDEA, DES, 3DES, Fortezza (NSA product).
Final step is to prepend a header with following fields:
o Content type – the higher layer protocol used to process the enclosed fragment o Major version – SSLv3
o Minor version – value of 0
o Compressed length – plaintext fragment length in bytes
Change Cipher Spec Protocol
Figure 2. SSL Record Format
Alert Protocol
Alerts that are always fatal (from SSL specification) : o unexpected_message
o bad_record_mac o handshake_failure o illegal_parameter The remaining alerts :
o close_notify o no_certiicate o bad_certificate
Handshake Protocol
Allows the server and client to authentucate each other.
Allows the server and client to negotiate an encryption and mac algorrithm to protect data in ssl record.
Consists of a series messages exchanged by client and server. Three fields of each message :
o Type (1 byte) o Length (3 bytes) o Content ( ≥ 0 bytes)
Figure 3. Handshake Protocol Handshake Protocol – Phase 1
o Initiate a logical connection and establish security capabilities.
o Client send client_hello message with nonce, session ID, cipher suite (decreasing order of preference), compress method.
o Server returns server_hello message with nonce and selection of proposed parameters.
o Key exchanges: RSA | fixed, ephemeral, or anonymous Diffie-Hellman | Fortezza.
Handshake Protocol – Phase 2 o Most of this is optional.
o Server sends it’s certificate (X.509s) if it needs to be authenticated.
o server_key_exchange message is sent. This is a hash which includes nonces to prevent replay attacks.
o Server can send a certificate_request message to the client.
o Finally the server_done message (no parms) is always sent by the server to indicate the end of hello, authentication and exchange message.
o Server waits for client response. Handshake Protocol – Phase 3
o A certificate message is sent if server requests it. o client_key_exchange message sent to exchange keys.
o certificate_verify message may be sent to verify the client’s ownership of the
private key for the client certificate. Handshake Protocol – Phase 4
o Completes the setting up of a secure connection.
o Client sends a change_cipher_spec message and copies the pending CipherSpec into the current CipherSpec.
o Client sends finished message under the new algorithm, keys and secrets. o In response to these two messages, the server does the same.
o Handshake is complete and the client and server may begin to exchange application layer data.
Cryptographic Computations
Master Secret Creation – two stages: pre-master-secret exchange (RSA or Diffie-hellman) and master secret computation by both sides
Generation of Cryptographic Parameters – the master-secret is a seed value for functions that generate the client/server MAC secret, keys, and IV
16.3 TRANSPORT LAYER SECURITY
TLS is an Internet standard to replace SSLv3. Defined in RFC 2246.
Record format is the same as SSL Record Format. TLS makes use of HMAC (padding bytes are XORed).
Version Number
For the current version of TLS, the major version is 3 and the minor version is 3.
Message Authentication Code
TLS makes use of the HMAC algorithm defined in RFC 2104. The MAC calculation indicated in the following expression:
MAC(MAC_write_secret,seq_num || TLSCompressed.type || TLSCompressed.version || TLSCompressed.length || TLSCompressed.fragment)
Pseudorandom Function
PRF, pseudorandom function, expands small shared secrets into longer blocks of data. Uses two hash functions (RSA & SHA-1) for added security.
Alert Codes
internal_error decrypt_error
The remaining alerts include : user_canceled no_renegotiation
Cipher Suites
Cipher suites are the same except for Fortezza (not supported).
Client Certificate Types
The following certificate types to be requested in a certificate_request message:
o rsa_sign o dss_sign o rsa_fixed_dh o dss_fixed_dh SSLv3 includes
o rsa_ephemeral_dh o dss_ephemeral_dh o fortezza_kea
Certificate_Verify and Finished Messages
certificate_verify message, MD5 and SHA-1 are calculated only over handshake_messages.
The finished message is a hash based on the shared master_secret.
PRF(master_secret,finished_label,MD5(handshake_messages)| |SHA-1(handshake_messages))
Cryptographic Computations
The form of the TLS calculation is different from SSLv3. Defined as :
master_secret = PRF (pre_master_secret, "master secret", ClientHello.random||ServerHello.random)
The calculation of the key block material is defined as :
key_block = PRF (master_secret, "key expansion", SecurityParameters.server_random||
SecurityParameters.client_random)
Padding
16.4 HTTPS
Elements of the communication are encrypted : URL of the requested document. Contents of the document. Contents of browser forms.
Cookies sent from browser to server and from server to browser. Contents of HTTP header.
Connection Initiation
The agent acting as the HTTP client. Also acts as the TLS client.
All HTTP data is sent as TLS application data.
There are three levels of awareness of a connection in HTTPS.
Connection Closure
An HTTP client or server can indicate closure by Connection: close. Connection: close, connection will be closed after this record is delivered. Requires that TLS close the connection with the peer TLS entity on the remote side.
16.5 SECURE SHELL (SSH)
SSH – Secure Shell.
SSH is a protocol for secure remote login and other secure. Network services over an insecure network.
Developed by SSH Communications Security Corp., Finland. Two distributions are available:
o commercial version
o freeware (www.openssh.com) Specified in a set of Internet drafts.
Allows a user to run commands on a machine's command prompt without them being physically present near the machine.
The most visible application of the protocol is for access to shell accounts on Unix-like operating systems, but it can also be used in a similar fashion on Windows.
Transport Layer Protocol
Provides server authentication, confidentiality, and integrity. Services (may provide compression too).
Runs on top of any reliable transport layer (e.g., tcp). SSH security features
o Strong algorithms
– uses well established strong algorithms for encryption, integrity, key exchange, and public key management
o Large key size
o Algorithm negotiation
- kex_algorithms (comma separated list of names) - server_host_key_algorithms - first_kex_packet_follows (boolean)
- random cookie (16 bytes) o Algorithm lists
- The server lists the algorithms it supports.
- The client lists the algorithms that it is willing to accept. - Algorithms are listed in order of preference.
- Selection: first algorithm on the client’s list that is also on the server’s list.
User Authentication Protocol
Provides client-side user authentication. Runs on top of the ssh transport layer protocol.
The “publickey” method
o All implementations must support this method.
o However, most local policies will not require authentication with this method in the near future, as users don’t have public keys.
o Authentication is based on demonstration of the knowledge of the private key (the client signs with the private key).
o The server verifies that
- The public key really belongs to the user specified in the authentication request.
- The signature is correct. o ssh_msg_userauth_request
- User name - Service name - “publickey”
- True (a flag set to true)
- Public key algorithm name (e.g., ssh-dss) - Public key
o The server responds with ssh_msg_userauth_failure if the request
failed or more authentication is needed, or
ssh_msg_userauth_success otherwise. o Using the private key
- Involves expensive computations.
- May require the user to type a password if the private key is stored in encrypted form on the client machine.
o In order to avoid unnecessary processing, the client may check whether authentication using the public key would be acceptable.
- ssh_msg_userauth_request - User name
- Service name - “publickey” - False
- Public key algorithm name - Public key
- If ok then the server responds with o SSH_MSG_USERAUTH_PK_OK
The “password” method
o All implementations should support this method. o This method is likely the most widely used. o SSH_MSG_USERAUTH_REQUEST
- user name - service name - “password”
- FALSE (a flag set to FALSE) - password (plaintext) o The server may respond with
- SSH_MSG_USERAUTH_FAILURE, - SSH_MSG_USERAUTH_SUCCESS, or
- SSH_MSG_USERAUTH_PASSWD_CHANGEREQ o Changing the password
- SSH_MSG_USERAUTH_REQUEST user name
service name “password” TRUE
old password (plaintext) new password (plaintext)
The “hostbased” method
o Authentication is based on the host where the user is coming from. o This method is optional.
o The client sends a signature that has been generated with the private host key of the client.
o The server verifies that.
- The signature is correct. o SSH_MSG_USERAUTH_REQUEST
- user name - service name - “hostbased”
- public key algorithm name
- public key and certificates for client host - client host name
- user name on client host
- signature (computed over the session ID and the data in the request)
Connection Protocol
Multiplexes the secure tunnel provided by the SSH Transport Layer and User Authentication Protocols into several logical channels.
These logical channels can be used for a wide range of purposes : o Secure interactive shell sessions
o TCP port forwarding o Carrying X11 connections Provides
o Interactive login sessions o Remote execution of commands o Forwarded tcp/ip connections o Forwarded x11 connections
All these applications are implemented as “channels”.
All channels are multiplexed into the single encrypted tunnel provided by the SSH Transport Layer Protocol.
Channels are identified by channel numbers at both ends of the connection. Channel numbers for the same channel at the client and server sides may differ.
Channel mechanisms
Opening a channel- SSH_MSG_CHANNEL_OPEN Channel type
Sender channel number Initial window size Maximum packet size
… channel type specific data …
- SSH_MSG_CHANNEL_OPEN_CONFIRMATION
Recipient channel number (sender channel number from the open request)
Sender channel number Initial window size Maximum packet size
… channel type specific data … - SSH_MSG_CHANNEL_OPEN_FAILURE
Recipient channel number (sender channel number from the open request).
Data transfer over a channel
- SSH_MSG_CHANNEL_DATA Recipient channel number Data
- SSH_MSG_CHANNEL_WINDOW_ADJUST Recipient channel number
Bytes to add to the window size
Closing a channel
- SSH_MSG_CHANNEL_EOF
Recipient channel number (sent if the party doesn’t want to send more data).
- SSH_MSG_CHANNEL_CLOSE
Recipient channel (receiving party must respond with an SSH_MSG_CHANNEL_CLOSE, the channel is closed if the party has sent and received the closing message).
Channel type specific requests
- SSH_MSG_CHANNEL_REQUEST Recipient channel number Request type
Want reply flag (true if reply is needed) … request type specific data …
- SSH_MSG_CHANNEL_SUCCESS Recipient channel
- SSH_MSG_CHANNEL_FAILURE Recipient channel
Pertanyaan : Apakah HTTPS benar-benar menjamin security suatu web? Jika HTTPS bisa terserang,
jenis serangan apa yang bisa menembus lapisan keamanannya?BIBLIOGRAPHY
[1] W. Stallings, Cryptography And Network Security Principles And Practice Fifth Edition, New York: Prentice Hall, 2011.
