Download to read offline
Uploaded byOlivier Bonaventure
Part2-Apps-Security.pptx
This document provides a high-level summary of Transport Layer Security (TLS): - TLS establishes an encrypted connection between a client and server through a handshake that authenticates the server and negotiates encryption parameters. - The handshake includes the client sending a ClientHello, the server responding with a Certificate and ServerHello, and agreeing on encryption keys. - Once established, the connection uses the record protocol to securely transmit encrypted and authenticated data between the client and server. Sessions can also be resumed later using the agreed session ID.
More Related Content
Similar to Part2-Apps-Security.pptx
More from Olivier Bonaventure
Part2-Apps-Security.pptx
- 1. Part 2 Internet applications Securityprinciples © O. Bonaventure, UCLouvain, 2023. Supplementary material for the Computer Networking : Principles, Protocols and Practice ebook, https://www.computer-networking.info
- 2. Agenda • Making HTTPfaster • Network security principles • Security protocols
- 3. A faster web •How could we speed up the web ? • What is our objective ?
- 4. How to improveweb ? • What can be done to improve web performance ? • Reduce unnecessary data transfers • If-Modified-Since
- 5. Reducing latency ? •How can we reduce latency ? • Move server closer to client – CDN
- 6.
- 7.
- 8. HTTP/2.0 • Key changesfrom HTTP/1.x • Binary protocol instead of ASCII • Support multiple datastreams over the underlying transport connection
- 9. A single TCP connection •One TCP connection for all objects for a given client-server pair • Minimize in-network and server resources • Beware of head-of-line blocking • Can we do better than HTTP/1.1 ?
- 10.
- 11. HTTP/2.0 • How torealise ? Source Provider Destination DATA.ind(”GET /b") DATA.ind(”GET /a") DATA.request(”GET /a…") DATA.request(“GET /b") DATA.req(”AAAAAA") DATA.req(”AAAAAA") DATA.req(”BBBB") DATA.req(”BBBB") DATA.ind(”AAAAAA") DATA.ind(”AAAAAA") DATA.ind(”BBBB") DATA.ind(”BBBB")
- 12. HTTP/2.0 Framing • Howto divide the bytestream in different streams ? AAAAABBBBBAAAAABBBB Frame type All implementations must support 16 KBytes
- 13. HTTP/2.0 Frames • Differentframe types • SETTINGS : configuration parameters • DATA : carries user data • Defines END_STREAM flag • HEADERS : HTTP command and headers • RST_STREAM : cancel stream
- 14. HTTP/2.0 Framing • Dividingstream in DATA frames AAAAABBBBAABBB Len=5,Type=Data,SID=1, Payload=“AAAAA” Len=4,Type=Data,SID=2, Payload=“BBBB” Len=2,Type=Data,Flag=ES,SID=1, Payload=“AA” Len=3,Type=Data,Flag=ES,SID=2, Payload=“BBB”
- 15. HTTP/2.0 Streams Idle open Half closed remote Halfclosed local closed Send/recv H recv ES Send ES Send/recv R Send/recv R Recv ES Send/recv R Send ES H: Headers frame ES: End_Stream fl R: RST_STREAM
- 16. HTTP/2 • Why changingHTTP ? • Reduce page load time • Minimize data exchanged • Reduce network load • Fewer transport connections • Reduce risks of attacks from ASCII parsing
- 17.
- 18. Agenda • Making HTTPfaster • Network security principles • Crypto building blocks • Client authentication • Server authentication • Key exchange • Security protocols
- 19. The security landscape •Legitimate users • Attacker B Bob Alice Terrence T A
- 20. Security threat: Privacy •Security issue • Alice sends a confidential message to Bob • How to prevent Terrence from reading the message ? B T A
- 21. Authentication • Security issue •Terrence sends a message to Bob impersonating Alice • How to prevent Terrence from spoofing messages or how can Bob verify that the message originates from Alice and not Terrence ? B T A
- 22. Message integrity • Alice sendsa message to Bob, but Terrence changes the message before it reaches Bob • How to prevent Terrence from changing the message or how to allow Bob to check that the message sent by Alice was not modified ? B T A
- 23. Denial of Service • Terrencesends so many messages to Bob that Bob is unable to process the messages sent by Alice • How to prevent Terrence from overloading Bob so that Alice cannot contact Bob ? B T
- 24. Hash functions • Properties •Easy to compute H(Msg,key) • Very difficult to find Msg2 : H(Msg,k)=H(Msg2,k) • Example hash functions • MD5, MD4, SHA-1,SHA-256 Alice Bob H H m key key m,H(m,key) insecure channel
- 25. MD5 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 16 64 2561024 8192 MD5 - Throughput in Gbps MD5
- 26. SHA1 and SHA256 0 1 2 3 4 5 6 7 1664 256 1024 8192 SHA - Throughput in Gbps SHA-1 SHA512 Benchmarks can be computed using openssl speed command
- 27. Secret-key crypto • Examples: DES, AES, RC-4, IDEA, CHACHA Alice Bob E D m key key E(m,key) insecure channel m
- 28. Cipher performance 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 16 64256 1024 8192 Cipher - Throughput in Gbps RC4 DES AES AES-256
- 29. Public-key crypto • Eachuser maintains two keys • A public key (PublicKey) which can be made public and can be used by any user to send him/her encrypted messages • A private key (PrivateKey) which is kept secret and can be used to decrypt information encrypted with the public
- 30. Public-key crypto Encryption • Examples •RSA, ECC Alice Bob E D m PubBob PrivBob E(m,PubBob) unsecure channel m Security of RSA depends on the ability to factor numbers. Best factorisation so far is 829 bits long RSA key https://en.wikipedia.org/wiki/RSA_Factoring_Challenge
- 31. Public-key crypto Signatures • Examples •RSA, DSS Alice Bob S V m PrivAlice PubAlice S(m,PrivAlice) insecure channel yes no
- 32. RSA 0 20000 40000 60000 80000 100000 120000 140000 160000 180000 512 1024 20484096 verify/s sign/s
- 33. Agenda • Sharing resources •Network security principles • Crypto building blocks • Client authentication • Server authentication • Key exchange • Security protocols
- 34. Password authentication Alice Bob Hellofrom Alice, password = blabla Info about Alice pass=blabla Never ever store a password in clear in a file What are the security risks with password based authentication ? B A
- 35. Attacks • Man inthe middle attack Terrence Alice Bob Hello from Alice, password = blabla If Terrence can capture the message, then he will know the password and ... Info from Alice, password = blabla Can we improve this by using hash functions ? B T A
- 36. Hashed Password Alice Bob Hellofrom Alice, password = Hash(blabla) Info about Alice pass=Hash(blabla) Is this solution secure against a MITM attack ? B T A
- 37. One-time passwords • Serverstores for each user • username • n /* number of allowed authentications */ • hashn(pwd) /* hash3(pwd)=hash(hash(hash(pwd))*/ An implementation of this scheme is described in : N. Haller, C. Metz, P. Nesser, M. Straw. A One-Time Password System. RFC 2289.February 1998.
- 38. One-time passwords • Whenuser wishes to be authenticated • Server sends stored value of n • User sends hashn-1(pwd) • Server compares hash(hashn-1(pwd)) with hashn(pwd) • If equal, user is authenticated, server decrements n and remembers hashn-1(pwd)
- 39. One time passwords AliceBob Hello from Alice My current n is 123 Password : Hash122(P)=VVBG Info about Alice n=123 Hash123(P)=ZROK Info about Alice n=122 Hash122(P)=VVBG Can Terrence attack this protocol ? B A
- 40. One-time passwords Alice Bob Mycurrent n is 8 Password : Hash7(P)=ABCT Info about Alice n=122 Hash122 (P)=VVBG Terrence impersonates Bob Hello from Alice Terrence already knows Hash7(P) ! and can compute HashN(P) with N>=7 Current n is 122 Hash121(P)=Z4FT Hello from Alice What can Alice do to counter this attack ? B T A
- 41. Agenda • Sharing resources •Network security principles • Crypto building blocks • Client authentication • Server authentication • Key exchange • Security protocols
- 42. Server Authentication Alice Bob Areyou Bob ? Yes, of course • A more secure protocol is necessary • Solution • Each server maintains a (public,private) key pair • PubBob , PrivBob B A
- 43. Server authentication • Isthis a secure authentication (justify) ? Alice Bob Are you Bob ? S(Yes,PrivBob) PubBob,,PrivBob Alice must already know PubBob B A
- 44. Server authentication Alice Bob Areyou Bob ? S(Yes,PrivBob) PubBob,,PrivBob Terrence Please send PubBob Possible Man in the Middle Attack The two messages sent by Bob could also have been sent by Terrence Bob's key : PubBob Is this secure ? B T A
- 45. Server authentication • Public-keycertificates • To authenticate public keys, Alice and Bob must trust a third party • Certificates l S(PubBob , PrivC) Alice Bob Are you Bob ? S(Yes,PrivBob) S(PubBob , PrivC ) PubC, ,PubBob,,PrivBob S(PubBob , PrivC ) Charles PubC,,PrivC PubC, Is this protocol secure (justify) ? B A
- 46. Are certificates sufficient? Alice Bob Are you Bob ? Terrence Are you Bob ? Terrence copies the message sent by Bob for later... Terrence sends the saved copy of Bob's message S(Yes,PrivBob) S(PubBob , PrivC ) S(Yes,PrivBob) S(PubBob , PrivC ) PubC, ,PubBob,,PrivBob S(PubBob , PrivC ) PubC , B T A
- 47. Improved authentication • RandomAliceis a nonce Alice Bob Are you Bob ?, RandomAlice Terrence Terrence copies the message sent by Bob for later... This is useless as the next request sent by Alice will contain a different random number S(Yes,RandomAlice ,PrivBob) S(PubBob , PrivC ) PubC, ,PubBob,,PrivBob S(PubBob , PrivC ) PubC B T A
- 48. Agenda • Sharing resources •Network security principles • Crypto building blocks • Client authentication • Server authentication • Key exchange • Security protocols
- 49. Key Exchange • Howcan Alice and Bob safely exchange a secret key in the presence of Terrence ? B T A T
- 50. Diffie-Hellman key exchange • Relieson modulo integer arithmetic • All users agree on • A modulus : p • A base : g
- 51. Diffie-Hellman key exchange Alice Bob A=gamod p B=gb mod p a=random int b=random int Secret=Ba mod p Secret=Ab mod p B A
- 52. Diffie-Hellman g=5, p=23 Alice Bob A=gamod p=16 B=gb mod p=21 a=8 b=13 Secret=Ba mod p =218mod 23=3 Secret=Ab mod p =1613 mod 23=3 B A
- 53. Diffie-Hellman • Is thissafe ? • Mathematics • Researchers have tried to break the scheme for more than 4 decades • Attackers • Can Terrence find an attack against Diffie-Hellman ?
- 54. B T A possible MITM attack AliceBob A=ga mod p B=gb mod p a=random int b=random int SA=Ta mod p Terrence t=random int T=gt mod p T=gt mod p SB=Bt mod p SA=At mod p SB=Tb mod p A
- 55. Solving the MITMattack • What can we do to prevent this Man in the Middle Attack ? • Pre-negotiated Shared secret • Use public keys • Public/Private keypair on Client • Public/Private keypair on Server
- 56. Authenticated Diffie- Hellman Alice Bob A=gamod p S(B=gb mod p, PrivBob) Cert(PubBob , PrivC ) Secret=Ba mod p Secret=Ab mod p PubC, ,PubBob,,PrivBob S(PubBob , PrivC ) Charles PubC,,PrivC B A
- 57. Agenda • Sharing resources •Network security principles • Security protocols • Transport Layer Security (TLS) • Ssh • Attacks against DNS
- 58. TLS works aboveTCP Application Application TLS TLS TCP TCP All data exchanged by application is encrypted and authenticated
- 59. TLS building blocks •Handshake • Authenticate server • Negotiate crypto parameters • Negotiate encryption and authentication keys • Record protocol • Transmit data securely
- 60. Phases of aTLS session • Handshake • Session establishment, key negotiation • Data transfer phase • Encrypted and authenticated records are exchanged • Session termination • Data transfer stops and session terminates
- 61. TLS handshake Alice Bob ClientHello(Ciphers, RandomAlice) ServerHello(Ciphers,RandomBob ) Certificate(PubBob , PrivC ) PubC, ,PubBob,,PrivBob S(PubBob , PrivC ) PubC E( PreMasterSecret , PubBob) Alice chooses PreMaster Secret Finished( H(handshake msgs,Key) Finished( H(handshake msgs,Key)) B A
- 62. X.509 Certificates • C=country,O=organisation , OU=Organisation Unit, ST=State, L=City • CN=Common Name • Sometimes DNS name for a server • Key usage extensions • digitalSignature, keyEncipherment, dataEncipherment, keyCertSign, ... • Optional Fields • emailAddress, subjectAltName, ...
- 63. ClientHello message • ProtocolVersion • 32 bytes long random number • 4 bytes Unix time (seconds since 01/01/1970) • 28 bytes random number • Session Id • Each SSL session has an identifier which can be used later to restart a session • List of supported Ciphers • List of supported Compression Methods
- 64. ClientHello • Supported ciphers •Authentication+Key Exchange+Cipher+Hash • TLS RSA WITH NULL MD5 • TLS RSA EXPORT WITH RC4 40 MD5 • TLS RSA WITH RC4 128 MD5 • TLS RSA WITH DES CBC SHA • TLS RSA WITH 3DES EDE CBC SHA
- 65. ServerHello • Protocol version •Random • Session Id • Optional, sent by server if it allows sessions to be resumed later • Cipher Suite • One of the client cipher suites Compression Method
- 66. Handshake (cont.) Alice Bob ClientHello(Ciphers, RandomAlice) ServerHello(Ciphers,RandomBob ) Certificate(PubBob , PrivC ) ServerHelloDone PubC, ,PubBob,,PrivBob S(PubBob , PrivC ) PubC ClientKeyExchange (E(PreMasterSecret, PubBob)) B A
- 67. Data transmission Data Data(a) Data(b) MACMAC Hash(Hkey) Hash(Hkey) Rec. Header Encrypted(Data(a)+MAC) Rec. Header Encrypted(Data(b)+MAC) Encrypt(Ekey) Encrypt(Ekey) • Divide the byte stream in records • Each record is authenticated • and encrypted
- 68. Record Authentication • Howto authenticate records ? • Key • Sequence number • Data • Cryptographic construction • HMAC
- 69.
- 70. Session resumption Alice Bob ClientHello(Ciphers, Session:123) ServerHello(Ciphers,Session:123 ) ChangeCipherSpec Finished( H(handshake msgs,Key) PubC, ,PubBob,,PrivBob S(PubBob , PrivC ) PubC, Session 123 : MasterKey ChangeCipherSpec Finished( H(handshake msgs,Key) Session 123 : MasterKey B A
- 71. TLS 1.3 • Whychanging TLS ? • TLS was considered to be too slow • Two round-trip-times • TLS was considered to be too complex • Some attacks have affected TLS • Privacy became a strong focus within the IETF
- 72. Design objectives • simplifythe design by removing unused or unsafe protocol features • only a small number of cipher suites • improve the security of TLS • no compression or unsafe features • improve the privacy of the protocol • perfect forward secrecy • reduce the latency of TLS
- 73. Perfect Forward Secrecy • Definition •An encryption system has the property of forward secrecy if plain-text (decrypted) inspection of the data exchange that occurs during key agreement phase of session initiation does not reveal the key that was used to encrypt the remainder of the session.
- 74. Does TLS support PFS? • Not when RSA is used ClientHello (Ciphers, RandomAlice) ServerHello(Ciphers,RandomBob ) Certificate(PubBob , PrivC ) E( PreMasterSecret , PubBob) Alice chooses PreMaster Secret T Z PubC, ,PubBob,,PrivBob S(PubBob , PrivC ) PubC • Some TLS ciphers use Diffie-Hellman
- 75. Simplifying the handshake • Reducethe number of ciphers supported • Less negotiation between client/server • Diffie-Hellman is now required • Client immediately starts Diffie-Hellman before having validated the server certificate
- 76. TLS 1.3 handshake AliceBob ClientHello (ga mod p, RandomAlice) ServerHello(gb mod p,RandomBob ) Certificate(PubBob , PrivC ) Sign(DHkey,Handshake) Finished Encrypted Data PubC, ,PubBob,,PrivBob S(PubBob , PrivC ) PubC Alice computes DHkey Finished, Encrypted Data Bob computes DHkey B A
- 77. A single physicalserver for many TLS services • Server Name Indication Alice Bob PubC, ,PubBob,,PrivBob S(PubBob , PrivC ) PubC , Tom PubC, ,PubTom,,PrivTom S(PubTom , PrivC ) ClientHello (ga mod p, RandomAlice,SNI=Bob) ServerHello(gb mod p,RandomBob ) Certificate(PubBob , PrivC ) Sign(DHkey,Handshake) Finished Encrypted Data Privacy concern: can be used to track sites visited by users if ClientHello is captured. ESNI
- 78. Agenda • Sharing resources •Network security • Security protocols • Transport Layer Security (TLS) • Ssh • Attacks against DNS
- 79.
- 80. A telnet session clientserver Connect_req Connect_resp Connect_conf username Login: Password: mypass • Is this secure ?
- 81. SSH • Basic principles •Public key used for authentication • Each host (client/server) has a public keypair • Diffie Hellman for key exchange • Secret key encryption for confidentiality
- 82.
- 83. SSH : keyexchange • Principles • Diffie Hellman allows to securely exchange keys • but it needs to be authenticated ! • When you use ssh to access UCLouvain’s servers, how do you authenticate them ?
- 84. Key exchange client SSH2_MSG_KEXINIT B=gb modp Sign(Hash(Vclient||Vserver|| KEXClient||KEXServer||PubServer||A||B||K) SSH2_MSG_KEXINIT A=ga mod p ,PubServer,,PrivServer K=Ab mod p
- 85. User authentication • Howdoes the server authenticate the user ? • Username/password • Sent over the encrypted channel • Public key authentication • User has his/her public/private keypair • Server knows user's public key and sends challenge
- 86. Agenda • Sharing resources •Network security principles • Security protocols • Transport Layer Security (TLS) • Ssh • Attacks against DNS
- 87. Attacks against DNS •DNS is key, if an attacker can change the responses returned by resolvers, this could have a major impact • Users rely on their resolver to obtain name-to-address mappings
- 88. Packet spoofing • Onthe Internet, every device has one IP address • All the packets sent by this device use its IP address as their source • Is it possible for Terrence to send a packet using Alice’s IP address ?
- 89.
- 90. Spoofing attack B T A Q? www.bob.net www.bob.net=2001:db8:12::1 Responsesent using Bob’s IP address How can Alice verify that Bob’s message is legitimate and Terrence’s message invalid ?
- 91. Countering spoofing attacks Identification Flags 32bits Number of additional Number of authority Number of answers Questions (variable number of resource records) Number of questions Answers (variable number of resource records) Authority (variable number of resource records) Additional information (variable number of resource records) Source port Dest. port UDP Length Checksum UDP header DNS message Alice should use random source port in her queries and verify the server response Alice should use random identifiers and verify the server response Total: 32 bits of randomness https://tools.ietf.org/html/rfc6056
- 92. Other approaches • DNSSEC •DNS extensions that allows servers to sign their reponse using public keys • DNS responses sent in clear over UDP • Alice can verify the cryptographic signature • DNS over TLS or DNS over HTTPS • Request/Response sent over TLS session(encrypted and authenticated) • cannot be hijacked by Trudy
- 93. Denial of Service attacks •How can Trudy saturate Alice’s link to make it impossible for her to use Internet ? • Naive approach T A Lots of traffic sent by Trudy Can Terrence hide the attack and amplify it ? https://www.cloudflare.com/en-gb/learning/ddos/famous-ddos-attacks/ What was the largest known DDoS attack ?
- 94. Amplification attack • Protocoldesigners, beware ! B T A S=B,D=A www.bob.net=... Terrence will try to send a short request that triggers a large response from Bob
Editor's Notes
- #38 An implementation of this scheme is described in : N. Haller, C. Metz, P. Nesser, M. Straw. A One-Time Password System. RFC 2289.February 1998.
- #40 In the example above, hash(VVBG)=ZROK
- #41 To avoid this Problem, Alice must remember the last value of n used by each server with whom she is communicating and should be warned when the server requests a different value of n that the previous value.
- #43 The public-private key pair can be a RSA key-pair for example.
- #44 In this slide and the subsequent ones,S(Yes,PrivBob) is a signed message that contains “Yes” and is signed by using the ,PrivBob private key . The validity of this signature can be checked by using ,PubBob
- #45 A Man in the Middle or Woman in the Middle attack is possible in this case as Terrence can easily intercept the messages sent by Alice and replace them with fake messages that contain her public key and signature.
- #46 In the example above, we use S(PubBob , PrivC) to indicate a certificate for Bob's key issued by Charles. Charles usually checks the identity of Bob offline and then creates the certificate. Charles is sometimes referred to as a Trusted Third Party (TTP).
- #47 Replay attacks are common threats to security protocols.
- #48 The nonce is a random number. Note that to be secure, this nonce should be truly random. In practice, generating random numbers is not easy, For a detailed discussion, see : RFC1750 Randomness Recommendations for Security. D. Eastlake, S. Crocker, J. Schiller. December 1994.
- #94 The biggest DDoS attack to date took place in September of 2017. The attack targeted Google services and reached a size of 2.54 Tbps. Google Cloud disclosed the attack in October 2020. The attackers sent spoofed packets to 180,000 web servers, which in turn sent responses to Google. The attack was not an isolated incident: the attackers had directed multiple DDoS attacks at Google's infrastructure over the previous six months.