Transport Level Security

1
Chapter 5

• Transport Level Security

1
2
5.1 Web Security Considerations Web presents
new challenges
? Web is two-way, so servers can be attacked
? Organizations use Web as "store-front"
if compromised, money can be lost and
reputation damaged
? Underlying software is complex,
and may hide many potential security flaws
? Subverting a Web server may provide a
launching pad into the intranet (next slide)
? Users are untrained and unaware of security
risks
2
3
? Subverting a Web server may provide a
launching pad into the intranet
Three-tier system
3
4
Web Security Threats - omit
Web Traffic Security Approaches
Figure 5.1 Relative Location of Security
Facilities in the TCP/IP Protocol Stack
4
5
5.2 Secure Socket Layer and Transport Layer
Security
SSL 2.0 was developed and patented by Netscape
in 1994. TLS is the non-proprietary Internet
standard development (RFC 2246, 1999) TLS 1.0 was
an upgrade of SSL 3.0, so TLS 1.0 is sometimes
referred to as SSL 3.1 Latest standard is TLS
1.2, sometimes referred to as SSL 3.3
I did not find Stallings description of SSL easy
to follow, so I am using the treatment by Stephen
Thomas.
5
6
SSL and TLS Essentials by Stephen
Thomas Chapter 3 SSL Operation 3.1 SSL
roles -----------------------------
SKIM 3.2 SSL Messages -----------------------
SKIM 3.3 Establishing Encrypted
Communications 3.3.1 ClientHello OMIT
compression methods p43 3.3.2
ServerHello 3.3.3 ServerKeyExchange 3.3.4
ServerHelloDone 3.3.5 ClientKeyExchange 3.3.6
ChangeCipherSpec 3.3.7 Finished 3.5 Authentica
ting the Servers Identity 3.5.1
Certificate 3.5.2 ClientKeyExchange omit rest
of chapter
Start here
6
7
3.3 Establishing Encrypted Communications First,
establish TCP connection from client to port 443
on server
Secure channel established proceed to use
7
8
8
9
9
10
10
11
11
12
12
13
13
14
Secure channel established
14
15
3.3.1 ClientHello
Current versions SSL 3.3, TLS 1.2
Cookie Also used as a nonce to repel replay
attacks
15
16
3.3.2 ServerHello
Server decides
Server selects from menu submitted by client
16
17
3.3.3 ServerKeyExchange Server sends its public
key in section 3.5 this will be replaced by
server sending its public-key certificate
3.3.4 ServerHelloDone Server has completed
initial negotiation.
3.3.5 ClientKeyExchange Client generates
premaster secret, and sends it encrypted with
the servers public key. Decrypting the
premaster secret will verify that the server
possesses the corresponding private key. Both
sides can compute necessary keys.
3.3.6 Change Cipher Spec Preliminary negotiations
are complete and client tells server Im going
to begin using the agreed cipher suite.
17
18
3.3.6 ChangeCipherSpec Since the transition to
secured communication is critical, and both sides
have to get it exactly right, the SSL
specification is very precise in describing the
process.
The SSL specification also recognizes that some
of the information (in particular, the key
material) will be different for each direction of
communication. In other words, one set of keys
will secure data the client sends to the server,
and a different set of keys will secure data the
server sends to the client.
For a given system, whether it is a client or a
server, SSL defines a write state and a read
state. The write state defines the security
information for data that the system sends, and
the read state defines the security information
for data that the system receives.
18
19
3.3.6 ChangeCipherSpec






