HTTP Web eb and d URLs Web page consists of objects Addressable - - PowerPoint PPT Presentation

HTTP

Web eb and d URLs

 Web page consists of objects

 Addressable by a URL  Can be HTML file, JPEG image, Java applet, audio file,…

 Bound to a host name and a path name within host

Portland State University CS 430P/530 Internet, Web & Cloud Systems

www.someschool.edu/someDept/pic.gif host name path name

HTTP TP

 Hypertext transfer protocol

 Web’s application layer protocol  Send URL from client to server  Return content from server to

client

 Client/server model  HTTP 1.0: RFC 1945  HTTP 1.1: RFC 2068

Portland State University CS 430P/530 Internet, Web & Cloud Systems

PC running Explorer Server running Apache Web server Mac running Navigator

HTTP TP over ervie view w (cont ntinued inued)

 Uses TCP:

 Client initiates bi-directional TCP connection (via socket) to server, port

80

 Server accepts TCP connection from client  HTTP messages (application-layer protocol messages) exchanged

between browser (HTTP client) and Web server (HTTP server)

 Messages encoded in text

 TCP connection closed

Portland State University CS 430P/530 Internet, Web & Cloud Systems

HTTP TP req equest uest me mess ssag age

 Two types of HTTP messages: request, response  HTTP request message:

 ASCII (human-readable format)

Portland State University CS 430P/530 Internet, Web & Cloud Systems

GET /somedir/page.html HTTP/1.1 Host: www.someschool.edu User-agent: Mozilla/4.0 Connection: close Accept-language:fr (extra carriage return, line feed) request line (GET, POST, HEAD commands) header lines Carriage return, line feed indicates end

• f message

http://www.someschool.edu/somedir/page.html

HTTP TP res espon ponse se me mess ssag age

Portland State University CS 430P/530 Internet, Web & Cloud Systems

HTTP/1.1 200 OK Date: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 …... Content-Length: 6821 Content-Type: text/html Connection: close data data data data data ... status line (protocol status code status phrase) header lines data, e.g., requested HTML file

HTTP TP hea eader ders

 Contains a variety of headers for implementing

 Caching  Session management (cookies)  Authentication  Tracking (referer)  Localization (language)  Content-encoding  Covered in 494/594 and 495/595 classes (Internetworking Protocols

and Web Security)

 Also contains headers for managing connection …

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Ser erial, ial, non-per persist sistent ent connect nnections ions

 HTTP/1.0  One request/response per

connection

 simple to implement  server parses request, responds,

and closes connection

 RTT = round-trip time

total = 2RTT+transmit time

Portland State University CS 430P/530 Internet, Web & Cloud Systems

time to transmit file initiate TCP connection RTT request file RTT file receivedtime time

Ser erial, ial, non-per persist sistent ent connect nnections ions

Client

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Server

SYN SYN SYN SYN ACK ACK ACK ACK ACK DAT DAT DAT DAT FIN ACK

0 RTT 1 RTT 2 RTT 3 RTT 4 RTT

Server reads from disk

FIN

Server reads from disk Client opens TCP connection Client sends HTTP request for HTML Client parses HTML Client opens TCP connection Client sends HTTP request for image Image begins to arrive Then delivers HTML before closing the connection

Iss ssue ue

 Multiple embedded objects on page

 Connection setup latency adds extra round trips per transfer (e.g. TCP’s

three-way handshake)

 Server and network overhead

 Connection handling, extra packets

 Short transfers hard on TCP

 (e.g. slow-start, loss recovery algorithm)

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Pa Parall rallel el non-per persis sistent ent conn nnection ections

 Netscape browser (1990s)  Improve latency by using multiple concurrent connections

 Browsers often open up to 6-8 parallel TCP connections to fetch

referenced objects

 Different parts of Web page arrive independently on separate

connections (object demux via connections)

 Can grab more of the network bandwidth than other users

 Doesn’t improve response time all the time

 TCP connections contending with each other causing more packet losses

