1. Lecture 6: Web security: SSL
Anish Arora
CSE 5473
Introduction to Network Security

2. Web security needs
Web now widely used by business, government, individuals, but Internet & Web are vulnerable
Threats:
Revealing private information on server
Interception of client information (client card fraud and abuse)
Content hijacking (mimics of well known sites) and defacement
Hostile content (recursive window pop ups)
Cookies reveal where users have been, how many times ads have been displayed (user profiling), allow impersonation
Web server attacks:
Buffer overflow (longer than expected parameters)
Dot dot URL traversal allows file system access
Allowing attacker to execute programs (editors, xterm), root access
Denial of service

3. Web security needs CGI scripts Requirements include:
clients can invoke services via HTML macros run on server side
scripts allow encoding of commands
server runs at root (port 80)
Requirements include:
integrity
confidentiality
dealing with denial of service
authentication

4. Web security Need added security mechanisms
authentication can be based on message digest
cookies can help
access control via network addresses
multi-layered: SHTTP (just for http) + SSL (generic for TCP) + IPSec (host to host)

5. SSL (Secure Socket Layer)
transport layer security service, yields secure channel
secure byte stream
optional public-key server authentication
optional client authentication
originally developed by Netscape
hash: combined MD5 & SHA
encryption: Diffie Helman, RSA & DES, RC4
version 3 designed with public input; subsequently became Internet standard TLS (Transport Layer Security)
uses TCP to provide a reliable end-to-end service
useful for HTTP, NNTP, telnet, telephony signaling
SSL has two layers of protocols
SSL probably most widely used Web security mechanism. Its implemented at the Transport layer; cf IPSec at Network layer; or various Application layer mechanisms eg. S/MIME & SET (later).

6. SSL architecture
Stallings Fig 17-2.

7. SSL architecture SSL session SSL connection
an association between client & server
created by the Handshake Protocol
define a set of cryptographic parameters
may be shared by multiple SSL connections
SSL connection
a transient, peer-to-peer, communications link
associated with 1 SSL session

8. SSL record protocol confidentiality message integrity
using symmetric encryption with a shared secret key defined by Handshake Protocol
 stateful protocol
IDEA, RC2-40, DES-40, DES, 3DES, Fortezza, RC4-40, RC4-128
message is compressed before encryption
message integrity
using a MAC with shared secret key
similar to HMAC but with different padding
SSL Record Protocol defines these two services for SSL connections.

9. SSL record protocol operation

10. SSL record format

11. Crypto for Record Protocol
Use IV (one of the parts of the keys exchanged) for seed in CBC encryption mode
IV is used for first message
Last ciphertext of previous message is used as IV for new message
HMAC is appended to M; padding is used
Using last cipertext is vulnerable to revealing some block in previous message by controlling the first block of the new message!
Javascript attacks are opened up with this vulnerability

12. SSL record protocol payload

13. SSL change cipher specification protocol
one of 3 SSL specific protocols which use the SSL record protocol
a single message
causes pending state to become current
hence updating the cipher suite in use

14. SSL alert protocol conveys SSL-related alerts to peer entity severity
warning or fatal
specific alert
unexpected message, bad record mac, decompression failure, handshake failure, illegal parameter
close notify, no certificate, bad certificate, unsupported certificate, certificate revoked, certificate expired, certificate unknown
compressed & encrypted like all SSL data

15. SSL handshake protocol
allows server & client to:
authenticate each other
to negotiate encryption & MAC algorithms
to negotiate cryptographic keys to be used
comprises a series of messages in phases
establish Security Capabilities
Server Authentication and Key Exchange
Client Authentication and Key Exchange
finish

16. What’s wrong with this handshake protocols?
Can we talk?, cipher list
cipher, certificate (Bob)
{K}Bob
Data protected with key K
Bob
Alice
Chosen cipher can be downgraded by active adversary
Man in the middle can propose key forcing Bob to reveal data, but not forcing Alice to reveal data since her proposed key is not broken

17. Simplified SSL protocol
Can we talk?, cipher list, NA
cipher, certificate (Bob), NB
{S}Bob, E(h(msgs,CLNT,K),K)
h(msgs,SRVR,K)
Data protected with key K
Bob
Alice
S is pre-master secret, derived from random with PKCS padding and including client version number
Key K = h(S,NA,NB)
K has three parts: (i) for encryption, (ii) for IV, (iii) for hash
msgs = all previous messages; CLNT and SRVR are constant
Nonces also help to prevent replays
Authentication that both are using the same K is now achieved
Authentication of cipher happens since all previous messages are considered
However trust in certificate is still assumed!

18. Certificate Verification
Look at a browser, the certificate associated with a secure server, and its certificate chain
Browser has embedded in it some certificate along this chain
Basis for checking that certificate received in the second step is valid

19. SSL handshake protocol
Stallings Fig Optional verification of the client also
Colored messages are optional
Phase 1-3 messages are plaintext

20. SSL handshake protocol
Phase 1
CS: Client hello (to establish security enhancement capabilities)
random challenge, which algorithms are supported
server chooses encryption, compression algorithms
S C: Server hello:
acknowledges algorithms
established random connection id
Phase 2
S C: Server certificate
server returns a X.509 certificate chain
optionally asks for client certificate

21. SSL handshake protocol
Phase 3
Client key exchange
client verifies certificate chain against that in web browser
if not in list of CAs, may trust the new certificate
client generates 48 byte pre-secret
CS: session key exchange:
pre-secret encrypted w/ server’s public key in certificate
both sides can now generate master secret
session key now generated from master secret
client hello random provides “salt”

22. SSL handshake protocol
SC: optionally ask for request certificate (in phase 2)
send challenge phrase, encrypted with server write key
(in phase 3) client responds with encrypted
MD5(server challenge and certificate), client certificate
server verifies certificate and hash
certificate used to associate with username&pwd, for future logins
Phase 4:
Finished message exchange, encrypted with session key
verifies success of key exchange and authentication processes
Phase 5
Now encrypted application data exchanged between C, S

23. TLS (Transport Layer Security)
IETF standard RFC 2246 similar to SSLv3
with minor differences
in record format version number
uses HMAC for MAC
a pseudo-random function expands secrets
has additional alert codes
some changes in supported ciphers
changes in certificate negotiations
changes in use of padding