19
20
20
21
3.3.7 Finished Immediately after sending their
ChangeCipherSpec messages, each system sends a
Finished message. The Finished messages allow
both systems to verify that negotiation has been
successful and that security has not been
compromised. Two aspects of the Finished message
contribute to this security.
First the Finished message itself is subject
to the negotiated cipher suite If the receiving
party cannot successfully decrypt and verify the
message, then clearly something has gone awry
with the security negotiation.
The contents of the Finished message also serves
to protect the security of the SSL negotiation.
Each Finished message contains a cryptographic
hash of important information about the
just-finished negotiation This protects against
an attacker who manages to insert fictitious
messages into, or remove legitimate messages
from, the communication.
21
22
3.5 Authenticating the Servers Identity By now
in this course were familiar with the need to
authenticate the servers identity. In the usual
situation in which SSL is deployed (ordering from
Amazon.com) we do not need to authenticate the
client SSL has an option to do so, but we will
skip this.
No surprise we will insist on the server sending
the client an X.509 certificate browser will
automatically check validity, using its library
of CA public keys.
But just receiving a valid certificate is not
enough - It must be the right
certificate! The browser will also check this.
22
23
3.5 Authenticating the Servers Identity
continued
New replaces ServerKeyExchange
23
24
Darth
Sends amazon.com certificate
3.5.2 ClientKeyExchange Encryption of the
pre-master secret with the public key sent in
the Certificate message means that the server
must actually possess the corresponding private
key to decrypt the pre-master secret. Both sides
can compute necessary keys.
24
25
Chapter 4 Message Formats 4.1 Transport
Requirements 4.2 Record Layer 4.3 ChangeCipher
Spec Protocol 4.4 Alert Protocol 4.4.1
Severity Level 4.4.2 Alert Description 4.5
Handshake Protocol 4.5.2 ClientHello 4.5.3
ServerHello 4.5.4 Certificate 4.5.7
ServerHelloDone 4.5.8 ClientKeyExchange-
include RSA only 4.5.10 Finished 4.6 Securin
g Messages 4.6.1 Message Authentication
Code 4.6.2 Encryption 4.6.3 Creating
Cryptographic Parameters3
25
26
443
SSL Record Layer
26
27
Figure 5.2 SSL Protocol Stack
27
28
4.1 Transport Requirements
28
29
4.2 Record Layer
29
30
30
31
Figure 5.3 SSL Record Protocol Operations
31
32
HTTP
32
33
4.3 ChangeCipherSpec Protocol
Record Layer Header
33
34
4.4 Alert Protocol The Alert Protocol signals an
error. Some error messages are cautionary,
others fatal. TLS removes some of the error
categories in SSL and adds some new ones.
34
35
Table 4.3 Alert Protocol Description

35
36
4.5 Handshake Protocol Purposes
1. negotiate cipher suite to be
used ClientHello message (section
4.5.2) ServerHello message (section 4.5.3)
2. authenticate I/D of server Certificate
message (section 4.5.4) ClientKeyExchange
message (4.5.8)
3. generate collection of shared secret
information Premaster secret
(ClientKeyExchange) Master secret (section
4.6.3) Keying material (section 4.6.3) MAC
key Encryption key IV
36
37
Format of Handshake message
Record Layer Header protocol 22 decimal
In practice they are not!
37
38
38
39
39
40
Record Layer Header protocol 22
4.5.2 ClientHello

