SSL & TLS Architecture short
Download as PPT, PDF53 likes43,197 views
The document discusses SSL and TLS architecture, highlighting their importance for web security amidst various threats such as integrity and confidentiality issues. It covers the ITU-T recommendations and x.800 series that outline a comprehensive security framework, addressing different layers of security including infrastructure, services, and applications. Key mechanisms like the handshake protocol, key exchange, and use of X.509 certificates are explained to illustrate how these protocols ensure secure end-to-end communication over the internet.
![TLS: Change Cipher Spec,
Finished
Client Server
[ChangeCipherSpec]
Finished
40
[ChangeCipherSpec]
Finished
Application Data Application Data](https://image.slidesharecdn.com/ssltlsarchitectureshort-120507194057-phpapp01/85/SSL-TLS-Architecture-short-40-320.jpg)
![TLS: Using a Session
Client Server
ClientHello (Session #)
ServerHello (Session #)
42
[ChangeCipherSpec]
Finished
[ChangeCipherSpec]
Finished
Application Data Application Data](https://image.slidesharecdn.com/ssltlsarchitectureshort-120507194057-phpapp01/85/SSL-TLS-Architecture-short-42-320.jpg)
SSL & TLS Architecture short
- 1. SSL & TLS Architecture By Avirot M. Liangsiri Senior Technical Specialist Professional Computer Co., Ltd. 1
- 2. Web Security Essential • Web now widely used by business, government, individuals for multiple application • But Internet & Web are vulnerable • Have a variety of threats • integrity • confidentiality • denial of service • authentication • Need added security mechanisms 2
- 3. Security Architecture • ITU-T Recommendation X.805 Security architecture for systems providing end‑to‑end communications had been developed by ITU-T SG 17 (ITU-T Lead Study Group on Telecommunication Security) and was published in October 2003. • The group has developed a set of the well-recognized Recommendations on security. Among them are X.800 Series of Recommendations on security and X.509 v3 - Public-key and Attribute Certificate Frameworks. 3
- 4. ITU-T X.800 Threat Model (simplified) X 1 - Destruction (an attack on availability): – Destruction of information and/or network resources 2 - Corruption (an attack on integrity): – Unauthorized tampering with an asset 3 - Removal (an attack on availability): – Theft, removal or loss of information and/or other resources 4 - Disclosure (an attack on confidentiality): – Unauthorized access to an asset 5 - Interruption (an attack on availability): – Interruption of services. Network becomes unavailable or unusable X 4 4
- 5. ITU-T X.800 Eight Security Dimensions Address the Breadth of Network • Limit & control access to Vulnerabilities network elements, services & Access Control • Provide Proof of Identity applications • Examples: shared secret, • Examples: password, ACL, firewall Authentication PKI, digital signature, digital certificate • Prevent ability to deny that an activity on the network Non-repudiation • Ensure confidentiality of data occurred • Example: encryption • Examples: system logs, Data Confidentiality digital signatures • Ensure data is received as • Ensure information only flows Communication Security sent or retrieved as stored from source to destination • Examples: MD5, digital • Examples: VPN, MPLS, signature, anti-virus software L2TP Data Integrity Availability • Ensure network elements, • Ensure identification and services and application network use is kept private available to legitimate users Privacy • Examples: NAT, encryption 5 • Examples: IDS/IPS, network redundancy, BC/DR Eight Security Dimensions applied to each Security Perspective (layer and 5
- 6. ITU-T X.800 Three Security Layers Applications Security 3 - Applications Security Layer: THREATS • Network-based applications accessed by Services Security Destruction end-users Corruption VULNERABILITIES Removal • Examples: Disclosure – Web browsing Vulnerabilities Can Exist Interruption In Each Layer Infrastructure Security – Directory assistance ATTACKS – Email – E-commerce 1 - Infrastructure Security Layer: 2 - Services Security Layer: • Fundamental building blocks of networks • Services Provided to End-Users services and applications • Examples: • Examples: – Frame Relay, ATM, IP – Individual routers, switches, servers – Cellular, Wi-Fi, – Point-to-point WAN links – VoIP, QoS, IM, Location services – Ethernet links – Toll free call services • Each Security Layer has unique vulnerabilities, threats 6 • Infrastructure security enables services security enables applications security 6
- 7. ITU-T X.800 Applying Security Planes to Network Protocols End User Security Plane Activities Protocols •End-user data transfer • HTTP, RTP, POP, IMAP •End-user – application • TCP, UDP, FTP interactions • IPsec, TLS Control/Signaling Security Plane Activities Protocols •Update of routing/switching tables • BGP, OSPF, IS-IS, RIP, •Service initiation, control, and PIM teardown • SIP, RSVP, H.323, SS7. •Application control • IKE, ICMP • PKI, DNS, DHCP, SMTP Management Security Plane Activities Protocols •Operations •SNMP •Administration •Telnet 7 •Management •FTP •Provisioning •HTTP 7
- 8. SSL (Secure Socket Layer) • transport layer security service • originally developed by Netscape • version 3 designed with public input • subsequently became Internet standard known as TLS (Transport Layer Security) • uses TCP to provide a reliable end-to-end service • SSL has two layers of protocols
- 9. Where SSL Fits HTTP SMTP POP3 HTTPS SSMTP SPOP3 80 25 110 443 465 995 Secure Sockets Layer Transport Network Link
- 10. Uses Public Key Scheme • Each client-server pair uses • 2 public keys • one for client (browser) • created when browser is installed on client machine • one for server (http server) • created when server is installed on server hardware • 2 private keys • one for client browser • one for server (http server)
- 11. SSL Architecture
- 12. SSL Architecture • SSL session • an association between client & server • created by the Handshake Protocol • define a set of cryptographic parameters • may be shared by multiple SSL connections (by using same session symmetric key) • SSL connection • a transient, peer-to-peer, communications link • associated with 1 SSL session
- 13. SSL Record Protocol • confidentiality • using symmetric encryption with a shared secret key defined by Handshake Protocol • IDEA, RC2-40, DES-40, DES, 3DES, Fortezza, RC4-40, RC4-128 • message is compressed before encryption • message integrity • using a MAC (Message Authentication Code) created using a shared secret key and a short message
- 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
- 17. Changes from SSL 3.0 to TLS • Fortezza removed • Additional Alerts added 17 • Modification to hash calculations • Protocol version 3.1 in ClientHello, ServerHello
- 18. 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
- 19. TLS:Key Exchange • Need secure method to exchange secret key • Use public key encryption for this • “key pair” is used - either one can encrypt and 19 then the other can decrypt • slower than conventional cryptography • share one key, keep the other private • Choices are RSA or Diffie-Hellman
- 20. TLS: Integrity • Compute fixed-length Message Authentication Code (MAC) • Includes hash of message 20 • Includes a shared secret • Include sequence number • Transmit MAC with message
- 21. TLS: Integrity • Receiver creates new MAC • should match transmitted MAC • TLS allows MD5, SHA-1 21 A B Message Message’ MAC MAC MAC’ =?
- 22. TLS: Authentication • Verify identities of participants • Client authentication is optional • Certificate is used to associate identity with 22 public key and other attributes A B Certificate Certificate
- 23. TLS: Overview • Establish a session • Agree on algorithms • Share secrets 23 • Perform authentication • Transfer application data • Ensure privacy and integrity
- 24. TLS: Architecture • TLS defines Record Protocol to transfer application and TLS information • A session is established using a Handshake 24 Protocol Handshake Change Alert Protocol Cipher Spec Protocol TLS Record Protocol
- 25. TLS: Record Protocol 25
- 26. TLS: Handshake • Negotiate Cipher-Suite Algorithms • Symmetric cipher to use • Key exchange method 26 • Message digest function • Establish and share master secret • Optionally authenticate server and/or client
- 27. Handshake Phases • Hello messages • Certificate and Key Exchange messages • Change CipherSpec and Finished messages 27
- 28. TLS: Hello • Client “Hello” - initiates session • Propose protocol version • Propose cipher suite 28 • Server chooses protocol and suite • Client may request use of cached session • Server chooses whether to honor request
- 29. TLS: Key Exchange • Server sends certificate containing public key (RSA) or Diffie-Hellman parameters • Client sends encrypted “pre-master” secret to 29 server using Client Key Exchange message • Master secret calculated • Use random values passed in Client and Server Hello messages
- 30. Public Key Certificates • X.509 Certificate associates public key with identity • Certification Authority (CA) creates certificate 30 • Adheres to policies and verifies identity • Signs certificate • User of Certificate must ensure it is valid
- 31. Validating a Certificate • Must recognize accepted CA in certificate chain • One CA may issue certificate for another CA • Must verify that certificate has not been revoked 31 • CA publishes Certificate Revocation List (CRL)
- 32. X.509: Certificate Content • Version • Subject X.500 name • Serial Number • Subject Public Key • Signature Algorithm Identifier • Algorithm • Object Identifier (OID) • Value 32 • e.g. id-dsa: {iso(1) member- body(2) us(840) x9-57 (10040) • Issuer Unique Id (Version 2 ,3) x9algorithm(4) 1} • Subject Unique Id (Version • Issuer (CA) X.500 name 2,3) • Validity Period (Start,End) • Extensions (version 3) • optional • CA digital Signature
- 33. Subject Names • X.500 Distinguished Name (DN) • Associated with node in hierarchical directory (X.500) 33 • Each node has Relative Distinguished Name (RDN) • Path for parent node • Unique set of attribute/value pairs for this node
- 34. Example Subject Name • Country at Highest Level (e.g. US) • Organization typically at next level (e.g. CertCo) • Individual below (e.g. Common Name 34 “Elizabeth” with Id = 1) DN = { • C=US; • O=CertCo; • CN=Elizabeth, ID=1}
- 35. Version 3 Certificates • Version 3 X.509 Certificates support alternative name formats as extensions • X.500 names 35 • Internet domain names • e-mail addresses • URLs • Certificate may include more than one name
- 36. Certificate Signature • RSA Signature • Create hash of certificate • Encrypt using CA’s private key 36 • Signature verification • Decrypt using CA’s public key • Verify hash
- 37. TLS: ServerKeyExchange Client Server ClientHello ServerHello 37 Certificate ServerKeyExchange
- 38. TLS: Certificate Request Client Server ClientHello ServerHello 38 Certificate ServerKeyExchange CertificateRequest
- 39. TLS: Client Certificate Client Server ClientHello ServerHello 39 Certificate ServerKeyExchange CertificateRequest ClientCertificate ClientKeyExchange
- 40. TLS: Change Cipher Spec, Finished Client Server [ChangeCipherSpec] Finished 40 [ChangeCipherSpec] Finished Application Data Application Data
- 41. TLS: Change Cipher Spec/Finished • Change Cipher Spec • Announce switch to negotiated algorithms and values 41 • Finished • Send copy of handshake using new session • Permits validation of handshake
- 42. TLS: Using a Session Client Server ClientHello (Session #) ServerHello (Session #) 42 [ChangeCipherSpec] Finished [ChangeCipherSpec] Finished Application Data Application Data
- 43. TLS: HTTP Application • HTTP most common TLS application • https:// • Requires TLS-capable web server 43 • Requires TLS-capable web browser • Netscape Navigator • Internet Explorer • Cryptozilla • Netscape Mozilla sources with SSLeay
- 44. X.509 Certificate Issues • Certificate Administration is complex • Hierarchy of Certification Authorities • Mechanisms for requesting, issuing, revoking 44 certificates • X.500 names are complicated • Description formats are cumbersome (ASN.1)
- 45. X.509 Alternative: SDSI • SDSI: Simple Distributed Security Infrastructure (Rivest, Lampson) • Merging with IETF SPKI: Simple Public-Key 45 Infrastructure in SDSI 2.0 • Eliminate X.500 names - use DNS and text • Everyone is their own CA • Instead of ASN.1 use “S-expressions” and simple syntax • Name and Authorization certificates
- 46. TLS “Alternatives” • S-HTTP: secure HTTP protocol, shttp:// • IPSec: secure IP • SET: Secure Electronic Transaction 46 • Protocol and infrastructure for bank card payments • SASL: Simple Authentication and Security Layer (RFC 2222)
- 47. Summary • SSL/TLS addresses the need for security in Internet communications • Privacy - conventional encryption 47 • Integrity - Message Authentication Codes • Authentication - X.509 certificates • SSL in use today with web browsers and servers • Equivalent to TLS
Editor's Notes
- #5: ITU-T X.800 Threat Model Confidential Issue Availability Issue Integrity Issue
- #9: 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).
- #12: Stallings Fig 17-2.
- #14: SSL Record Protocol defines these two services for SSL connections.
- #17: Stallings Fig 17-6.
- #18: Hash includes Finished and CertificateVerify messages following client cert types removed: rsa_ephemeral_dh dss_ephemeral_dh fortezza_dms SSL 2 -> SSL 3.0 major changes
- #21: Secret is used so that someone cannot replace both message and MAC, putting a new matching MAC in place of the original
- #25: Operational and pending states
- #26: Currently no compression defined but could be client boundaries are not preserved 2^14 bytes or less in protocol unit md5, sha-1, none MAC des, 3des, des40, rc2, rc4, idea none encryption
- #27: Encryption mac key exchange Des/3des/des40 md5, sha1, none rsa, dh rc2 rc4 idea none
- #29: Server “ Hello Request ”- ask client to restart hello includes some random data for creating the master secret
- #30: Client generates 48-byte secret random # , encrypts using server’s public key, sends to server if diffie-hellman, p,g
- #31: PKCS standards from RSA for RSA certificates PKCS #10 cert requests PKCS #9 cert attributes PKCS #7 cert chain format application/x-pkcs7-mime used to load CA chain into browser
- #35: Possible to have more than one DN for an entry
- #37: DSS digital signature standard also
- #38: Certificate specifies public key must be appropriate for key exchange algorithm required for non-anonymous key exchange includes certificate chain - certs which verify previous ones in the chain PKCS#7 is not used since defined in sets rather than sequences
- #39: Certificate request is optional specifies list of acceptable certificate authorities specifies types of certificates requested (e.g. RSA, dh)
- #41: See next slide
- #42: Change Cipher Spec not part of handshake
- #43: Server can refuse to use session by not including session # in server hello keys for session are calculated fresh using shared master secret and new random numbers from Hello messages
- #45: Mention different kinds of certificates identity encryption etc
- #47: S-HTTP inter-operates with http signature authentication encryption public key key exchange, & externally arranged Secure * Secure-HTTP/1.4 : Request URI Secure-HTTP/1.4 200 OK response header lines convey information e.g. Certificate-Info: has cert, Encryption-Identity: x500 name ------------ IPSec RFC 1825-1829 required for IPv6, optional for IPv4 transport mode - protect contents of IP packet tunnel mode - protect entire IP packet encryption, MAC SASL Means to add authentication to connection-based protocol Variety of mechanisms Kerberos V4, GSSAPI, “External” Allows separation of authorization identity from client identity in credentials Permits authenticated state in protocol