Outline SSH SSL/TLS CSci 5271 DNSSEC Introduction to Computer - PDF document

Outline SSH SSL/TLS CSci 5271 DNSSEC Introduction to Computer Security Announcements intermission Protocols and web combined slides The web from a security perspective Stephen McCamant SQL injection University of Minnesota, Computer Science & Engineering Web authentication failures Cross-site scripting Authentication methods Old crypto vulnerabilities 1.x had only CRC for integrity Password, encrypted over channel Worst case: when used with RC4 ✳s❤♦sts : like ✳r❤♦sts , but using client host key Injection attacks still possible with CBC User-specific keypair CRC compensation attack Public half on server, private on client For least-insecure 1.x-compatibility, attack detector Plugins for Kerberos, PAM modules, etc. Alas, detector had integer overflow worse than original attack Newer crypto vulnerabilities SSH over SSH IV chaining: IV based on last message ciphertext SSH to machine 1, from there to machine 2 Allows chosen plaintext attacks Common in these days of NATs Better proposal: separate, random IVs Better: have machine 1 forward an encrypted Some tricky attacks still left connection (cf. HA1) Send byte-by-byte, watch for errors 1. No need to trust 1 for secrecy Of arguable exploitability due to abort 2. Timing attacks against password typing Now migrating to CTR mode SSH (non-)PKI Outline SSH When you connect to a host freshly, a mild note SSL/TLS When the host key has changed, a large warning DNSSEC Announcements intermission ❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅ ❅ ❲❆❘◆■◆●✿ ❘❊▼❖❚❊ ❍❖❙❚ ■❉❊◆❚■❋■❈❆❚■❖◆ ❍❆❙ ❈❍❆◆●❊❉✦ ❅ The web from a security perspective ❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅ ■❚ ■❙ P❖❙❙■❇▲❊ ❚❍❆❚ ❙❖▼❊❖◆❊ ■❙ ❉❖■◆● ❙❖▼❊❚❍■◆● ◆❆❙❚❨✦ SQL injection ❙♦♠❡♦♥❡ ❝♦✉❧❞ ❜❡ ❡❛✈❡s❞r♦♣♣✐♥❣ ♦♥ ②♦✉ r✐❣❤t ♥♦✇ ✭♠❛♥✲✐♥✲t❤❡✲♠✐❞❞❧❡ ❛tt❛❝❦✮✦ Web authentication failures ■t ✐s ❛❧s♦ ♣♦ss✐❜❧❡ t❤❛t ❛ ❤♦st ❦❡② ❤❛s ❥✉st ❜❡❡♥ ❝❤❛♥❣❡❞✳ Cross-site scripting

SSL/TLS IV chaining vulnerability Developed at Netscape in early days of the public web TLS 1.0 uses previous ciphertext for CBC IV Usable with other protocols too, e.g. IMAP But, easier to attack in TLS (vs. SSH): SSL 1.0 pre-public, 2.0 lasted only one year, 3.0 More opportunities to control plaintext much better Can automatically repeat connection Renamed to TLS with RFC process “BEAST” automated attack in 2011: TLS 1.1 wakeup TLS 1.0 improves SSL 3.0 call TLS 1.1 and 1.2 in 2006 and 2008, only gradual adoption Compression oracle vuln. But wait, there’s more! Compr ✭ ❙ ❦ ❆ ✮ , where ❙ should be secret and ❆ is Too many vulnerabilities to mention them all in attacker-controlled lecture Kaloper-Merˇ Attacker observes ciphertext length sinjak et al. have longer list “Lessons learned” are variable, though If ❆ is similar to ❙ , combination compresses better Meta-message: don’t try this at home Compression exists separately in HTTP and TLS HTTPS hierarchical PKI Hierarchical trust? No. Any CA can sign a cert for any domain Browser has order of 100 root certs A couple of CA compromises recently Not same set in every browser Most major governments, and many companies Standards for selection not always clear you’ve never heard of, could probably make a Many of these in turn have sub-CAs ❣♦♦❣❧❡✳❝♦♠ cert Also, “wildcard” certs for individual domains Still working on: make browser more picky, compare notes CA vs. leaf checking bug MD5 certificate collisions MD5 collisions allow forging CA certs Certs have a bit that says if they’re a CA Create innocuous cert and CA cert with same hash All but last entry in chain should have it set Requires some guessing what CA will do, like sequential Browser authors repeatedly fail to check this bit serial numbers Also 200 PS3s Allows any cert to sign any other cert Oh, should we stop using that hash function?

CA validation standards HTTPS and usability CA’s job to check if the buyer really is ❢♦♦✳❝♦♠ Many HTTPS security challenges tied with user decisions Race to the bottom problem: CA has minimal liability for bad certs Is this really my bank? Many people want cheap certs Seems to be a quite tricky problem Cost of validation cuts out of profit Security warnings often ignored, etc. “Extended validation” (green bar) certs attempt to fix We’ll return to this as a major example later Outline DNS: trusted but vulnerable SSH SSL/TLS Almost every higher-level service interacts with DNS DNSSEC UDP protocol with no authentication or crypto Announcements intermission Lots of attacks possible The web from a security perspective Problems known for a long time, but challenge to fix SQL injection compatibly Web authentication failures Cross-site scripting DNSSEC goals and non-goals First cut: signatures and certificates ✰ Authenticity of positive replies Each resource record gets an ❘❘❙■● signature E.g., ❆ record for one name ✦ address mapping ✰ Authenticity of negative replies Observe: signature often larger than data ✰ Integrity Signature validation keys in ❉◆❙❑❊❨ RRs ✲ Confidentiality Recursive chain up to the root (or other “anchor”) ✲ Availability Add more indirection Negative answers DNS needs to scale to very large flat domains like Also don’t want attackers to spoof non-existence ✳❝♦♠ Gratuitous denial of service, force fallback, etc. Facilitated by having single ❉❙ RR in parent indicating But don’t want to sign “ ① does not exist” for all ① delegation Solution 1, ◆❙❊❈ : “there is no name between ❛❝❛❝✐❛ Chain to root now includes ❉❙ es as well and ❜❛♦❜❛❜ ”

Preventing zone enumeration DANE: linking TLS to DNSSEC Many domains would not like people enumerating all their entries “DNS-based Authentication of Named Entities” DNS is public, but “not that public” DNS contains hash of TLS cert, don’t need CAs Unfortunately ◆❙❊❈ makes this trivial How is DNSSEC’s tree of certs better than TLS’s? Compromise: ◆❙❊❈✸ uses password-like salt and repeated hash, allows opt-out Signing the root Deployment Political problem: many already distrust US-centered Standard deployment problem: all cost and no nature of DNS infrastructure benefit to being first mover Practical problem: must be very secure with no Servers working on it, mostly top-down single point of failure Clients: still less than 20% Finally accomplished in 2010 Will probably be common for a while: insecure Solution involves ‘key ceremonies’, international connection to secure resolver committees, smart cards, safe deposit boxes, etc. What about privacy? Outline SSH Users increasingly want privacy for their DNS SSL/TLS queries as well DNSSEC Older DNSCurve and DNSCrypt protocols were not Announcements intermission standardized The web from a security perspective More recent “DNS over TLS” and “DNS over HTTPS” SQL injection are RFCs Web authentication failures DNS over HTTPS in major browsers might have Cross-site scripting serious centralization effects Hands-on assignment 2 up Outline SSH SSL/TLS If same group as HA1, host and group number are DNSSEC the same Announcements intermission Otherwise, contact Travis to change The web from a security perspective Instructions and VMs now available SQL injection Due Friday, November 22nd Web authentication failures Cross-site scripting