and delay

 OS overhead for each TCP connection

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Per ersis sisten ent t HTTP TP connection nnections

 Default in HTTP/1.1

 Server leaves connection open after sending response  Client sends additional requests on the same connection as soon as it

encounters a referenced object

 Subsequent HTTP messages between same client/server sent over

• pen connection

 On same TCP connection: server, parses request, responds, parses new

request,..

 As little as one RTT for all the referenced objects

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Per ersis sisten ent t HTTP TP ben enef efits its

 Server overhead reduced

 Less connection setup, more data transfer

 TCP congestion control behavior improved

 Longer connections with larger congestion windows

 Response time improved

 Avoids multiple, serial TCP handshakes

 New HTTP request header for controlling

 Connection: keep-alive  Connection: close

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Per ersis sisten ent t HTTP TP connection nnection exa xample ple

Client

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Server

ACK ACK DAT DAT ACK

0 RTT 1 RTT 2 RTT

Server reads from disk Client sends HTTP request for HTML Client parses HTML Client sends HTTP request for image Image begins to arrive

DAT

Server reads from disk

DAT

Client

HTTP TP exa xample ple

 Non-persistent HTTP/1.0

mashimaro <~> 9:11AM % nc -C chi-ni.com 80 GET / HTTP/1.0 Host: chi-ni.com HTTP/1.0 200 OK … Connection: close Content-Type: text/html <HTML> <HEAD> <TITLE>Jeannie's Web Site</TITLE> </HEAD> <BODY> <IMG SRC="./2007_06_11-09_31_40.jpg"> </BODY> </HTML> mashimaro <~> 9:21AM %

 Persistent HTTP/1.1

mashimaro <~> 9:20AM % nc -C chi-ni.com 80 GET / HTTP/1.1 Host: chi-ni.com Connection: keep-alive HTTP/1.1 200 OK … Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html <HTML> <HEAD> <TITLE>Jeannie's Web Site</TITLE> </HEAD> <BODY> <IMG SRC="./2007_06_11-09_31_40.jpg"> </BODY> </HTML> GET /2007_06_11-09_31_40.jpg HTTP/1.1 Host: chi-ni.com Connection: close HTTP/1.1 200 OK Content-Length: 539 Connection: close Content-Type: image/jpeg JFIFHHC … mashimaro <~> 9:20AM %

Prob

• blems

lems wi with th HTTP/ TP/1.1

 Serial delivery of objects

 Head-of-line object blocking  Stall in one object prevents delivery of others

 Most useful information in first few bytes (layout info)

 Multiple connections allow incremental rendering of images

Portland State University CS 430P/530 Internet, Web & Cloud Systems

HTTP TP ope perat ration ion

 Want the best of both worlds

 Persistence

 Single TCP connection

 Parallel object delivery

 Ability to simultaneously retrieve embedded objects over connection

 Need application/object level demux within a single TCP connection

to emulate multiple connections

 Leads us to SPDY (2009) and HTTP/2, then QUIC and HTTP/3

Portland State University CS 430P/530 Internet, Web & Cloud Systems

HTTP/2

HTTP/ TP/2

 Two main improvements

 Multiplexed streams  Server-push

HTTP/ TP/2 2 mu multiple tiplexed ed st strea eams ms

 HTTP/1.1

• Pipelined, sequential operation
• n each connection
• Must use multiple connections

to get parallel delivery of

• bjects
• Typically, 4-8 outstanding

requests on 4-8 connections

• Still resource intensive on the

server

 HTTP/2

• One connection, many

pipelined, concurrent requests

• Normally limited to 100

Client Server Client Server

HTTP/1.1 Sequential HTTP/2 Multiplexed

HTTP/ TP/2 2 mu multiple tiplexed ed st strea eams ms

 How?

 HTTP stream identifiers combined with range requests/responses

 Implemented as a framing protocol within HTTP  Server labels data with the object it is for and the range of bytes within it  Application-layer demultiplexing of object data  Allows one to support pipelining but avoid HOL blocking

 Application specific solution to transport protocol problem.

