KEAMANAN INFORMASI DAN JARINGAN NETWOR

PART 5: NETWORK AND
INTERNET SECURITY
CHAPTER 16
TRANSPORT-LEVEL SECURITY

MADIS SARALITA – 5112100038
Keamanan Informasi dan Jaringan (C)

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
 Modification of user
data
 Trojan horse
browser
 Modification of
memory
 Modification of
message traffic in
transit
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
Denial of
 Killing of user
Service
threads
 Flooding machine
with bogus requests
 Filling up disk or
memory
 Isolating machine by
DNS attacks
Authentication  Impersonation of
legistimate users
 Data forger
Integrity

Consequences
 Loss of information

 Compromise of
machine
 Vulnerabilty to all
other threts

Countermeasures
 Cryptographic
checksums

 Loss of information
 Loss of privacy

 Encryption, web
proxies

 Disruptive
 Annoying
 Prevent user from
getting work done

 Difficult to prevent

 Misrepresentation
of user
 Belief that false
information is valid

 Cryptographic
techniques

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)

Transparent
to end users

Above TCP. Embedded
in packages

Application
Specific - 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.



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).

Message

Optional

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.









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
o unsupported_certificate
o certificate_revoked
o certificate_expired
o certificate_unknown

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 Client now verifies the certificate if requested and checks parameters.

A certificate message is sent if server requests it.
client_key_exchange message sent to exchange keys.
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.
o
o
o



Cryptographic Computations



Master Secret Creation – two stages: pre-master-secret exchange (RSA or Diffiehellman) 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
Similar alert codes to SSL with a few new additions; of these, the following are always fatal.
 record_overflow
 unknown_ca
 access_denied
 decode_error
 protocol_version
 insufficient_security
 unsupported_extension




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




Added prior to encryption of user data is the minimum amount required.
Can be any amount that results a multiple of the cipher’s block length.
A variable padding length is used to frustrate attacks.

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
– requires encryption to be used with at least 128 bit keys.
– supports larger keys too.

o

Algorithm negotiation
– encryption, integrity, key exchange, and public key algorithms are
negotiated.
– it is easy to switch to some other algorithm without modifying the base
protocol.

Algorithm negotiation
o

o

SSH_MSG_KEXINIT
- kex_algorithms (comma separated list of names)
- server_host_key_algorithms
- encryption_algorithms_client_to_server
- encryption_algorithms_server_to_client
- mac_algorithms_client_to_server
- mac_algorithms_server_to_client
- compression_algorithms_client_to_server
- compression_algorithms_server_to_client
- first_kex_packet_follows (boolean)
- random cookie (16 bytes)
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
o
o
o

o

All implementations must support this method.
However, most local policies will not require authentication with this method
in the near future, as users don’t have public keys.
Authentication is based on demonstration of the knowledge of the private
key (the client signs with the private key).
The server verifies that
- The public key really belongs to the user specified in the
authentication request.
- The signature is correct.
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
- Signature (computed over the session id and the data in the
- Request)

o

o

o

o

The server responds with ssh_msg_userauth_failure if the request
failed
or
more
authentication
is
needed,
or
ssh_msg_userauth_success otherwise.
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.
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
SSH_MSG_USERAUTH_PK_OK

The “password” method
o
o
o

o

o

All implementations should support this method.
This method is likely the most widely used.
SSH_MSG_USERAUTH_REQUEST
- user name
- service name
- “password”
- FALSE (a flag set to FALSE)
- password (plaintext)
The server may respond with
- SSH_MSG_USERAUTH_FAILURE,
- SSH_MSG_USERAUTH_SUCCESS, or
- SSH_MSG_USERAUTH_PASSWD_CHANGEREQ
Changing the password
- SSH_MSG_USERAUTH_REQUEST
 user name
 service name
 “password”
 TRUE
 old password (plaintext)
 new password (plaintext)

The “hostbased” method
o
o
o
o

Authentication is based on the host where the user is coming from.
This method is optional.
The client sends a signature that has been generated with the private host
key of the client.
The server verifies that.
- The public key really belongs to the host specified in the
authentication request.

o

- The signature is correct.
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).
 Reason code and additional textual information.

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.
[2] [Online]. Available: http://en.wikipedia.org/wiki/Secure_Shell. [Accessed 03 May 2015].