Terwijl ik dit schreef heeft de redactie https://www.security.nl/posting/523336/DNS+requests+over+poort+80 gesloten (begrijpelijk, want de vraagsteller was de weg kwijt) maar aangezien ik er al iets over geschreven had, wil ik de lezer dat toch niet onthouden...)

DNS
Om performance redenen (in elk geval historisch) gaat DNS primair via UDP poort 53 (TCP poort 53 kan ook onder bepaalde omstandigheden).

Om integriteitsredenen valt er veel voor te zeggen om geen UDP te gebruiken voor DNS. Want daarmee kunnen antwoorden in principe door elk internet IP-adres worden gespoofed, terwijl een aanvaller bij TCP connecties daadwerkelijk toegang moet hebben tot de verbinding (spoofen betekent dat de afzender van het antwoord wordt vervalst, waarna de aanvaller die dat doet, elk gewenst antwoord kan geven).

Bij DNSSEC worden antwoorden digitaal ondertekend om de integriteit en authenticiteit te waarborgen. DNSSEC doet niets aan vertrouwelijkheid (alles wordt nog steeds plain-text verzonden). M.a.w. zelfs als je uitsluitend DNSSEC zou gebruiken, kan via public WiFi eenvoudig worden vastgesteld welke DNS lookups jij doet en welke antwoorden jij krijgt. DNSSEC helpt dan natuurlijk wel garanderen dat die antwoorden niet worden vervalst.

Het voordeel van (theoretische) geauthenticeerde en versleutelde DNS verbindingen is echter beperkt, want een aanvaller met toegang tot de verbinding (jouw ISP of werkgever, backdoorded MODEM, public WiFi, WiFi met kraakbaar wachtwoord, VPN endpoint en TOR start- en endpoint) kan daarna nog steeds zien met welke IP-adressen jij verbinding maakt (in het geval van TOR weet een endpoint, als het goed is (fingers crossed), niet precies wie jij bent). Een nadeel is dat het aanzienlijk trager zou zijn.

OCSP
OCSP gebruikt in elk geval TCP, waarmee spoofing door derden beperkt is tot aanvallers met toegang tot de verbinding. Bovendien wordt via OCSP meestal niet de domainname van de server o.i.d. meegestuurd, maar een hash van het certificaat - waar je als eenvoudige aanvaller niet zoveel aan hebt. Ten slotte kan die aanvaller (met toegang tot jouw verbinding) sowieso zien met welk IP-adres van de betreffende website jij communiceert, dus dat proberen geheim te houden in OCSP helpt niet veel.

Het grootste probleem van OCSP is dat de meeste browsers gewoon aannemen dat "het wel goed zit" als ze niet snel antwoord krijgen van de OCSP server. Dat betekent dat een aanvaller slechts de antwoorden naar jouw PC hoeft te blokkeren als hij een MITM aanval inzet met een gekopieerd certificaat en de bijbehorende private key ook in zijn bezit heeft. OCSP verbindingen versleutelen helpt geen zier om dit probleem tegen te gaan.

Een ander probleem van OCSP is dat de certifcaatverstrekker precies weet wanneer jij welke https site bezoekt (en die informatie zou kunnen verkopen), een privacy probleem dus. Theoretisch kunnen ook anderen, die op basis van hashes in OCSP requests weten om welk certificaat (van welke site) het gaat (en jouw verbindingen kunnen afluisteren), weten welke https sites jij bezoekt. Maar ook hier geldt dat zij sowieso de IP-adressen voorbij kunnen zien komen.

Bij OCSP stapling verstuurt de webserver een OCSP antwoord mee naar jouw browser, waardoor de certificaatverstrekker buiten het plaatje valt (die OCSP antwoorden hebben een zeer korte geldigheidsduur van bijv. 5 minuten, waar certificaten vaak 2 or 3 jaar geldig zijn - m.u.v. Let's Encrypt die 3 maanden geldig zijn).

Certificaten kunnen "OCSP must staple" vermelden, waarmee de browser weet dat de server een (niet te oud) stapled OCSP antwoord moet meesturen (en een MitM aanvaller er niet mee wegkomt door die informatie uit te filteren). Echter, als de OCSP server [waar de (i]https webserver[/i] bijv. elke 5 minuten een antwoord ophaalt) dan een tijdje niet bereikbaar is of jouw webserver heeft zelf problemen heeft met ophalen/verwerken van die OCSP antwoorden, heb je een mooie DoS op je website. Zie https://blog.hboeck.de/archives/886-The-Problem-with-OCSP-Stapling-and-Must-Staple-and-why-Certificate-Revocation-is-still-broken.html voor meer info.