De Demo mo

 http://http2.golang.org/gophertiles  HTTP/1

 Handshaking overhead, poor congestion control behavior, multiple RTT

to request individual tiles

 Exacerbated with lossy/wireless links and long RTTs

 HTTP/2

 One handshake, better congestion control behavior, tiles requested in

single RTT

HTTP/ TP/2 2 se server er pu push sh

 HTTP/1.1

 Client fetches origin page  Must parse base page for

embedded objects before submitting subsequent requests for them

 Server often knows what client

will request next

initiate TCP connection RTT RTT parse and request embedded

• bjects

request file time time send file

HTTP/1.1

HTTP/ TP/2 2 se server er pu push sh

 Support for server to push

content to client

 Preload content directly into

browser cache so subsequent loads hit

 Especially useful for single-

page applications

initiate TCP connection RTT RTT request file push embedded

• bjects

time time send file

HTTP/2

Iss ssue ues s wi with th HTTP/2 P/2

 Initial connection setup

 Multiple round-trips required for a single transfer still  TCP handshake  TLS handshake  HTTP request/response

 TCP congestion control still a bottleneck  No support for error correction for lossy wireless links  TCP connection bound to IP address

 Instead of browser session  Session lost upon migration from WiFi to cellular

 Motivates Google's QUIC

Portland State University CS 430P/530 Internet, Web & Cloud Systems

QUIC (now HTTP/3)

QU QUIC

 Quick UDP Internet Connections

 A reliable, multiplexed transport over UDP  Always encrypted  Reduced RTT times  Runs in user-space  Open-source

 Google's rewrite of web protocols to improve performance

 Bypass IETF and standards process via direct implementation on Google

web-sites and Chrome

 Servers: Google Prototype Server / LibQUIC  Now being standardized as HTTP/3

 https://www.zdnet.com/article/http-over-quic-to-be-renamed-http3/

Why did id Go Google gle do th this? s?

 Layering great for modularity, but what about performance?

 Done historically with layer violation

Portland State University CS 430P/530 Internet, Web & Cloud Systems

$BROWSER HTTP/1.1 TLS 1.2 TCP IP

Physical Network

google.com ??? User-perceived latency Chrome HTTP/2 Launch your

• wn browser

Update HTTP Google CDN Build a carrier-grade network google.com

From m HTTP P to QU QUIC

 Congestion control, reliability, encryption, and some HTTP/2 move

to QUIC

QU QUIC Fea eatures tures

 Collapses the stack and eliminates layering

 A single protocol spanning 3 layers  HTTP being used as the new carrier protocol for all network apps (the

new waistline!)

 But supports,

 Multiplexed streams and object-level demultiplexing (e.g. HTTP/2)  0-RTT connections with encryption (TLS 1.3)  Reliability over UDP  Forward error correction to handle lossy wireless links  Connection migration with IP address change  Pluggable congestion control (including TCP Cubic, BBR)

0 Round und-Trip rips: s: QU QUIC vs.

• s. TCP+T

P+TLS LS

 First connection

 TCP with TLS: TCP + certificate exchange/validation (3 RTTs)  QUIC: 1RTT for all (TLS 1.3)

 Subsequent connections

 TCP with TLS: Add TLS restart (2 RTT)  QUIC: 0 RTT for all (TLS 1.3)

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Mu Mult ltipl iplexed ed str treams: eams: QU QUIC IC vs. . SPD PDY/HTTP2 Y/HTTP2

(on packet t loss ss)

HT HTTP 1.0 QUIC

QU QUIC - Connection nnections

 UDP with encrypted and authenticated packets

 Prevents active attacks and middlebox changes (NAPT) unlike TCP

 Connection UUID (64-bit) to identify connections

 Used instead of TCP/IP 5-tuple  Connections decoupled from IP addresses to survive going from WiFi to

