1 / 53

Sample Application Layer Protocols

Sample Application Layer Protocols. Why study existing application layer protocols? Introduce widely used App Layer Protocols HTTP (hypertext transfer protocol) slides 7-21 SMTP (simple mail transfer protocol) slides 22-32 DNS (domain name service) slides 33-45

ishana
Télécharger la présentation

Sample Application Layer Protocols

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Sample Application Layer Protocols • Why study existing application layer protocols? • Introduce widely used App Layer Protocols • HTTP (hypertext transfer protocol) slides 7-21 • SMTP (simple mail transfer protocol) slides 22-32 • DNS (domain name service) slides 33-45 • FTP (file transfer protocol) slides 46-53 • Not covered in class, but responsible for content

  2. Why study existing App Layer Protocols? • We will be developing our own app layer protocol • Examples will help us understand concept of a protocol • Need to be able to • Design a protocol • Implement a protocol • Need to understand • Security concepts • Protocol vulnerabilities • Types of attacks • Our app layer protocol should mitigate as many security risks as possible

  3. Requirements of Some Network Apps

  4. Services Provided byInternet Transport Protocols • Connection-oriented • Client & server exchange control data (handshaking) before app-level messages begin to flow • Full-duplex connection: messages can be sent in either direction at same time • Client & server must destroy connection when done sending messages • Reliable transport • Delivers messages without errors and in proper order • Congestion control • Can slow-down or speed-up transmission rate between sender and receiver • Exists for benefit of entire Internet, rather than for benefit of communicating processes

  5. Some Network Apps and Their Protocols

  6. Wireshark (v2.4.0) • Description • A network protocol analyzer • Capture and interactively browse traffic on a computer network • Runs on most platforms e.g., Windows, macOS, Linux, and UNIX • Used by network professionals, security experts, developers, and educators • Freely available as open source; released under GNU GPL version 2 • Wireshark used to be known as Ethereal • Demo • Open browser; Start capturing network traffic; Go to a URL (www.lemoyne.edu); Stop capturing network traffic • Do same thing for portal.lemoyne.edu

  7. Hypertext Transport Protocol (HTTP) • Purpose • Describes how • Web clients request pages (i.e., files) from web servers • Web servers transfer web pages to clients • A specialized file transfer protocol • History • Fairly new protocol • First version in 1996 (RFC 1945) • Latest update in 2014 (RFC 7230)

  8. HTTP: User’s Perspective • Typical sequence • User clicks on hypertext link • Browser sends HTTP request to web server • Web server sends HTTP response to client • Browser displays page • Web server is stateless • Does not remember HTTP requests from a client

  9. HTTP: Network Services • Reliable data transfer? • Yes • Specific bandwidth requirements? • No • Does an end-to-end delay matter? • No

  10. HTTP: Connection Types Persistent connection (default) Non-persistent connection Client initiates TCP connection via port 80 Client sends request Server sends response Server closes TCP connection • Client initiates TCP connection • via port 80 • Client sends request • Server sends response • Server waits specified timeout duration before closing TCP connection

  11. HTTP: URI Format(https://tools.ietf.org/html/rfc3986#section-3.5) • Service • The application layer protocol (e.g., http); ends with colon • Server information (optional) • Two slashes, required by HTTP and HTTPS • Username:Password@ (optional) • Server • Server’s address (the server domain) • Port (optional) • Colon followed by a number • URI • Slash followed by resource; a directory path or name of file, application, or database • Query (optional) • Starts with a question mark (?); parameters separated by ampersand (&) • Anchor (optional) • Starts with hash character (#) for HTTP; browser jumps to this location in HTML

  12. HTTP: Client Commands • Client command • ASCII text lines; each ends with CrLf • One line with a keyword command followed by a resource identifier and HTTP version • Some meta header lines i.e., field:value pairs • Blank line • Optional data

  13. HTTP: Client Commands (cont’d) • Sample client (keyword) commands • GET • Data retrieval from server • HEAD • Similar to GET; only returns associated meta-headers • POST • Provides upload functionality; resource identifier used for processing the uploaded info; reply may contain response data • PUT • Alternative to POST; place data in location specified by resource identifier • DELETE • Remove resource identifier from server

  14. HTTP: Server Replies • Server reply • ASCII text lines; each ends with CrLf • One status line containing the HTTP version followed by a 3-digit status code and associated phrase • Some meta header lines i.e., field:value pairs • Blank line • data being sent to client

  15. HTTP: Server Replies (cont’d) • Sample 3-digit replies • 200 OK • 301 Moved Permanently • Requested object has been permanently moved • Location: header shows URL of new location • 400 Bad Request • Request not understood by server • 404 Not Found • 505 HTTP Version Not Supported

  16. HTTP Example(Run Socket_HTTP_Client.java; capture via Wireshark) • A Client Request GET /voorhedp/index.html HTTP/1.1 Host: www.lemoyne.edu User-agent: Mozilla/4.0 Accept-language: en • A Server Reply HTTP/1.1 200 OK Date: Wed, 20 Jan 2016 17:36:00 EST Server: Apache/1.3.0 (Unix) Last-Modified: Wed, 20 Jan 2016 10:00:00 EST Content-Length: 6821 Content-Type: text/html CrLf (data datadatadata…)

  17. HTTP: Support Security? • Does HTTP provide and/or support: • Confidentiality? • No (messages sent in plaintext) • Integrity? • No (relies on checksums at lower layers of protocol stack) • Availability? • Could spoofed HTTP requests be a denial-of-service attack? • Non-repudiation? • No (no idea who is requesting page) • Assurance? • No • Authenticity? • No • Anonymity? • No (because of cookies)

  18. HTTP: Support Security? (general risks) • General HTTP Risks • Unauthenticated client • Unauthenticated server • Client privacy • Use HTTP meta-header Referer: URL to identify where the linked URL came from • Information leakage • Client meta-headers usually identify type of web browser (version, OS) • Server meta-headers usually identify type of server, version, and supported plug-ins • Server location profiling • Use GMT date and local time to determine time zone; target attacks for middle of night. • Access to operating system • e.g., cause buffer overflow to gain direct access to OS • Insecure applications • Lower-layer protocols

  19. HTTP: Support Security? (URL Exploitation) • URL Exploitations • Hostname resolution attacks • Redirect hostname resolution system (DNS) • Host cloaking • Camouflage a hostname without modifying DNS • URI cloaking • Hex encoding of special characters; attackers use this to hide actual URL • Cutting and splicing • Remove (cut) or add (splice) information to a URL to modify its path • Query abuse • Modify query parameters destined for CGI (common gateway interface) • SQL Injections • Cross-site scripting • Occurs when data submitted to server by one user is sent to another user e.g., online forums and blogs allow users to post content and hyperlinks.

  20. HTTPS • HTTP Secure • Aka: HTTP over TLS, HTTP over SSL • Connection is encrypted using either • TLS (Transport Layer Security) newer • SSL (Secure Sockets Layer) • Uses public key cryptography to establish secret key • Uses same secret key to encrypt/decrypt data in transit • Uses public key certificate • Gives assurance that the web server is who they say they are

  21. HTTPS: Support Security? • Does HTTPS provide and/or support: • Confidentiality? • Yes (uses cryptography) • Integrity? • No (But does eliminate man-in-the-middle and eavesdropping attacks) • Availability? • Could spoofed HTTPS requests be a denial-of-service attack? • Non-repudiation? • No (no idea who is requesting page) • Assurance? • Yes (uses public key cryptography and public key certificates) • Authenticity? • Yes (uses public key certificates) • Anonymity? • No (because of cookies)

  22. Simple Mail Transfer Protocol (SMTP) • Purpose • Send a message (aka e-mail) from one host to another host • Support sending attached files as part of message • Message (and attached file) contents on receiving host needs to match message contents on sending host • Sending host • Sends packets containing portions of message in correct order • Receiving host • Packets may be received out of order • Packets need to be re-assembled in correct order • History • A very old protocol • First version in 1981 (RFC 788); modeled after FTP • Latest update in 2001 (RFC 2821)

  23. E-Mail Protocol Suite • Alice sends an e-mail to Bob • Alice’s e-mail client sends e-mail to her server using SMTP • Alice’s e-mail server sends e-mail to Bob’s server using SMTP • Bob’s e-mail client uses 1 of 3 protocols • Post Office Protocol Version 3 (POP3) • Download mail to client; supports download-&-delete, download-&-keep • Internet Mail Access Protocol (IMAP) • Read mail on server • Hyper Text Transfer Protocol (HTTP) • Read mail on server; for web-based e-mail clients

  24. SMTP: Overview • Used by sender’s e-mail client and by all e-mail servers • When Alice sends an e-mail to Bob • Alice’s e-mail client (SMTP client) sends e-mail to Alice’s e-mail server (SMTP server) • Alice’s e-mail server (SMTP client) sends e-mail to Bob’s e-mail server (SMTP server) • Each e-mail server • Acts as SMTP client (when sending e-mail) • Uses message queue • Contains e-mails being sent • Retry sending an e-mail X times, every N minutes; If failure after X times, notify sender • Acts as SMTP server (when receiving e-mail) • Has mailbox for each e-mail user • Contains e-mails sent to this user

  25. SMTP: Overview (cont’d) • Originally designed to send text-only messages • An e-mail contains header lines From: voorhedp@lemoyne.edu To: voorhedp@lemoyne.edu Subject: hello • And a message body (message text) • There’s a blank line (CrLf) between last header line and message body • MIME (Multipurpose Internet Mail Extensions) • Allows us to attach files (e.g., images, music) to messages • RFCs 2045, 2046 • Adds additional header lines Content-Transfer-Encoding: Content-Type:

  26. SMTP: Network Services • Reliable data transfer? • Yes • Specific bandwidth requirements? • No • Does an end-to-end delay matter? • No

  27. SMTP Example(Alice sends e-mail to Bob) • Alice uses e-mail client software to create e-mail to Bob • Instructs client software to send message • Alice’s e-mail client software: • Creates TCP connection with her e-mail server (port 25) • Sends message to her e-mail server (port 25) • Destroys TCP connection with her e-mail server (port 25) • Alice’s e-mail server: • Creates TCP connection with Bob’s e-mail server (port 25) • Sends ALL messages in queue destined for this e-mail server (port 25) • Destroys TCP connection with Bob’s e-mail server (port 25) • Bob’s e-mail server: • Put’s e-mail from Alice in Bob’s mailbox • At Bob’s convenience: • Uses his e-mail client software to read Alice’s message

  28. SMTP Example(Without Authentication) • SMTP Client: telnet smtp.gmail.com 25 create connection to an SMTP server • SMTP Server: 220 mx.google.com ESMTP • SMTP Client: EHLO lemoyne.eduextended hello; senders domain • SMTP Server: 250-mx.google.com at your service, [192.231.124.16] • SMTP Client: MAIL FROM:voorhedp@lemoyne.eduinitiate message transmission • SMTP Server: 250 voorhedp@lemoyne.edu ... Sender ok • SMTP Client: RCPT TO:<voorhedp@lemoyne.edu> • SMTP Server: 250 voorhedp@lemoyne.edu ... Recipient ok • SMTP Client: DATA start message text • SMTP Server: 354 Enter mail, end with “.” on a line by itself • SMTP Client: Hi Dave, • SMTP Client: I hope you don’t mind that I am sending a message to myself! • SMTP Client: .terminate message text • SMTP Server: 250 Message accepted for delivery • SMTP Client: QUIT • SMTP Server: 221 mx.google.com closing connection

  29. SMTP: Support Security? • Does SMTP provide and/or support: • Confidentiality? • No • Message sent in plaintext • Attached files sent as-is • Types of attacks • Man-in-the-middle • Copy plaintext message and/or attached file data • Spoofing • Change FROM address (pretend to be a valid user) • Denial-of-service, distributed denial-of-service • Overwhelm an email server with spoofed messages

  30. SMTP: Support Security? (cont’d) • Does SMTP provide and/or support: • Integrity? • No • Relies only on checksums at lower layers of protocol stack • Types of attacks • Man-in-the-middle • Modify plaintext message or file data • Spoofing • Change FROM address (pretend to be a valid user) • Availability? • Easy to send lots of spoofed emails to a server

  31. SMTP: Support Security? (cont’d) • Does SMTP provide and/or support: • Non-repudiation? • Protocol does not require recording/logging of email messages • Assurance? • No • Authenticity? • Only between email client and authenticated user’s email server • Anonymity? • No, since FROM must be specified (even though this is easily spoofed)

  32. SMTPS: SMTP Secure • Application layer • Continues to use SMTP as designed • Transport layer • Connection is secured using: • TLS (Transport Layer Security) newer • SSL (Secure Sockets Layer) or • Ensures confidentiality (using crypto) and integrity (using a message integrity check) • Not an end-to-end security mechanism • May 19, 2014. The Only Email System The NSA Can't Access. Forbes. • Aug 9, 2013. What Are Your Options Now For Secure Email? Popular Science.

  33. Domain Name System (DNS) • Purpose • A directory service for the Internet • Translates names to IP addresses (and vice versa) • Used by other app layer protocols (e.g., FTP, SMTP, HTTP) to resolve user-supplied host names • History • A very old protocol • First version in 1983 (RFC 882) • Latest update in 1987 (RFC 1034 & 1035) • Other informational RFCs have been published since

  34. DNS: Architecture • Distributed Architecture • To divide workload of managing host names • Five types of DNS servers • Root • TLD (Top Level Domain) • Primary • Secondary • Caching

  35. DNS: Architecture (cont’d) • Root servers • 13 root DNS servers; primary source for doing name resolution • Does not store hostnames, contains pointers to other DNS servers • For reverse lookups, roots maintain lists of subnets and servers that manage the subnets • Official list of root servers at www.root-servers.org • Three types of TLD (Top Level Domain)servers • gTLD (Generic TLD) e.g., com, edu, gov • ccTLD (Country Code TLD) i.e., one per country • SLD (Secondary Level Domain) defined by ccTLD • Does not store hostname, contains pointers to primary name servers for a domain

  36. DNS: Architecture (cont’d) • Primary servers • 1 per domain • Authoritative source for specific host name resolution • Owned and managed by specific domains • Secondary servers • Domain backups • Provide authoritative responses but may not be directly owned or managed by the domain • Receive periodic updates from primary servers called a zone transfer using a TCP connection

  37. DNS Lookup Algorithm • Request www.aNewDomain.org • Assumption: first time this domain name is being requested • Root nameserver asked for TLD nameserver for org • Response is an IP address for the org TLD (authoritative) • The org nameserver asked to lookup aNewDomain.org • Response is an IP address for the aNewDomain.org Primary server (authoritative) • The aNewDomain.org nameserver asked to lookup www.aNewDomain.org • Response is IP address for this server • If every DNS request did this, result would be too much DNS traffic • Secondary and cache servers used to avoid having to contact root, TLD and primary nameservers

  38. DNS: Architecture (cont’d) • Caching servers • Speed for service providers • Caching DNS servers receive and relay new requests and cache replies for faster access • Provide “unauthenticated” results • Generated much faster than if the host needed to query a root, ccTLD, SLD, and primary DNS server • Each DNS reply includes a cache timeout duration • The data should be held until the information expires • Usually the duration is between a day and a week • Most large companies and Internet providers operate caching DNS servers for their customers.

  39. DNS: Network Services • Reliable data transfer? • No: by default, DNS is connection-less • Uses (transport layer) UDP and port 53 • Yes: optionally can use connection-oriented • Uses (transport layer) TCP and port 53 • Specific bandwidth requirements? • No • Does an end-to-end delay matter? • No

  40. DNS: Database • A distributed database • Contains resource records (RRs) • RR format is a 4-tuple:(Name, Value, Type, TTL) • Type is A • Name is hostname and Value is IP address • Type is NS • Name is a domain (e.g., lemoyne.edu) and Value is the hostname of an authoritative DNS server • Type is CNAME • Name is an alias hostname (e.g., lemoyne.edu) and Value is the canonical hostname (www.lemoyne.edu) • Type is MX • Name is an alias email server name and Value is the canonical email server name • TTL (time to live) • Determines when resource record should be removed from a cache server

  41. DNS: Protocol • A simple request/reply protocol • 12-byte header • See RFC 1035 pages 24-27 • 4 blocks of optional info • See RFC 1035 pages 27-29 • Simple request • Has info for 1 question • No data in other 3 sections • Simple reply • May repeat question • 1 answer section • DNS database updated statically via config file • RFC 2136 (1997) • Adds dynamic UPDATE via DNS protocol Identification Flags Number of answer RRs Number of questions Number of authority RRs Number of additional RRs Questions (variable number of questions) Answers (variable number of resource records) Authority (variable number of resource records) Additional Information (variable number of resource records)

  42. DNS: Support Security? • DNS reputation: most insecure protocol on Internet • Why? Protocol assumes trust between DNS servers • Does DNS provide and/or support: • Confidentiality? • No (messages sent in plaintext) • Integrity? • No (relies on checksums at lower layers of protocol stack) • Availability? • Hard to do DDOS (protocol is simple and root/TLD servers are well managed) • Non-repudiation? • No (no idea who is updating database) • Assurance? • No (assumes trust, but does not verify) • Authenticity? • No • Anonymity? • Yes

  43. DNS: Support Security? (types of attacks) • Technical risks • Unauthenticated responses • Attacker observes a DNS request and forges a DNS reply • DNS Performance versus Security • DNS request sent to many servers in parallel • Fastest reply used for name resolution (could come from attacker) • DNS protocol operates over TCP or UDP • TCP is slower, thus most DNS requests use UDP • Easier for attacker to send a reply (no need to hijack TCP connection) • DNS Poisoning • Attacker alters DNS database(s); hides using spoofed IP address • DNS cache poisoning • Attacker sends reply to DNS cache server with long TTL value

  44. DNS: Support Security? (types of attacks, cont’d) • Technical risks (cont’d) • Blind ID attack • Attacker generates flood of DNS replies, each containing a different identifier value • Attacker can generate 65,536 false DNS packets—one for each session identifier • If correct session identifier is received before a real server can provide the true reply, then the caching server becomes poisoned • Corrupt DNS packets • Some DNS implementations do not properly check data boundaries • A packet may claim to have more data than it actually contains or may not contain enough data • Can result in buffer overflows and underflows

  45. DNS: Support Security? (types of attacks, cont’d) • Social risks • Similar hostnames • Typographical errors entered by user • Attackers can use this knowledge to hijack connections • Automatic name completion • Web browsers support automatic name completion; browser usually appends .com • What if the TLD is not .com? • Attacker can effectively hijack the domain by registering the .com name. • Social engineering • Attacker convinces name registrar that they have authority to change a DNS record • Domain renewals • Domain names expire (in 1, 2 or 5 years) • What if domain owner forgets to renew their domain? • Attacker can register domain to another IP address

  46. File Transfer Protocol (FTP) • Purpose • Transfer a file between two hosts • File contents on receiving host needs to match file contents on sending host • Sending host • Sends packets containing portions of file contents in correct order • Receiving host • Packets may be received out of order • Packets need to be re-assembled in correct order • History • A very old protocol • First version in 1971 (RFC 114) • Latest update in 1985 (RFC 959) • 1997 (RFC 2228) proposes security extensions • 1998 (RFC 2428) adds support for IPv6

  47. FTP: User’s Perspective • Typical sequence • Start FTP client • Provide username and password • To authenticate to FTP server • Transfer files between FTP client and FTP server • Download (FTP server to FTP client) • Upload (FTP client to FTP server)

  48. FTP: Network Services • Reliable data transfer? • Yes • Specific bandwidth requirements? • No • Does an end-to-end delay matter? • No

  49. FTP Example(active mode) • FTP client creates TCP connection with FTP server (port 21) • FTP client sends username command (4-letter command with data) • USER username • FTP server sends response (3-digit number) • 331 meaning: username ok, password required • FTP client sends password (4-letter command with data) • PASS password • FTP server sends response (3-digit number) • 230 meaning: user logged in, proceed • FTP client requests list of files in current directory (4-letter command) • LIST • FTP server creates TCP connection with FTP client (port 20) • FTP server sends list of files over this new connection (port 20) • FTP server destroys TCP connection with FTP client (port 20) • FTP client requests a file be downloaded to client (4-letter command with data) • RETR filename • FTP server creates TCP connection with FTP client (port 20) • FTP server sends file over this new connection (port 20) • FTP server destroys TCP connection with FTP client (port 20)

  50. FTP: client commands; server replies • Client command • Sent as ASCII text • Each ends with CrLf • Sample client commands • CDUP change to parent dir • CWD change directory • LIST request list of files • PASS send password • QUIT logout • RETR download a file • STOR upload a file • USER send username • Server reply • Three digit ASCII number • Sample 3-digit replies • 125 data connection already open; transfer starting • 225 data connection open; no transfer in progress • 226 closing data connection; requested file action successful • 230 user logged in, proceed • 331 username ok, need password • 425 can't open data connection • 530 not logged in See RFC 959 for complete description of FTP See pages 35-38 for details on server reply.

More Related