- Ties your MAC address to an internet routable address
- Finds other devices residing within your subnet via broadcasts
- Defines the mechanism for connecting two hosts together
- Source IP Address and Port
- Destination IP Address and Port
- IP Protocol
- Routing
- Abstracts underlying network capabilities
- The packet has a header explaining where it's come from, where it's going to, and how long it's got to go before it abandons it's try.
- Any node on the route can rewrite the packet to hide the source or destination address (NAT) or port (PAT)
- If the packet's "Time To Live" expires, an ICMP message is sent back to the source
- To route a packet from one network to another, each host has a routing table specifying the next hop gateway
- Each step through the network resolves the MAC address of it's gateway via an ARP request broadcast
- When the address arrives at it's destination, it follows a return path using the same method
- Used to indicate routing and TCP/UDP issues
- TTL counter in ICMP is misused by traceroute
- Can notify you that a port or host is not responding
- Useful in LANs, not useful publicly
- Sending messages which guarantee acknowledgement
- Three Way Handshake (Syn, SynAck, Ack)
- Usually "Clean" termination (Reset or Fin, Ack)
- HTTP/HTTPS
- SSH
- FTP
- SMTP/POP3/IMAP
- XMPP
- IRC
- Sending low latency, non-guaranteed messages
- VoIP
- Skype
- Google Hangouts
- SIP
- Syslog
- DNS
- Used to resolve "Names" to IP Addresses
- www.example.org -> 192.0.2.1
- Also used to identify resources provided by that domain name
- A = IPv4 Address, AAAA = IPv6 Address
- MX records = Mail
- NS = Responsible name server
- CNAME = Alias
- TXT = Other text
- Your machine has a list of DNS servers it talks to
- It asks all those servers to retrieve the record for a given name
- If that DNS server doesn't know it, it asks the root servers for the TLD NS
- It then asks the TLD NS for the domain name NS
- It then asks the domain name NS for the subdomain NS or record etc.
- Originally used to transfer Hyper Text Markup Language files to clients, now used as a general purpose transfer protocol for:
- HTML, Text, Images, Javascript
- JSON, XML, VPNs...
- Also provides LOLcats
- The HTTP request sends several headers:
- Host, User Agent, Encodings, Cookies, Last successful request of that page and an "etag"for it.
- Then a VERB request
- GET, PUT, POST, DELETE
- Then the URI it wants
- Server replies with headers of it's own
- Response code (200, 404, etc), Length of response, last modified, etag for the page
- Then the content of the URI, or verbose errors
- 404 File not found
- 302/307 redirect
- 401 authentication required
- Previous versions were called SSL. This is now depreciated.
- TLS provides you with an encrypted tunnel over which you can pass lots of TCP or UDP protocols
- These tunnels can be authenticated by the use of Certificate Authorities, or Trust On First Use (TOFU)
- Most commonly as the "S" in HTTPS
- FTP/S
- OpenVPN
- Tor
- SIP (using DTLS)
- Client starts by sending the highest version of TLS it supports, a random number, ciphers it supports
- Server replies confirming the TLS version it supports, a random number, and says which cipher it picked from the list supplied by the client
- It also sends it's certificate.
- Assuming the server and client agree, and the certificate is acceptable (matches the DNS name or overriden) then...
- Client encrypts a Pre-Master-Secret with the Server's public key, which was in the Certificate
- Client and Server use
CRYPTOGRAPHYto create the Master Secret from the data exchanged already
- Client encrypts the FINISHED mssage with the Master Secret, hashes the result and signs the hash
- Server decrypts this, returns it's own encrypted, signed and hashed FINISHED message.
- Data is now sent encrypted using whatever new protocol they want to layer over the top.
Abridged version of: https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake
- Originally designed as a secure replacement for the existing remote shell tools (rsh, telnet)
- It now also permits file transfers, port forwarding, carrying forward keys for onward connections and even has a built-in VPN!
- You can mount an SFTP location into your Linux File System with SSHFS
- Transport layer establishes a TOFU TLS-Like tunnel, without a CA chain
- User authentication layer confirms credentials
- Password (also referred to as keyboard-interactive)
- Public Key (RSA/DSA/x509)
- Connection Layer provides the shell, port forwarding and execution of any commands
- To provide an authenticated tunnel between
- Network-to-Network
- Host-to-Network
- Optionally, also to encrypt that tunnel
- There are technically two modes, AH and ESP
- AH (Authentication Header) provides authentication of origin and prevents replay attacks
- ESP (Encapsulation Security Payloads) adds encryption to the tunnel.
- These both rely on IKE (Internet Key Exchange) to define the SA (Security Association) that the AH or ESP modes use
- IKE operates on UDP 500 or 4500 and starts by initializing a Diffie-Hellman key exchange to create a shared key
- This key is used to create the Phase 1 SA, that is then authenticated with either a shared secret or x509 Certificates
- The SA is also encrypted with a designated cipher and hashing algorithm
- A Phase 2 SA is created for AH or ESP using the Phase 1 SA
- AH adds a sequence number to an existing IP packet, as well as the Phase 2 SA and Destination IP address
- ESP encrypts an entire IPv4 or IPv6 packet using the values from the IKE Phase 2 SA, adds the ESP headers and a hash to confirm it's not been modified in transit
Abridged version of: https://en.wikipedia.org/wiki/Internet_Key_Exchange and https://en.wikipedia.org/wiki/IPsec
- Provides simple authentication using non-token authenticators
Um... Wait for the next protocol
- Take a shared secret key, add a counter, SHA1 both, truncate it to 4 bytes (6 digits), compare to the server
- If you've already seen that HOTP value, reject it as used.
- Increment and store the counter if it is an exact match
- Provides simple authentication using non-token authenticators (again)
- Google Authenticator
- Dropbox
- Github
- And lots, lots, lots more
- Pretty much the same as last time, but...
- Take a shared secret key, add the current unix epoch timestamp divided by the "timestep", SHA1 both, truncate it to 4 bytes (6 digits), compare to the server
- If you've already seen that TOTP value or it isn't more recent than the last known timestamp, reject it as used.
- The server calculates a number of "windows" either side of the current timestamp, if it matches one of those, store that timestamp as the last used.
- Provides simple TWO FACTOR authentication using non-token authenticators
- Battle.net
- Pretty much the same as last time again, but...
- Enter a shared secret key (as a PIN), add the current unix epoch timestamp divided by the "timestep", SHA1 both, truncate it to 4 bytes (6 digits), compare to the server
- If you've already seen that M/OTP value or it isn't more recent than the last known timestamp, reject it as used.
- The server calculates a number of "windows" either side of the current timestamp, if it matches one of those, store that timestamp as the last used.
- Provides a one-click, single factor authenticator to web applications
- No where yet, it's not yet released properly (should be out within 3 months ish)
- You can see the current status at http://grc.com/sqrl
- Server provides a link using the SQRL:// prefix including a "Nonce"
- Client calculates a site-specific Private Key based on local key material on their device
- Client sends the calculated public key over HTTPS and signs the Nonce with their calculated private key
- Server stores the public key as authentication material
Abridged version of http://sqrl.pl/guide