LTE

 Congestion control

 Implemented into application layer (i.e. user-space)  Window remembered by the client for reestablished connections

Es Esta tablis blishing hing a QU QUIC Connection nnection

 HTTP response header

 Alternate-Protocol: 443:quic

 Client establishes QUIC connection in the

background

 Clients can cache if server supports QUIC

to avoid subsequent negotiation

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Client Server

QUIC Connetion

HTTP QUIC

Alternate-Protocol:

QU QUIC Per erformance

• rmance

 5% latency reduction on average  30% reduction in rebuffers (video pauses) on

YouTube

 1 second faster at the 99th percentile for Google web search  Helps more for higher latency networks

 Example: Cellular/wireless hops

 https://eng.uber.com/employing-quic-protocol/

De Deplo ployment yment at t Go Google gle

 100% of all Android/Chrome to

YouTube traffic

 Now about 50-50 QUIC (UDP)/TCP

QUIC HTTP/2, TCP HTTP 1.1, TCP

QU QUIC in Chrome

• me

 Write network traffic to disk and upload to utility

 chrome://net-export/  https:/netlog-viewer.appspot.com/

Portland State University CS 430P/530 Internet, Web & Cloud Systems

QU QUIC in Wireshark eshark

 HTTP/3 = QUIC (11/2018)

 https://www.zdnet.com/article/http-over-quic-to-be-renamed-

http3/

 Now everywhere…(9/2019)

 https://www.zdnet.com/article/cloudflare-google-chrome-and-

firefox-add-http3-support/

DNS

Do Doma main in Name me Syst stem em (DN DNS) S)

 Internet hosts, routers like to use fixed-length addresses (numbers)

 IP address (32 bit) - used for addressing datagrams

 Humans like to use variable-length names

 www.cs.pdx.edu  keywords

 DNS, keywords, naming protocols

 Map names to numbers (IP addresses)

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Or Origi ginal nal Name me to Address dress Mappi pping ng

 Flat namespace

 /etc/hosts.txt  SRI kept main copy  Downloaded regularly

 Problems

 Count of hosts was increasing

 From machine per domain to machine per user

 Many more downloads of hosts.txt  Many more updates of hosts.txt

Portland State University CS 430P/530 Internet, Web & Cloud Systems

DN DNS: S: Do Doma main in Name me Syst stem em (1984) 4)

 Application-layer protocol used to resolve names

 Name to IP address translation  Core Internet function, implemented as application-layer protocol

 Complexity at network’s “edge”

 Distributed database implemented in a hierarchy of many name

servers

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Go Goals als

 Scalability  Decentralized maintenance  Fault-tolerance  Global scope

 Names mean the same thing everywhere

 Don’t need

 Atomicity  Strong consistency

Portland State University CS 430P/530 Internet, Web & Cloud Systems

DNS NS hiera erarchic chical al ca canonical

• nical nam

ame space ace

 www.cs.pdx.edu

Portland State University CS 430P/530 Internet, Web & Cloud Systems

root edu net

• rg

uk com ca gwu ucb pdx bu mit cs ece www

High gh-le level el view w of DN DNS

 Client-side

 Resolver  Local name server

 Server-side

 Root name servers  Top-level name servers  Authoritative name servers

Portland State University CS 430P/530 Internet, Web & Cloud Systems

resolver on requesting host "local" DNS server

pdx.edu, 1.1.1.1, 8.8.8.8, etc.

Clie ient re nt reso solver er

 Code on client to query DNS hierarchy

 Resolver configuration /etc/nsswitch.conf  Local name servers to use specified in /etc/resolv.conf

 Hand-configured or automatically configured (DHCP)

 Host queries local name server for unknown names  Or now…built-in to browsers and applications

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Local cal name me se server er

 When a resolver makes a DNS query, query is sent to its local name