40
41
There are more of these in SSL TLS removes some
and adds others.
41
42
Secure Socket Layer TLSv1 Record Layer
Handshake Protocol Client Hello Content
Type Handshake (22) Version TLS 1.0
(0x0301) Length 92 Handshake
Protocol Client Hello Handshake
Type Client Hello (1) Length 88
Version TLS 1.0 (0x0301)
Random gmt_unix_time Oct 10,
2008 105418.000000000
random_bytes 751AB9DCEBF3014D799038D27E24E6409C
8397FE6E1A7553... Session ID Length
0 Cipher Suites Length 24
Cipher Suites (12 suites) Cipher
Suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
Cipher Suite TLS_DHE_DSS_WITH_AES_
256_CBC_SHA (0x0038) Cipher
Suite TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite TLS_DHE_RSA_WITH_AES_128_
CBC_SHA (0x0033) Cipher Suite
TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
Cipher Suite TLS_RSA_WITH_RC4_128_MD5
(0x0004) Cipher Suite
TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite TLS_RSA_WITH_AES_128_CBC_SHA
(0x002f) Cipher Suite
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
Cipher Suite TLS_DHE_DSS_WITH_3DES_EDE_C
BC_SHA (0x0013) Cipher Suite
SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA (0xfeff)
Cipher Suite TLS_RSA_WITH_3DES_EDE_CBC_
SHA (0x000a) Compression Methods
Length 1 Compression Methods (1
method) Compression Method null
(0)
Client can handle up to TLS 1.0 (SSL 3.1)
Remarkable range of capabilities in browser!
42
43
Client to server
43
44
44
45
4.5.3 ServerHello
45
46
Server to client
Secure Socket Layer TLSv1 Record Layer
Handshake Protocol Server Hello Content
Type Handshake (22) Version TLS 1.0
(0x0301) Length 74 Handshake
Protocol Server Hello Handshake
Type Server Hello (2) Length 70
Version TLS 1.0 (0x0301)
Random gmt_unix_time Oct 10,
2008 110013.000000000
random_bytes C7B2A2F58454A2C2A0DE667781E277354
4C86C8FF724069E... Session ID Length
32 Session ID 77987B601B5544C111C3FCB
1DF96F7A8970D1EFD39630F3F... Cipher
Suite TLS_RSA_WITH_RC4_128_MD5 (0x0004)
Compression Method null (0)
46
47
Server to client
47
48
4.5.4 Certificate
48
49
Server to client
Secure Socket Layer TLSv1 Record Layer
Handshake Protocol Certificate Content
Type Handshake (22) Version TLS 1.0
(0x0301) Length 2468 Handshake
Protocol Certificate Handshake Type
Certificate (11) Length 2464
Certificates Length 2461
Certificates (2461 bytes)
Certificate Length 1271 Certificate
(id-at-commonNamewww.amazon.com,
Certificate Length 1184
Certificate (id-at-commonNameVeriSign Class 3
Secure Server CA Secure Socket Layer TLSv1
Record Layer Handshake Protocol Server Hello
Done Content Type Handshake (22)
Version TLS 1.0 (0x0301) Length 4
Handshake Protocol Server Hello Done
Handshake Type Server Hello Done (14)
Length 0
49
50
CS 336/536 Lab 3 SSL/TLS Certificate message
from Amazon.com contains a chain of public key
certificates
Certificate 1 Issued to www.amazon.com Issuer
VeriSign Class 3 Secure Server CA
Certificate 2 Issued to VeriSign Class 3
Secure Server CA Issuer VeriSign Class 3
Public Primary Certification
Authority
51
4.5.7 ServerHelloDone
51
52
Server to client
The ServerHelloDone message is tacked on the end
of the Certificate message.
52
53
Both sides know algorithms, client generates
pre-master secret and can use it to compute all
necessary keys (session key, IV, MAC key).
Client encrypts pre-master secret with server
public key and sends.
Server has received encrypted pre-master secret,
decrypts with its private key and uses pre-master
secret to compute all necessary keys. Both sides
know all keys.
53
54
4.5.8 ClientKeyExchange
Chronologically, ChangeCipherSpec comes here,
but its not part of the Handshake Protocol.
54
55
4.5.10 Finished
55
56
The 3 messages from the client
Secure Socket Layer TLSv1 Record Layer
Handshake Protocol Client Key Exchange
Content Type Handshake (22) Version TLS
1.0 (0x0301) Length 134
Handshake Protocol Client Key Exchange
Handshake Type Client Key Exchange (16)
Length 130 TLSv1 Record Layer Change
Cipher Spec Protocol Change Cipher Spec
Content Type Change Cipher Spec (20)
Version TLS 1.0 (0x0301) Length 1
Change Cipher Spec Message TLSv1 Record
Layer Handshake Protocol Encrypted Handshake
Message Content Type Handshake (22)
Version TLS 1.0 (0x0301) Length 32
Handshake Protocol Encrypted Handshake
Message
56
57
Client to server
58

58
59
Server to client
60
4.6.3 Creating Cryptographic Parameters Where
did the various keys come from?
Calculation of the Master Secret
48 bytes
60
61
We need this secret information
61
62
Creation of the secret information (key material)
TLS does this somewhat differently
62
63
63
64
Review repeat of a previous slide
Both sides know algorithms, client generates
pre-master secret and can use it to compute all
necessary keys (session key, IV, MAC key).
Client encrypts pre-master secret with server
public key and sends.
Server receives encrypted pre-master secret,
decrypts with its private key and uses pre-master
secret to compute all necessary keys. Then both
sides have computed identical keys.
We need to have an agreed test message.
64
65
Return to 4.5.10 Finished Finished message
carries the agreed test message, MD5 and SHA
hashes of the previous handshake messages.
Heres the SHA
Inner and outer hash remind us of HMAC
TLS uses a slightly different hash calculation.
Keyed, not signed
65
66
4.5.10 Finished
66
67
Handshake finally over! Ready to do useful work.
4.6 Securing Messages (Application)
Figure 4-31 shows use of SHA as hash
67
68
Application protocol data (HTTP)
68
69
The inner and outer hash used here in SSL reminds
us of HMAC (RFC 2104). This is slightly
different, but TLS uses HMAC exactly.
69
70
5.4 Transport Layer Security Protocol We have
been noting the (small) differences from SSL as
we went along.
Interoperability of TLS 3.1 with SSL 3.0 A
client with capability for both should send the
version 3.0 ClientHello message if the server
understands TLS 3.1 it will reply with the
protocol version set to 3.1 and the rest of the
exchange will be under TLS.
Similarly, if SSL version 2.0 is still a
possibility, the client should send the version
2.0 ClientHello message.
70
71
End of SSL/TLS study
71
72
Stallings Section 5.5 Secure Shell (SSH)
Again, I did not find Stallings description easy
to follow, so I am using the my own treatment
(handout).
72
73
Secure Shell (SSH) 1. Remote Users Both Telnet
and FTP send passwords across the
Internet in the clear. SSH and
SFTP are secure replacements for Telnet and
FTP that protect passwords, and can even avoid
use of them. SSH has many similarities with
SSL, also some differences (next
slides)
73
74
2. Environments of SSH and SSL
Authentication of human user unnecessary.
User may not always use same client machine.
Authentication of human user vital.
74
75
3. Preview of SSH operation
? limited authentication of server machine
? no authentication of client machine
? server will unquestioningly participate in
establishing secure channel to
any client machine
? careful human user authentication over secure
channel
? several similarities with SSL handshaking (2
slides on)
75
76

SSH Transport Layer roughly equivalent to SSL/TLS
Record Layer
76
77
4. Transport Layer Protocol
SSH TCP connection to port 22 established.
SSL TCP connection to port 443 established.
At this point both sides know algorithms
77
78
Both sides know algorithms
At this point both sides compute keys
78
79
Both sides know algorithms
Both sides compute keys
Service User Authentication Protocol
79
80
SSH Protocol SSH Version 2 Packet
Length 788 Padding Length 8 Key
Exchange Msg code Key Exchange Init
(20) Algorithms
Cookie 8B21EDD188AFED7EC7FC499F65CD84C7
kex_algorithms length 126
kex_algorithms string diffie-hellman-group-excha
nge-sha256, diffie-hellman-group-exchange-sh
a1, diffie-hellman-group14-sha1,
diffie-hellman-group1-sha1
server_host_key_algorithms length 15
server_host_key_algorithms string
ssh-rsa,ssh-dss
encryption_algorithms_client_to_server length
157 encryption_algorithms_client_t
o_server string aes128-cbc,3des-cbc,blowfish-c
bc, cast128-cbc, arcfour128,arcfour256,arcfour,a
es192-cbc,aes256-cbc, rijndael-cbc_at_lysator.liu.
se, aes128-ctr,aes192-ctr, aes256-ctr
encryption_algorithms_server_to_client
length 157 encryption_algorithms_
server_to_client string aes128-cbc,3des-cbc,bl
owfish-cbc,cast128-cbc, arcfour128,arcfour256,ar
cfour,aes192-cbc,aes256-cbc, rijndael-cbc_at_lysato
r.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
mac_algorithms_client_to_server length
105 mac_algorithms_client_to_serve
r string hmac-md5, hmac-sha1,umac-64_at_openssh.co
m,hmac-ripemd160, hmac-ripemd160_at_openssh.com,hma
c-sha1-96,hmac-md5-96
mac_algorithms_server_to_client length 105
mac_algorithms_server_to_client string
hmac-md5, hmac-sha1,umac-64_at_openssh.com,hmac-rip
emd160, hmac-ripemd160_at_openssh.com,hmac-sha1-96,
hmac-md5-96 compression_algorithms
_client_to_server length 26
compression_algorithms_client_to_server string
none,zlib_at_openssh.com,zlib
compression_algorithms_server_to_client length
26 compression_algorithms_server_to
_client string none,zlib_at_openssh.com,zlib
languages_client_to_server length
0 languages_server_to_client
length 0 Payload 0000000000
Padding String
Cookie
Menu of cipher suites
80
81
In the menus, algorithms are listed in order of
preference. Those chosen are the
first ones on the clients list that are also on
the servers list.
In our lab the algorithms chosen are
Key exchange diffie-hellman-group-exchange-sha256
Server host key ssh-rsa
Symmetric encryption aes128-cbc
MAC hmac-md5
Compression none
81
82
Recall Diffie-Hellman
Global parameters q, a
Key exchange method chosen diffie-hellman-group-e
xchange-sha256
DH_GEX_REQUEST client specifies a range of
values for the modulus, q, and asks the
server to choose
DH_GEX_GROUP server responds with q, a to be
used.
DH_GEX_INIT client chooses its DH private key,
computes its public key
and sends it to server
DH_GEX_REPLY server sends its DH public key,
servers host public signing key and
signed hash of previous handshake messages.
82
83
83
84
84
85
85
86
SSH Protocol SSH Version 2 Packet
Length 700 Padding Length 10
Key Exchange Msg code Diffie-Hellman
GEX Reply (33) Payload
00000115000000077373682D727361000000012300000101..
. Padding String MAC
String
Much more on next slide!
86
87
87
88
As seen in the previous slide our DH_GEX_REPLY
message contains
? Servers DH public key
? Servers host RSA public key
? SHA-256 hash H of the previous handshake
messages, signed by the server with its private
host signing key.
H serves as the session identifier
88
89
To authenticate the server, the client
? checks servers public key against key in file
known_hosts (if this is the first contact,
user is given option to risk proceeding)
? checks the servers signature of the hash of
previous handshake messages agreement
proves that the server has the RSA private
key corresponding to its public host key
This gives limited authentication of the server.
Both participants compute the shared DH secret
and combine it with hashes of the previous
handshake messages to compute the various
necessary keys
89
90
90
91
At this point the secure tunnel between the
client host machine and the server machine has
been established. Note again that there has been
no authentication of the client host machine, and
only limited authentication of the server host
machine no X.509 certificate has been provided
and the client has been given the option of
proceeding on faith during first contact with a
particular server.
The above handshaking would be the same no matter
what application the user had invoked SSH to
execute in our lab you will see ? remote
terminal (SSH itself) ? file copy (SFTP) ? port
forwarding
The client now sends the SERVICE_REQUEST message,
specifying that it wishes to proceed to the User
Authentication Protocol
The server responds with SERVICE_ACCEPT. Of
course, these messages are authenticated and
encrypted, so are opaque to eavesdroppers (such
as you, using Wireshark in the lab!)
91
92
92
93
There will be no authentication of the client
host machine proceed to authenticate the human
user.
93
94
Everything so far in SSH has been part of the
Transport Layer (analogous to SSL/TLS Record
Layer)
The SSH user authentication protocol runs over
the transport layer, making use of the secure
tunnel that the transport layer has constructed.
5. SSH User Authentication Three methods
? trusted hosts server lets client host
machine authenticate user (not an
appealing option)
? user passwords use for traveling salesperson
guesting on different machines
? public-key authentication of user
94
95
Public-key Authentication of User
In advance, a copy of the users public key is
placed in the users home directory on the server
(slight problem how?)
To authenticate the user, the server generates a
challenge, encrypts it with users public key and
sends it to client client decrypts the challenge
with users private key, hashes it and returns
hash to server, which checks the hash. Agreement
proves that client has users private key.
95
96
The public-key method of user authentication is
clearly superior to the password method. If you
somehow discover another persons password, the
door is wide open to you. But even if you
somehow discover another persons passphrase, it
is useless without the private key conversely if
you accidentally have access to somebodys
(encrypted) private key, it cannot be activated
without the passphrase.
The SSH documentation states that the server
automatically tries the authentication methods in
the order ?trusted-hosts ? user
public-key ? user password.
Thus, if public-key authentication fails, the
server should drop back and invite password
authentication. You should be able to see this
in the lab.
96
97
6. SSH Connection Protocol We have been engaged
in necessary preliminaries establishment of the
secure tunnel and authentication of the user. Now
its time to move to useful work!
The SSH Connection Protocol is used to set up any
number of logical channels through the tunnel.
There are various types of channel, the most
obvious being one that carries a remote terminal
stream.
Other types support port forwarding.
97
98

98
99
7. Port Forwarding Telnet passes textual
information between client and server. Although
we introduced SSH as a secure replacement for
telnet, once we have the secure tunnel
established between SSH client and server, we can
use it to carry any kind of data.
That is, SSH can be used to carry another
applications bidirectional data stream. SSH
intercepts the service request and carries it and
the response over the secure channel. The other
application must be configured to use the SSH
client (or server) as a proxy.
In lab session 4 well see this for Web browser
? Web server traffic.
99
100

Local Forwarding is where the two clients are
running on the same machine and the two servers
on another machine. Here, the browser has been
configured to use localhost2001 as proxy the
SSH forwards this port, via port 22 on the
server, to port 80 on the server.
100
101
ssh -L2001localhost80 ltIP address
of X2gt
IP datagrams arriving at port X12001 are
forwarded to port X280
The full range of HTTP traffic (graphical, etc.)
will be carried across the channel a casual user
will not be aware that the direct connection was
not used.
101
102
Example of SSH Remote Port Forwarding
ssh R2001localhost110 ltIP address of
usergt
Traffic between POP3 client and POP3 server
travels through the secure port forwarding channel
102
103
This figure covers both local and remote port
forwarding.
Local SSH entity on left is SSH client, on
right is SSH server.
Remote SSH entity on the left is server, on
right is client
103
104
End of SSH material
End of Stallings Chapter 5
104