SystemsSec 2018W Lecture 8: Difference between revisions
No edit summary |
No edit summary |
||
(2 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
==Audio== | |||
[http://homeostasis.scs.carleton.ca/~soma/systemssec-2018w/lectures/comp4108-2018w-lec08-31Jan2018.m4a Lecture 8 Audio] | |||
==Notes== | |||
<!> Reminder to complete the experiences on time (before March 26th) | <!> Reminder to complete the experiences on time (before March 26th) | ||
== | ===The IP packet=== | ||
The basis of the internet | |||
If you want to connect to the internet all you need to be able to do is send/receive packets to someone who is connected to the internet. Everyone along the line can forward or pass along packets. What about ethernet and wifi? It’s just ways of sending packets | If you want to connect to the internet all you need to be able to do is send/receive packets to someone who is connected to the internet. Everyone along the line can forward or pass along packets. What about ethernet and wifi? It’s just ways of sending packets | ||
What's in an IP packet? | |||
Data structure | Data structure | ||
:Header | :Header | ||
Line 20: | Line 27: | ||
<blockquote>''Note: Packets are unprotected! There’s no confidentiality, it’s all in the open. Everyone who touches it on the way gets to see (or change!) the entire packet. Example; NAT is changing the source and destination packets!''</blockquote> | <blockquote>''Note: Packets are unprotected! There’s no confidentiality, it’s all in the open. Everyone who touches it on the way gets to see (or change!) the entire packet. Example; NAT is changing the source and destination packets!''</blockquote> | ||
=== | ===Securing IP packets=== | ||
IP packets on their own have no security, and this isn't a simple oversight. Packet-level security is hard. | |||
How would you secure it? Certain fundamental problems about locking this down. What attacks can you perform on a set of IP packets? | |||
; Eavesdropping | ; Eavesdropping | ||
: '''Δ''' You can only encrypt the payload! | : '''Δ''' You can only encrypt the payload! | ||
Line 33: | Line 43: | ||
'''Δ''' You can use a trusted intermediary service | '''Δ''' You can use a trusted intermediary service | ||
Δ Can also use onion routing (Tor) at the cost of speed | |||
'''Δ''' Can also use onion routing (Tor) at the cost of speed | |||
It’s not that the designers weren’t smart, it’s that their decision had to factor in a tradeoff between functionality and security costs. | It’s not that the designers weren’t smart, it’s that their decision had to factor in a tradeoff between functionality and security costs. | ||
=== Key management === | === Key management === |
Latest revision as of 19:10, 31 January 2018
Audio
Notes
<!> Reminder to complete the experiences on time (before March 26th)
The IP packet
The basis of the internet
If you want to connect to the internet all you need to be able to do is send/receive packets to someone who is connected to the internet. Everyone along the line can forward or pass along packets. What about ethernet and wifi? It’s just ways of sending packets
What's in an IP packet?
Data structure
- Header
- Source IP
- Destination IP
- Checksum
- Etc.
- Payload
Most important fields are the source IP address and the destination IP address
Note: Packets are unprotected! There’s no confidentiality, it’s all in the open. Everyone who touches it on the way gets to see (or change!) the entire packet. Example; NAT is changing the source and destination packets!
Securing IP packets
IP packets on their own have no security, and this isn't a simple oversight. Packet-level security is hard.
How would you secure it? Certain fundamental problems about locking this down. What attacks can you perform on a set of IP packets?
- Eavesdropping
- Δ You can only encrypt the payload!
- Traffic analysis; rate of traffic, who’s talking to who, when they’re talking
- The only way to prevent traffic analysis is to encrypt the header and mask it
- Pizza delivery attack
- Let’s say you’re a military organization, and you want to plan an attack but your employees are staying late? Oh look they ordered a pizza late at night, so now you have to order pizza all the time, keep the parking lot full, etc.
Δ You can use a trusted intermediary service
Δ Can also use onion routing (Tor) at the cost of speed
It’s not that the designers weren’t smart, it’s that their decision had to factor in a tradeoff between functionality and security costs.
Key management
You're going to send these packets to arbitrary other machines. Let’s assume you're going to do proper security (authentication, encrypt, etc..), you need to be able to identify the destination, you need their public key.
- Where do I get the key?
- Domain name system (DNS).
The DNS maps Hostnames to IP addresses. Every domain name technically ends with a ‘.’ which is defined as the root, from there it goes down a level to com, and again down to something like google, etc..
DNS is a bunch of public records, there’s no cryptographic protection in DNS. If you wanted to do that you would have to encrypt the entire mappings. Who would you trust to do that? Who has the authority to manage this? DNSSEC is an attempt to solve this and is currently being deployed but from a management’s perspective it is painful.
What protocols would we use to securely communicate? TLS/SSH, but this would only work for the payload. It gives us end-to-end protection, except that everyone can see that those two endpoints are communicating.
Δ There is a VOIP attack, in which you can figure out the words being said simply by examining the size of the packets being sent.
What does a VPN give you?
Δ What part of the traffic is encrypted and how is it authenticated? With a VPN the whole packet is being encrypted, but it’s encapsulated in another header directed to the VPN gateway. Anyone observing your traffic would only see communication between you and the gateway.
All you’ve done is move the problem, so why use it? It can help you against attackers close to you in the network space. If they have to compromise a VPN system further away that’s better maintained, it can (in principle) be harder to compromise.
What is your path of trust?
You cannot trust hostnames because DNS can be messed with. You can’t trust IP address as those can be changed. You can only trust the encryption in the payload.
How do you authenticate to a classic website?
Download a certificate and it is vouched for by a built-in authority. But how does the site authenticate with you? You can have a public key (and a private key) to identify yourself to the organization. Example is the Yubikey; an external thumb drive to store your key.
Why not give everyone a key pair?
Hard to explain it to the everyone, and what happens when the cryptography becomes obsolete.
At the end of the day, we can only really work with end-to-end and secure it on either end and hope that both ends are the correct ends.