server

 Each ISP/company/university typically has one

 Or public ones may be used

 Google (8.8.8.8)  Cloudflare (1.1.1.1)  OpenDNS (208.67.222.222) - supports filtered access

 Does not strictly belong to the hierarchy

 Acts as a proxy  Returns reply if cached  Forwards query into hierarchy if not

 Each local name server has addresses of root servers

 Hard-coded IP addresses in all name server distributions  Currently {a-m}.root-servers.net

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Server ers s organized anized hierar ierarchicall chically y mirr rroring ring name sp space ce

Client-side wants IP for www.amazon.com; 1st approx:

 Queries root to find com a root server to find com TLD server  Queries com TLD to find authoritative amazon.com server  Queries amazon.com authoritative server to get IP address for www.amazon.com

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Root servers com TLD servers

• rg TLD servers

edu TLD servers pdx.edu auth servers umass.edu auth servers yahoo.com auth servers amazon.com auth servers pbs.org auth servers

Root t name me se server ers

 13 hard-coded root name servers worldwide for fault-tolerance

 All that fit in a 512 octet SOA record

 Contacted by local name server that can not resolve name  Contains authoritative name servers of all top-level domains (i.e.

levels immediately below)

Portland State University CS 430P/530 Internet, Web & Cloud Systems

b USC-ISI Marina del Rey, CA l ICANN Los Angeles, CA e NASA Mt View, CA f Internet Software C. Palo Alto,

CA (and 17 other locations)

i Autonomica, Stockholm (plus 3

• ther locations)

k RIPE London (also Amsterdam, Frankfurt) m WIDE Tokyo a Verisign, Dulles, VA c Cogent, Herndon, VA (also Los Angeles) d U Maryland College Park, MD g US DoD Vienna, VA h ARL Aberdeen, MD

j Verisign, ( 11 locations)

Top-le level el doma main in (TLD) D) name me se server ers

 Responsible for com, org, net, edu, etc, and all top-level

country domains uk, fr, ca, jp.

 Network Solutions maintains servers for .com TLD  Educause for .edu TLD

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Aut uthoritati

• ritative

e name me se server ers

 Implements part of the distributed database  Provides authoritative hostname to IP mappings for a domain

 e.g. pdx.edu authoritative name server provides names for

media.pdx.edu , d2l.pdx.edu , www.pdx.edu , mail.pdx.edu

 Maintained by organization or service provider

 pdx.edu managed by Portland State  oregonctf.org managed by me (via Google)

 Authorities at every level of hierarchy

 Root name servers are authorities for TLD name servers

 Root servers deliver authority for ".edu" TLD

 TLD name servers are authorities for their own subdomains

 ".edu" TLD server delivers authority for "pdx.edu" name

 PSU name servers are authorities for their subdomains

 ".pdx.edu" authority delivers "cs.pdx.edu" names

Portland State University CS 430P/530 Internet, Web & Cloud Systems

DN DNS S rec ecord d ty type pes

 DNS: distributed db storing resource records (RR)  Type=A

 name is hostname  value is IP address or a list of IP addresses

 Type=MX

 name is domain (e.g. foo.com)  value is name of mail server associated with name

 Type=CNAME

 name is alias name for some “canonical” (the real) name

 www.ibm.com is really servereast.backup2.ibm.com  value is canonical name

 Type=NS

 name is domain (e.g. foo.com)

 value is hostname of authoritative name server for this domain (who owns

the name)

 Implement the "links" in the naming hierarchy

Portland State University CS 430P/530 Internet, Web & Cloud Systems

RR format: (name, value, type, ttl)

DN DNS S que uery y ty type pes

Recursive

 Puts burden of name resolution on contacted name server  Only returns answer or “not found”  Leads to heavy load

 Root servers disable recursive querying through them

Iterative

 Contacted server replies with name of server to contact  “I don’t know this name, but ask this server”  Client iteratively queries

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Rec ecur ursi sive e que uery y exa xample ple

Portland State University CS 430P/530 Internet, Web & Cloud Systems

