EECS388 MIDTERM
Certificate
- A message asserting the server's identity & its public key, signed by certificate authority (CA) - Similar to driver's license (expires, may need to replace) - TLS uses X.509 certificate format
Reading a cookie
- A site can read cookies set for its own domain or any parent domains
Padding
- Add bytes to end of message to make it a multiple of block size - Good approach: PKCS7 (add n bytes of value n). Ensures user can unambiguously distinguish padding from message after decrypting - Edge case: message that ends @ block boundary? Add entire block of padding
Cipher Modes
- Algorithms for applying block ciphers to more than one block (ie Cipher-block Chaining CBC) - Most trivial mode: A flawed approach would be Encrypted Code Book (ECB) mode
Certificate Authority (CA)
- An entity trusted by clients to verify identities & issue certificates - Can do 2 things: 1) Issue certificates to websites vouching for their domain name 2) Issue certificates to other entities delegating their CA privileges to intermediate CA
Drive-By Pharming
- Attacker has imbedded image (send GET request for image from local IP address that usually your router is on) - Attacker cannot see image, but can tell if request succeeded - "Yes or No" allows attacker to figure out router IP
CSRF via POST Request
- Attacker triggers a POST request using HTML & JS - Write script w/ proper POST method & send it to Bank.com - Cannot read AuthToken or POST response, but money is still gone
Cross Site Scripting (XSS)
- Attackers exploit sites that send untrusted inputs to browser w/o proper validation or sanitation - 2 Types: Reflected XSS & Stored XSS
Homographs
- Attacks that uses visually similar domain to trick users - Simple, but effective - Attacker buys look-alike domain & acquires a legitimate certificate, then set up phishing site
ACME
- Automatic Certificate Management Environment - Open protocol created by Let's Encrypt - Automates the processes of validation of server's identity (check control of domain) - Email verification - HTTP -- place file w/ confirmation code @ specified URL on domain - DNS -- add record containing confirmation code to domain's DNS zone
Diffie-Hellman (D-H) Key Exchange
- Birth of modern cryptography - Idea: could have open conversation & by the end of the conversation we know a know that no one else will know - Passive eavesdropper: fails (would take exponential time) - Man in the Middle Attack: Alice & Bob each shared their secrets w/ Mallory rather than each other. Mallory can eavesdrop & modify the messages unknowingly to A & B.
Public-key Crypto
- Breakthrough: keys can be distinct - Different keys to sign & verify messages
Fooling CA Validation
- CA convinced by attacker that they control a domain, they can then obtain certificate & fool browsers - Attack 1 -- Email validation (ex. CA emails confirmation code to [email protected]) - Attack 2 -- HTTP validation (ex. MiTM between CA & U-M & redirects CA's GET to own site) - Mitigation -- domains can limit which CAs issue certs for them by creating DNS record called Certification Authority Authorization (CAA), prohibit uses creating certain emails, & multi-perspective validation making MiTM attacks more difficult
Mitigating attacks on CAs
- CAs can revoke certs by adding them to a Certification Revocation List (CRL) - Browser companies crawl CRLs & push updates to users - Certificate Transparency
Certificate Transparency
- CAs must record every cert they issue in a public ledger, called Certificate Transparency (CT) log - Servers can monitor CT logs & detect if any CA issues improper cert for their names - Can monitor for certificates being issued for their domain name that they didn't request
Certificate Chains
- CAs sometimes issue intermediate CA certificates, which lend permission to sign further certificates - Delegate trust to other CAs - Use separate key for issuing certificates from long-term root key stored offline - Servers provide a certificate chain - Client verifies signature in each link, back to a trusted root CA in its root store
Facts about RSA
- Can be used for confidentiality, integrity, &/or authenticity - Confidentiality -- public-key encryption (A encrypts using B's public key, B decrypts using A's public key) - Integrity/sender authenticity -- digital signatures (A signs m using her private key, B verifies m,s using A's public key) - Both properties -- use both sets of key pairs & methods - RSA is over 1000x slower than AES
POST
- Can submit data; causes change or side-effect) - Get information only from here
Cipher-block Chaining (CBC)
- Chains cipher texts to obscure later blocks - Choose random initialization vector IV - Send IV w/ ciphertext - As long as initialization vector is different each time, we can reuse the key - Can't encrypt blocks in parallel (takes linear time) or out of order - Can't decrypt out of order
TLS assumes...
- Client & server are secure, but talking over malicious network - Passive (only eavesdrops) - Active (see, inject, modify, block)
Web Platform
- Collection of technologies developed as open standards that powers Websites & applications - Open: anyone can build Web browser or server, participate in standard design - Standards: URLs, HTML, JavaScript, HTTPS, TLS, etc.
CBC Padding Oracle
- Common flaw when using MAC-then-encrypt - Because decryption had to occur before checking MAC => couldn't tell if from a valid source or an attacker - Working backwards, attacker can unzip entire ciphertext - Attacker can provide whatever message as input & see which error (MAC or padding error) or differences in timing results - W/ clever modifications can get all of the plaintext - Not all CBCs are vulnerable, only those that violate Cryptographic Doom Principle
Merkle-Damgard construction
- Compression function - Message is sliced into 512-bit blocks - Input(256, 512) => Output(256 bits)
Hows TLS obtains confidentiality, integrity, & authentication:
- Confidentiality -- AEAD ciphers - Message Integrity -- AEAD ciphers - Authentication (of server by client) -- public key crypto & certificates
Browser sends all cookies in URL scope:
- Cookie-domain should URL domain or its parent - Cookie-path should be prefix of URL path - If protocol is https, cookie is secure
SOP: Cookies (Same-Origin Policy)
- Cookies use different scope than DOM - Scope based on ([scheme], domain*) -- complicated rules - Scheme is optional - Server can set "secure" attribute to limit cookies to HTTPS requests - Server can set HttpOnly attribute to prevent cookie from being accessed by DOM - A lot on the browsers to do the right thing - Set-cookie: id=a3fWa; Secure; HttpOnly;
Three Classic Web Attacks
- Cross-Site Request Forgery (CSRF) - SQL injection (SQLi) - Cross Site Scripting (XSS)
CSRF Attack
- Cross-Site Request Forgery attacks cause user's browser to perform unwanted actions on different site on user's behalf - Defend against CSRF using combination of secret validation tokens & SameSite Cookies
TLS (Transport Layer Security)
- Cryptographic protocol that is layered above TCP to ensure data security and integrity over public networks, such as the Internet - Commonly used w/ many application protocol: HTTP over TLS => HTTPS - If sending data over the internet => use TLS
SQL Injection
- Data changes meaning of SQL statements - Data becomes SQL code & is run on server side - Despite being easy to avoid, they are a common & dangerous mistake
Why use intermediate CA?
- Decreases risk of private keys being exposed - One intrusion would otherwise cost a software update of every browser in the world in order to change key
Block Ciphers
- Defines a permutation -Consist of function that encrypts fixed-size (n-bit) blocks w/ reuseable key - Inverse function that decrypts the blocks when used w/ same key - Can be inverted - Want a pseudorandom permutation (secure PRP is a function that cannot practically be distinguished from a truly random permutation w/o knowing k)
Encrypted Code Book (ECB
- Each block is encrypted independently - Leaks information about plaintext through cipher text (repeated text will have the same output)
Reflected XSS
- Echos script back to same user in context of site - Get user to send crafted JavaScript to server, server will echo back to me the browser's rendered script to run - Malicious code executes in site's origin - EX) attacker crafts URL containing malicious string. User clicks malicious URL link. User's browser interprets malicious JavaScript in server's response as part of legitimate web page & executes code. User's sensitive info is sent to attacker's server - PayPal 2021
Vigenere Cipher
- Encrypts successive letters using a sequence of Caesar ciphers keyed by the letters of the keyword - Use wheel to determine how far to shift each successive group of letters in plaintext - How to find n? One way is the Kasiski Method (repeated strings in long plaintext will sometimes be encrypted w/ same key letters
Same-Origin Policy
- Essential security question: When can one site access data contained in another site? - Browsers enforce isolation between site by applying Same-Origin Policy (SOP) - Separates content into different trust domains (origins) & restricts data flows between them - DOM scope: (scheme, host, port)
TSL Protocol Vulnerabilities
- Export-related -- basically prohibited exporting software that had cryptography stronger than certain level => allowed MiTM attacks - Mitigation -- use tools such as SSL Labs to test server & apply mitigations
Stripping
- For now, most browsers default to HTTP unless HTTPS explicitly specified in URL -- allows SSLStrip Attack - Attacker proxys through every one of connections to the real server & returns whatever the server would normally return - Everything looks normal, except no HTTPS - A network man-in-the-middle
HTTPS Certificate Ecosystem
- Forms web's public key infrastructure (PKI) - Is operated by: 1) Certificate authorities -- verify identities, revocation 2) Browser/platform developers -- implement cert validation & UI 3) CA/Browser Forum -- sets industry-wide issuance policies
After receiving certificate...
- Generate public key key-pair (private key bob & public key bob) - User can verify signature of CA on certificate using the CA's public key, & then use server's public key bob in certificate to verify TLS handshake between client & that server
HMAC
- HMAC construction turns a cryptographic hash function (SHA-256) into a Message Authentication Code - Hash-based Message Authentication Code (function) - MAC to get Message Integrity - Involves applying hash function twice - Design protects against length extension - EX) HMAC-SHA-256 - For practical purposes, we (think/hope) we can treat HMAC-SHA256 as a PRF - An HMAC is a fixed-length string of bits similar to other hashing algorithms such as MD5 and SHA-1, but it also uses a secret key to add some randomness to the result.
Phishing
- HTTPS cannot prevent Phishing - Majority of phishing site have valid certs - CAs don't have visibility into site behavior (CA doesn't continuously monitor content of sites & CA interact is a one time verification) - Mitigation -- Google Safe Browsing uses ML to ID dangerous sites, warn users
HTML
- Hypertext Markup Language - Defines document structure & hints @ appearance - Built from nested elements specified using <tags>, which may have "attributes" - Caution: some literal characters must be escaped or they may be interpreted as part of HTML markup
HTTP Protocol
- Hypertext Transport Protocol (HTTP) - Facilitate way to send requests to server & receive responses - Allows fetching of individual resources (ie HTML documents) - Structures as a sequence of request & responses (not as a stream of data) - Fundamental protocol out there
Path
- Identifies resource to server - Format is up to server
Cryptographic Doom Principle
- If you have to perform any cryptographic operation before verifying the MAC on a message you've received, it will somehow inevitably lead to doom
Why use D-H if other methods of sending a key confidentially exists?
- Important goal: forward secrecy - We want option to communicate repeatedly - Pitfall: adversary could record all ciphertext, then later steal our key - Solution: for each session, use D-H to generate temporary session key. Use separate long-term key to authenticate it - Pros: compromising long-term key would allow future impersonation, but not retrospective decryption (assuming attacker cannot break D-H)
XSS Defense: Validation & Escaping
- Input validation: Checks all headers, cookies, query strings, form fields, & hidden fields against rigorous specification of what is allowed - Output escaping: encode all special character in output to prevent interpretation as code
Authenticated encryption with associated data (AEAD)
- Integrity & encryption in one step - Seal & unseal operations - Associated data is covered by verifier but not included in the ciphertext (Used in sealing & unsealing)
JavaScript and the Dom
- JavaScript running in the browser can read & modify page content - Document Object Model (DOM) & other APIs provide a standard programming interface (JavaScript's API is DOM) - Resource loading from other sources
Multiple Perspective Domain Validation
- Just the challenge validation from Let's Encrypt - Splits up the traffic to attempt to retrieve content from site - All must return correct content in order for CA to trust you're legit - Attacker must intercept all of these challenges on all of these network paths
Confidentiality
- Keep content of message p secret from an eavesdropper (Eve) - Construct E() & D() from secure PRG (a block cipher) w/ appropriate padding/cipher mode - Eve is a passive attacker (can only see messages going across channel) - Can be more dangerous than an active attacker (will not know anything is happening unless attacker visibly reacts)
Login CSRF Attack
- Log victim's browser into an honest site w/ an account controlled by the attacker - Your browser logs into attacker account & attacker changes profile to look like you still (you don't realize you're in the attacker's "space") - Could accidentally be logged into an account where the hacker can store whatever you're doing & use it
Referer Validation
- Make sure referer is actually my own website, then cross-site request is fine - Allows sites to identify where users are coming from - Allowed -- https://bank.com => bank.com - Not allowed -- https://attacker.com => bank.com - User can turn off referer => not a sustainable solution
Ciphertext Malleability
- Many encryption methods are malleable: can transform a ciphertext into another ciphertext that decrypts to a related plaintext w/o knowing plaintext - CTR mode: Flipping bits anywhere in ciphertext => flips corresponding bits in decrypted plaintext - CBC mode: Will completely corrupt decrypted block i, all blocks following will have those bits flipped too. Can corrupt block of plaintext
Length Extension
- Merkle-Damgard functions are susceptible to length extension attacks - Attackers can calculate z = H(m || padding || v) using concatenation, where m is the original input to the hash function - Attacker doesn't know the padding (but can guess until the attacker gets it right) & gets to choose a value of whatever length
MAC
- Message Authentication Code (MAC) - Use MAC to get Message Integrity - Designed to be used as a secure verifier - Inputs = key, arbitrary length data - Output = fixed size digest (n bits)
Injection Attacks
- Mistake data fro code & execute it - Exploit vulnerabilities allowing specially crafted inputs to cause execution of malicious instructions - Types of injection attacks: SQL, Cross-Site Scripting, Shell, & Control Hijacking
HTTP Strict Transport Security (HSTS)
- Mitigation for SSLStrip Attack - Server sends special HTTP heading (max-age=3153600) - Browser will exclusively use HTTPS for the domain for max-age seconds & refuse to bypass certificate errors - First-time user to domain (wouldn't know HTTPS was suppose to be there)? Domains can get on HSTS Preload List shipped w/ browsers
Problems w/ Site Design
- Mixed content (resources loaded over HTTP from inside HTTPS page) -- can be modified or leaked (use HTTPS for all resources) - Cookies send over HTTPS will be sent unencrypted if browser later requests an HTTP URL from domain (set secure attribute on cookies so only sent via HTTPS) - HTTPS reveals certain information about a site (clients can use Tor or VPNs for privacy)
Content Security Policy (CSP)
- Modern approach that allows site to eliminate XSS by tightly specifying what scripts are allows to execute - Browsers will only execute scripts loaded in source files received from specified domains - Prohibits inline scripts & event-handling HTML attributes
Single Perspective Domain Validation
- One challenge validation check from Let's Encrypt data center - Only have to intercept single challenge validation
Ceasar Cipher
- One of the earliest examples of encryption -Encryption: c-i := (p-i + k)mod26 - Decryption: p-i := (c-i - k)mod26
True Randomness
- Output of a physical process that is inherently unpredictable - True randomness is expensive, often want to take a small amount of it & create a longer sequence that's "as good as random" - Input to generate key
Secret Token Validation
- Pages served by site embed a secret value in each request, server validates it - Nothing stops attacker from stealing token - Static tokens provide no protection (attacker can simply look them up) - Must be a session-dependent token, typically tied to session cookie (attacker cannot retrieve cookie due to SOP)
Query
- Parameter string passed to server - Can be anything of meaning to server - Originally used as format of key value
Fragment
- Parameter string visible only to client - Guides browser on where to go - Locally stored - EX) #section4 tells browser to scroll to named location
Preventing SQL Injection
- Parameterize (aka prepared) SQL statements - ORM (Object Relational Mapper) -- language-specific methods for accessing data using native code - Not sufficient to escape or filter out single quotes
HTTP Cookies
- Piece of data that server sends to the browsers - Browser may store it & return it in later requests to the same server - User for maintaining session state across HTTP requests (logins), personalization (storing preferences), & tracking user behavior on or across site - Clients can read, change, or erase cookie data
Web Security Goals
- Protect users from malicious sites & networks - Isolate sites from each other w/in browser: 1. Integrity (Site A cannot affect user's session on site B) & 2. Confidentiality (Site A cannot steal user's data from Site B)
Integrity
- Protection against tampering w/ messages - Let f() be secure PRF - Message Authentication Codes - HMAC-SHA-256 from hashes & keys to protect against length extension & use hashes & keys to compute verifier
Scheme
- Protocol used to access resource
TCP (Transmission Control Protocol)
- Provides "phone call"-like semantics (dial, send/receive data stream, hand up) - Does NOT provide confidentiality, integrity, authenticity - Plaintext
Pseudorandom Permutation (PRP)
- Pseudorandom function that also has an inverse (AES) - Encryption -- want to be able to encrypt & decrypt
PKI
- Public Key Infrastructure - Group of technologies used to request, create, manage, store, distribute, and revoke digital certificates.
RSA Key Pair
- Public key: (e, N) - Private key: (d, N) - Only person w/ particular private key can sign the message - Anyone w/ corresponding public key can verify signature & know it was made by private key - Anyone w/ your public key can send you a message in private & only you can decrypt it w/ your private key - Satisfies integrity - RSA can be used for encryption & digital signatures
GET
- Retrieve data, shouldn't change server state - GET request for data that you want (resource)
SameSite Cookie
- SameSite attribute prevents browser from sending cookie in cross-site request - SameSite= Strict (cookie isn't even sent in cross-site context) - SameSite= Lax (Cookie isn't sent on normal cross-site sub requests, but is allowed when following a regular link) - Should always set SameSite= Lax (more browsers do so as default)
Host
- Server's domain or IP address
Setting a cookie
- Site can set cookie for its own domain & any parent domain (as long as parent domain is not a public suffix) - login.site.com can set cookies for login.site.com & site.com
Stored XSS
- Site stores & displays user content w/o properly escaping it - Attacker uploads content that site shows to other users. Their browser load the resource & execute the code in their authentication contexts - Stores malicious code in a resource managed by the server, such as a database, where it can target other users - Attacker stores untrusted JavaScript on server side where an innocent victim can run data to browser - EX) Discovers vulnerability that enables script injection. Injects website w/ malicious script that steals each visitor's session cookies. Malicious script activated w/ each visit to website. Visitor's session cookies sent to perpetrator - Samy Worm 2005
Pseudorandom Generator (PRG)
- Somewhat like a PRF - No input except for key, where key (k) is a truly random seed - Cannot distinguish PRG from random stream of bits unless k is known
Resource loading from other sources...
- Sub resource loading gives lots of opportunity for attacks - Loading from lots of different sites (could a website view your gmail)
Port
- TCP port (default 443 for HTTPS & 80 for HTTP)
AES Block Cipher
- Today's most common block cipher - Efficient in software & hardware - Widely believed to be secure PRP (cannot be proved) - Designed to be difficult to analyze w/o knowing the key
Counter (CTR) Mode
- Turns a block cipher into a stream cipher - Benefits: doesn't require padding, efficient parallelism/random access - Generate key stream that we XOR w/ plaintext to get cipher text - Encrypt nonce (index 0 first) concatenated w/ secret key - Need guarantee that same nonce is not used w/ same key more than once
URLs
- Uniform Resource Locators - String specifying a unique resource on the web
Encrypt-then-MAC
- Universally regarded as safest of approaches because our encryption so far only ensures against passive eavesdroppers - Only this can ensure ciphertext isn't tampered w/ before decrytion - Checking the MAC before decryption
Authentication Cookie
- Upon successful login, server sets a cookie w/ an unguessable random value -- the authentication cookie - Server DB (database) stores the token, username, & expiry time - Browser presents the authentication cookies in later requests - Server validates via DB - Cookie-based authentication is insufficient for request that will have any side effects (cannot authenticate the person who is initiating)
A Secure Channel Protocol
- Use Diffie-Hellman to generate shared secret - Use RSA signatures to confirm we're really talking to each other (sender authenticity) - Derive symmetric keys for each direction using PRF - Use AEAS or encrypt-then-MAC messages (TLS does all of this under the hood)
Safely encrypting w/ RSA
- Use RSA to encrypt random x < N, use a PRF (ie SHA-256) to derive a key from x, then encrypt message using a symmetric cipher & key k - No long worry about wrap around, padding what we're encrypting, message length (can just send unstructured random value) - Identical messages yield different ciphertexts - Don't have to worry about RSA padding - Don't have to worry about message length
Stream Cipher
- Use a PRG g-subk() which is practically indistinguishable from a random stream of bits, unless you know k - Alice & Bob choose PRG g(), share key k - Never reuse keys, never reuse PRG output bits - More practical approach to confidentiality than OTP - Probably secure if g() is secure under PRG (but we don't know how to prove that secure PRGs even exist)
Defending D-H from MiTM attacks
- Use digital signatures (what HTTPS websites do) - Mallory cannot replicate because they do not know private keys
Referer
- VPN can see which recommended you, VPN knows who to pay - Web page containing the link that visitor clicked on to get to this page
Pseudorandom Function (PRF)
- f-subk() is indistinguishable in practice from random unless you know k - Takes key & input
One-Time Pad (OTP)
- k (OTP) is the same length as the plaintext & is truly random - Encryption: c-i := p-i XOR k-i - Decryption: p-i := c-i XOR k-i - Pro: provable secure, Mallory cannot do better than random guessing - Con: usually impractical (just as big as the message) - Can never "reuse" any part of the pad
What defines an origin?
- scheme://domain:port - EX) https://eecs388.org:443
TLS Protocol Handshake
1) Negotiate Crypto Algorithms (about negotiating cryptographic algorithms, client send to server a menu of algorithms it supports) 2) Established Shared Secret (Diffie-Hellman for forward secrecy, but don't know who secret was shared w/ => need 3rd step) 3) Authenticate the Server (Authenticating server using public key crypto, client authenticates server's public key w/ certificate chain)
Browser Execution Model
1. Loads content @ URL 2. Parses HTML & runs any inline JavaScript code 3. Fetches & renders subresources (JavaScript, image, CSS, frames) - After loading -- calls javaScript functions in response to user inputs, timeouts, etc - Document can also include frames which display another whole HTML page - Browser isolates frames from parent document
