- TLS packet format
- When doing TLS, we are encrypting payload but not all layers
- TCP allows us to have a protocol that gives us packets in order. Within TCP header and protocol:
- TCP delivered as payload of IP
- TCP makes sure packets are in order
- For every packet we send we expect to get acknowledgement back—ie. reliable delivery (we know whether arrived or not)
- Underneath TCP is TLS protocol
- TLS information is delivered as payload of TCP
- Gray part (TLS) includes encrypted data, MAC, padding, etc
- If conducted traffic analysis (solved a bunch of encrypted packets on the internet) could learn a lot since not everything is encrypted…
- Source and destination address: which IP is talking to who (source and destination address)
- If source IP is rare, could leak a lot of info
- If source IP is not rare, like Google’s, that might not tell you as much
- Port: what protocol they’re speaking
- Size of individual packets and number of packets going to particular source destination exposed. TLS does not pad packets to constant length
- How often packets are being sent
- Timing and length (eg. Skype – can see when people are talking and listening à who is talking more)
- Cumulative distribution function: x axis is packet length, y packet is how frequently we see those on internet
- Metadata that leaks from traffic is very poorly protected by law
- Zero protection under the law for metadata
- No warrants required to get this info
- No reasonable expectation of privacy
- Thus, we should question how much protection we really get from encryption – it is not the end solution
- How networks work
- Layers
- TCP being sent over IP
- TLS being sent over TCP
- HTTP being sent over TLS
- Link by link communication done over IP
- TCP controls flow of traffic from sender to receiver (intermediate routers don’t care about TCP, just end routers)
- TLS runs on top of TCP (end to end from client to server)
- TCP gives pipe, TLS encrypts pipe
- IPSEC was supposed to do encryption between routers
- IPSEC encrypts individual pipes, not the ones from sender to receiver
- Can also use in tunneling mode
- UDP (User Data Protocol) vs. TCP
- Two different ways of doing transport on the internet (vanilla and chocolate)
- UDP very simple (vanilla)
- No handshake
- Can just send packets with IP
- Unreliable transport on top of IP
- Source port, destination port, length, and cksum
- Cksum not secure because only 16 bits and also because algorithm is public
- Just send packets—doesn’t care whether they arrive or not
- Eg. Watching a video or talking on the phone- quality alternates between good and bad. When bad, those are dropped packets. Don’t want the dropped packets to come back a few minutes later
- TCP is a lot more complicated (chocolate)
- We’ve learned about this process
- Thus, in settings when you want to make sure you get all info and delays are okay use TCP. In settings when you can lose packets, but not have delays use UDP
- UDP Vulnerable to DoS Reflection & Amplication Attack
- Exploits the fact that UDP so simple
- Off path attack
- Sever: DNS is a protocol sent over UDP
- Sends DNS query that is short
- Illicit DNS response that is long because could be DNSSEC
- Tom’s source IP to Google public DNS
- How attack works
- Botnet of attacker sends packets to target
- Bit rate of what attacker sends is much smaller than what is hitting the victim (amount of work attacker has to do is much smaller than what the victim receives… because using public DNS server to enlarge packets)
- Victim will go down
- Another eg. Using monlist packets
- Can’t do this for TCP
- Source IP spoofing happening with UDP—this can’t happen in TCP
- In TCP
- Want to send packet that says “I’m Tom, please send me your monlist.”
- If queries were being sent over TCP, would have to do syn, then syn-ack, then ack to send the query. If I spoofed toms source ID in my syn, the message will go to tom and he will ignore it, so the server won’t get the ack. Can’t see what the server sent to tom in syn-ack.
- Breakdown of TCP handshake
- If sequence numbers were predictable: the attack would say (syn) “I’m Tom” –> (syn-ack) goes to Tom –> (ack) “I’m Tom and the sequence numbers are 0s, monlist” à Tom is hit with monlist
- This fails with TCP because of the sequence number and acknowledgement number that is in TCP packet and (both 32 bit random numbers)
- When I send the syn, I put a sequence number that is random and the acknowledgement number field is blank
- Server will store both numbers. Sequence number from syn will get copied into acknowledgement number in syn-ack. New random number for sequence in syn-ack
- When receiver gets response, he is going to take sequence number from syn-ack and put it in acknowledgement number. Sequence number for the next packet is +1
- This thwarts reflection attack because attacker doesn’t know what sequence number the server generated since it went to Tom (victim) not me (attacker)
- Thus, random sequence numbers in TCP prevent off path attacks
- Can inject things but they won’t be accepted because sequence number will be wrong
- Need crypto to prevent man in the middle
- So why doesn’t UDP use a handshake like TCP?
- Latency (delay) would incur more if used handshake every time sent packet
- Would be much slower
- DNS (have to learn IP address when you visit website. DNS lookup of domain name done over UDP)
- Great Firewall of China on TCP
- TCP connection formalities: opened with syn, syn-ack, ack and closed with fin, fin-ack, ack
- If something goes wrong for the three message handshake closing, you can just close connection with single packet (reset packet)
- Reset packet only accepted if sequence number sensible
- For off path attacker to close connection, would have to guess sequence and acknowledgement numbers to be sensible (not too far off)
- For on path attacker (sitting there reading traffic slowly and if sees something decides to take action) to close connection, doesn’t drop/intercept/tamper packets, just adds the reset packet
- This is sent to client and server, and they will think the server or client closed the connection. Connection will be closed and there will be no more communication. This is a classic way to do censorship with TCP
- Thus, can stop delivery of communication in the middle by using reset packet for on path
- Attacker needs to learn two things from the packets: sequence and acknowledgement numbers and then inject reset that has sensible sequence and acknowledgement
- Layers and ARP
- Link layer
- Machines have built in MAC addresses
- IP address changes depending on which network you’re on, constantly changing
- Mapping being done on link layer between permanent address (MAC) and short-term address (IP)
- If I have IP and MAC, and I want to let everybody else know what my addresses are, use protocol ARP: Address Resolution Protocol
- Computer wants to reach printer (knows IP address of printer), but actually have to connect to it. Make local area connection by sending broadcast message that says “who has this IP address?” in ARP. Printer responds: “IP address belongs to me, here is my MAC address”
- None of this authentication, MACed, signed
- ARP spoofing/poisoning attack: broadcast to the entire room, and anyone can answer. Attacker will cheat and say he has the IP address even though he doesn’t. Both attacker and legit will send responses – race condition to see who gets there first.
- Can be used to make yourself the man in the middle: need to get to router that will connect you to local internet. Pretend to be access point to read all local traffic
- 168.01 for router – claim to be router – victim’s computer will think that router is attacker’s computer, so all traffic will be sent to it. Attacker knows actual MAC of router, so can adjust packets and then send them to the real router