requesting host

mashimaro.cs.pdx.edu

• regonctf.org

root DNS server local DNS server

pdx.edu

1 2

authoritative DNS server dns1.oregonctf.org

8 .org TLD DNS server 4 5 6 3 7

requesting host

mashimaro.cs.pdx.edu

• regonctf.org

root DNS server local DNS server

pdx.edu

1 2 3 4 5

authoritative DNS server dns1.oregonctf.org

8 6 7 .org TLD DNS server

Itera erativ tive e que uery y exa xample ple

 Resolving A record of oregonctf.org  Resolver contacts local server recursively (1)  Local server queries root server iteratively

for oregonctf.org (2)

 Root server returns NS record for .org TLD

server (3)

 Local server queries TLD server iteratively

for oregonctf.org (4)

 TLD server returns NS record for

• regonctf.org (5)

 Local server queries authoratative server

iteratively for oregonctf.org (6)

 Authoritative server returns A record for

• regonctf.org (7)

 Can return multiple addresses

 Local server returns A record to client (8)

Portland State University CS 430P/530 Internet, Web & Cloud Systems

DN DNS: S: cachin ching g and nd up updating ating reco ecords ds

 DNS responses cached throughout hierarchy

 Reuse parts of lookup to decrease load (e.g. google.com, TLD servers)

 Thus, root name servers not often visited

 Entries timeout after some time (soft state)

 TTL field controlled by authority  Affects DNS-based load balancing

 Negative responses also cached

 Don’t repeat past mistakes (misspellings)

Portland State University CS 430P/530 Internet, Web & Cloud Systems

DN DNS S Lookup up Cachin ching g Ex Example ple

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Client Local DNS server root & edu DNS server pdx.edu DNS server

www.cs.pdx.edu?

cs.pdx.edu DNS server

NS pdx.edu NS cs.pdx.edu A www is IPaddr

Sub ubseq sequent uent Lookup up Ex Example ple

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Client Local DNS server root & edu DNS server pdx.edu DNS server cs.pdx.edu DNS server

mashimaro.cs.pdx.edu (cs.pdx.edu NS entry cached) NS pdx.edu NS cs.pdx.edu A www is IPaddr

DN DNS S pr protocol,

• col, me

mess ssages ges

 Unified format for request and response messages

 16 bit identification # for request, response uses same #  Flags specify

 query or reply  reply is authoritative

 Can use either TCP or UDP

Portland State University CS 430P/530 Internet, Web & Cloud Systems

DN DNS S dig g exa xample ple

 dig examples to demonstrate iterative and recursive queries

# local DNS server cat /etc/resolv.conf # List root servers dig # Find IP address of F root server dig f.root-servers.net # do an iterative query to IP addr of F root dig @192.5.5.241 +norecurse +tcp www.thefengs.com. # do an iterative query to IP addr of L TLD dig @192.41.162.30 +norecurse +tcp www.thefengs.com. # do an iterative query to IP addr of NS at googledomains dig @216.239.32.106 +norecurse +tcp www.thefengs.com. # do an iterative query to local DNS server dig +norecurse www.thefengs.com. # now do a recursive query through local DNS server dig +recurse www.thefengs.com.

DN DNS S rever erse se lookups ups

 Given an IP address, find its name

 Done via PTR record type, reversing the IP address, and using a special

domain .in-addr.arpa

 dig -t PTR 66.220.250.131.in-addr.arpa  (or dig -x 131.252.220.66)

 Root servers refer domain (in-addr.arpa) to Regional Internet

Registry

 Associated with IP address ranges (ARIN for US, RIPE for EU)  Registry forwards to DNS server of organization originally given the

range (e.g. PSU for 131.252.x.x)

 Note: Hosting other domains within PSU (e.g. oregonctf.org)

will not appear in reverse lookup

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Sett etting ing up up your ur own wn domain main

 Register name oregonctf.org at a registrar (e.g., Google

Domains)

 Give registrar names and IP addresses of your authoritative name server  Registrar inserts two RRs into the org TLD server

 Name of the authoritative server of the domain

(oregonctf.org, dns1.oregonctf.org, NS)

 IP address associated with the authoritative server

(dns1.oregonctf.org, 131.252.220.66, A)

 Set up authoritative server at 131.252.220.66

 Install DNS server (BIND)  Enter A record for oregonctf.org  Enter MX record for oregonctf.org

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Or…

 Let Google run DNS and configure via web  Demo

Portland State University CS 430P/530 Internet, Web & Cloud Systems

DN DNS S iss ssue ue #1

 Amplification attacks

 DNS query typically < 512 bytes  DNS response can be 65 kB  UDP packets fire & forget with IP addresses easily forged (unless BCP38

filtering done)

 UDP largely filtered by CAT (aside from QUIC now)...

Portland State University CS 430P/530 Internet, Web & Cloud Systems

DN DNS S iss ssue ue #2

 DNS cache poisoning attack

 Minimal authentication done on responses (16-bit ID field)  Adversary can blindly guess and spoof answers especially with UDP  Adversary can attack DNS servers directly to redirect victims elsewhere

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Ex Example ple

 Example: MyEtherWallet.com (MEW)  Lots of $, enormous target for exploitation (4/2018)

Portland State University CS 430P/530 Internet, Web & Cloud Systems

 MEW using AWS Route 53 to provide DNS

 BGP hijack from ISP in Ohio

 Adversary advertises a more specific route to AWS Route 53 DNS (/24)

 Redirects DNS to point to fake web servers in Russia that impersonate MEW  Captures credentials of users  Note: Fake web servers had a self-signed TLS cert impact limited.

 But, could have easily used Let's Encrypt…

Portland State University CS 430P/530 Internet, Web & Cloud Systems

https://blog.cloudflare.com/bgp-leaks-and-crypto-currencies/

Typi pical cal ope peraion aion

Portland State University CS 430P/530 Internet, Web & Cloud Systems

https://blog.cloudflare.com/bgp-leaks-and-crypto-currencies/

Hijack jacked ed ope perat ration ion

Portland State University CS 430P/530 Internet, Web & Cloud Systems

 Prevention via DNSSEC

 Certificates for DNS records  Not often checked by browsers unfortunately

Portland State University CS 430P/530 Internet, Web & Cloud Systems

DN DNS S iss ssue ue #3

 Queries not encrypted

 Adversary on same network can monitor all requests  https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-over-

https/

Portland State University CS 430P/530 Internet, Web & Cloud Systems

 Prevention via DNS over HTTPs (encryption for DNS

requests/responses)

 Secures connection between resolver and local name server  Encrypts request while removing MITM attacks  Working its way through IETF as DoH!



https://github.com/curl/curl/wiki/DNS-over-HTTPS

Portland State University CS 430P/530 Internet, Web & Cloud Systems

{"Status": 0, "TC": false, "RD": true, "RA": true, "AD": true, "CD": false, "Question":[{"name": "thefengs.com.", "type": 1}], "Answer":[{"name": "thefengs.com.", "type": 1, "TTL": 3600, "data": "131.252.220.66"}]} curl 'https://1.1.1.1/dns-query?ct=application/dns-json&name=thefengs.com&type=A'

 But, why not DNS over TLS? (DoT)

 80 (http) to 443 (https)  53 (dns) to 853 (DoT)  Separate web requests and DNS requests (good or bad?)

 The DoH vs DoT battle

 DoT: allows network operators and IT to more easily classify requests

and detect abuse (good for operators), but easily filtered!

 DoH: prevents a hostile government from easily blocking encrypted

DNS (good for users, activists)

 Must block https to eliminate encrypted DNS!  https://www.wired.com/story/dns-over-https-encrypted-web/

Portland State University CS 430P/530 Internet, Web & Cloud Systems