The Man in the Middle
Transparante HTTPS-proxy op de firewall
Om gebruikers in bedrtjfsnetwerken te beschermen tegen de gevaren van het web, wordt meestal gebruik gemaakt van een firewall. Moderne firewalls zetten niet meer alleen poorten open en dicht, maar kijken ook naar de inhoud van pakketten: bijvoorbeeld om ‘goed’ HTTP-verkeer te onderscheiden van ‘slecht’ HTTP verkeer. Dit levert een uitdaging op bij versleutelde verbindingen, zoals bijvoorbeeld HTTPS. Door de firewall op te laten treden als Certificate Authority kan ook dit versleutelde verkeer op een verantwoorde manier worden gescreend. Wie regelmatis op het net surft kent de gevaren: louche sites proberen je ertoe te verleiden om virussen, dialers en andere malware te installeren. Thuis moeten gebruikers zichzelf tegen dit soort aanvallen wapenen met behulp van virusscanners en personal firewalls – vaak met wisselend succes. In een bedrijfssituatie is het de moeite waard om de werkplekken centrall te beschermen, bijvoorbeeld door gebruik te maken van een firewall op netwerkniveau. Een infectie in een bedrijf kost in het gunstigste geval alleen wat tijd, maar kan in het ergste geval leiden tot grote storingen of het uitlekken van vertrouwelijke informatie.
Een netwerkfirewall regelt het dataverkeer tussen het internet in het bedrijfsnetwerk. Vroeger werd hierbij voornamelijk gekeken naar IP-adressen en poortnummers, maar moderne firewalls kijken ook naar de inhoud van het verkeer. Zo kan het bijvoorbeeld verstandig zijn om in principe wel HTTP-verkeer toe te staan, maar daarbij geen ActiveX-componenten door te laten.
Versleutelde verbindingen
Voor veel toepassingen, zoals internetbankieren, is het wensetijk om met een website te communiceren over een versleutelde verbinding. Dat kan met HTTPS: de HTTP-verbinding wordt hierbij ‘ingepakt in een versleutelde SSL- of TLS-verbinding.
Voor deze versleuteling wordt een ‘session key gebruikt, die alleen bekend is bij de Webserver en de client (de browser), Deze sleutel wordt voor iedere sessie door de client willekeurig verzonnen en door middel van public-key-cryptografie veilig naar de server gestuurd.
Bij public-key cryptografie heeft iedere partij een ‘sleutelpaar’ dat bestaat uit een publieke en een prive-sleutel, die wiskundig nauw met elkaar verbonden zijn. Berichten die worden versleuteld met de pubiieke sleutel kunnen alleen met de bijbehorende prive sleutel worden ontsleuteld, en vice versa.
De versleutelde verbinding komt tot stand nadat de server zijn publieke sleutel naar de client heeft gestuurd. De client kiest een willekeurige session key en versleutelt deze met de publieke sleutel van de server. Aangezien de server (aIs het goed is) de enige is die zijn eigen prive-sleutel kent, is hij ook de enige die dit berieht weer kan ontsleutelen. Daarom kan dit berieht zander problemen over het internet naar de server gestuurd worden, zonder dat we bang hoeven te zijn dat het wordt afgeluisterd. Na deze uitwisseling kennen alleen de client en de server de session key, dus kan deze gebruikt worden om het verkeer eenvoudig te versleutelen.
Certificaten
Bovenstaande is genoeg om te garanderen dat je met iemand kunt communiceren over een veilige verbinding – maar met wie communiceer je nu eigenlijk? Weet je wei zeker dat de sleutel die je kreeg ook echt de publieke sleutel is van degene met wie je denkt te maken te hebben?
Om zich te authenticeren stuurt de server in de eerste stap niet alleen zijn publieke sleutel, maar ook een ‘certificaat’ naar de client. Dit certificaat zegt in principe iets als: ‘Publieke sleutel X hoort bij hostname Y’. Een certificaat wordt uitgegeven en digitaal ondertekend door een zogenaamde Certificate Authority (CA). Deze controleert (als het goed is) vóór uitgifte of de aanvrager inderdaad de elgenaar is van de hostname in het certificaat. Eigenlijk is de betekenis van een certificaat dus nog iets subtieler: ‘Deze CA gelooft dat publieke sleutel X hoort bij hostname Y’. Om te bepalen weike CA’s te vertrouwen zijn, bevatten browsers een lijstje publieke sleutels van vertrouwde CA’s, Een lijst met de bekendste, zoals Verisign, wordt meestal standaard met de browser meegeleverd.
De keerzijde van de medaille
Dit is natuurlijk een prachtige techniek die voorziet in een reele behoefte, maar het maakt het in bedrijfsnetwerken wel moeilijker om de gebruikers te beschermen. De firewall kan met zomaar in de versleutelde gegevens kijken - dat was immers het doel van de versleuteling. Daardoor kan hij de pakketten dus ook niet controleren op schadelijke inhoud. Aangezien het praktisch gezien vaak met acceptabel zal zijn helemaal geen versleutelde verbindingen toe te laten, laten veel firewalls HTTPS-verkeer standaard ongescreend door. Dit hiedt een mogelijkheid voor aanvallers om zo hun malware naar binnen te loodsen. Toch zijn er wef degelijk manieren waarop de IT-afdeling haar gebruikers tegen dit soort aanvallen kan beschermen.
Niet-transparante proxy
Een eenvoudlge manier om (onversleuteld) HTTP-verkeer te screenen is door gebruik te maken van een niet-transparante proxy. Bij gebruik van een proxy neemt de browser van de gebruiker geen direct contact meer op met een bezochte website, maar vraagt hij de paginal op bij de proxy-server van het bedrijf. Deze proxy-server haalt de pagina dan op, screent hem, en stuurt hem door naar de gebruiker.
Ook HTTPS-verkeer kan via een proxy gaan. Dat verloopt (helaas?) echter zo, dat het onmogelijk is om de inhoud van het HTTPS-verkeer op de proxy-server te analyseren. De browser maakt met een ‘CONNECT’-com man do aan de proxy-server duidelijk met welke host hij wil communiceren. De proxy-server zal die ver binding opzetten, maar doet daarna nog slechts dienst als ‘doorgeefluik’ voor de versleutelde gegevens die been en weer verstuurd worden.
Deze methoden heten ’niet-transparant’ omdat de client aangepast moet worden om er gebruik van te maken. De meeste browsers ondersteunen deze functionaliteit wel t maar andere software vaak niet. Bovendien kan op deze manier de inhoud van de versleutelde verbinding dus niet gescreend worden.
Een elegantere oplossing is daarom de zogenaamde transparante proxy. Deze biedt dezelfde mogelijkheden als de gewone proxy, maar is volledig ’transparant’ voor de client: voor de browser lijkt het alsof hij gewoon direct contact heeft met de website. De verbinding wordt echter door de proxy-server ‘onderschepf. Vaak doet een firewafl tegelijk ook dienst als proxy-server.
Voor onversleuteld HTTP-verkeer wor¬ den transparante proxies tegenwoordig veel gebruikt. In het geval van HTTPS is dat niet zo: volgens 50 m mi gen is het Inherent onmogelijk om een transparante HTTPSproxy te maken, zonder onoverkomefijke concessies te doen aan de veiligheid. De rest van dit artikel laat zien dat hier toch een redelijke middenweg te vinden is.
Man-in-the-Middle
We maken even een uitstapje naar een bekende aanval op HTTPS: de zogenaamde ‘man-in-the-middle’-attack. Deze aanval houdt in dat als een aanvaller volledige controle heeft over een machine tussen de client en de server, hij ook de verbinding kan controleren [4,6]. Als de aanvaller de client een verbinding ziet maken met de server, onderschept hij deze aanvraag en geeft hij zelf antwoord. Ondertussen maakt hij een ’normale’ verbinding naar de server waar de gebruiker eigenlijk heen wilde. Nadat de aanvaller de pagina gelezen en eventueel aangepast heeft wordt deze ook naar de gebruiker gestuurd, die zo niet direct door heeft dat er lets mis is.
Deze aanval werkt echter maar gedeeltetijk: zoals we eerder hebben gezien is zeker dat de gebruiker commurviceert met iemand die de priv^sleutel heeft die hoort bij de gebruikte publieke sleutel. Aangezien de aanvaller natuurlijk geen toegang heeft tot de privé-sleutel van de server, zal hij een ander sleutel paar moeten gebruiken, Hij zal dus ook geen geldig certificaat kunnen aanleveren waarin staat dat de publieke sleutel van de aanvaller hoort bij de hostnaam van de server: geen enkele betrouwbare CA zou zo’n certificaat afgeven. De gebruiker krijgt dus bij het bezoeken van een beveiligde website een pop-up die hem vertelt dat het certificaat niet klopt. In de praktijk klikken de meeste gebruikers zo’n melding echter klakkeloos weg.
De firewall als Certificate Authority
Om gebruikers transparant te beschermen tegen dretgingen die verpakt zijn in een HTTPS-verbinding, zou je deze man-in-the-middletechniek binnen bedrijven echter op de firewall toe kunnen passen. Dit wordt door de meeste proxy-programmatuur niet ondersteund, aangezien het tot gevolg zou hebben dat de gebruikers bij iedere HTTPS-verbinding een pop-up te zien zou den krijgen. Dat is niet alleen vervelend, maar daardoor kunnen ze ook niet meer bepalen of de verbinding verder veilig is. De beveiligde verbinding kan immers, behalve op de firewall, ook nog op andere piaatsen onderbroken zijn. Gebruikers zouden daar terecht geen genoegen mee nemen.
Hier is een oplossing voor: eerder in dft artikel hebben we bekeken wat een certificaat eigenlijk betekent: “Deze CA garandeert dat deze publieke sleutel hoort bij deze hostnaam”. De truuk is dat we de IT-afdeling laten optreden als een soort ondergeschikte CA. De ‘man-in-the-middle’-achtige software op de firewall controleert dan of het certificaat van de server kiopt. Is dat het geval, dan produceert het voor de verbinding tussen de firewall en de gebruiker een certificaat dat zegt: Systeembeheer garandeert dat deze publieke sleutel hoort bij deze hostnaam.
De lokale computers kunnen nu zo worden geconfigureerd dat ze, in plaats van de ‘officiele’ Certificate Authorities, de afdeling Systeembeheer vertrouwen. Systeembeheer zorgt ervoor dat de doorgestuurde gegevens niet alleen van de gewenste host afkomstig zijn, maar ook geen malware bevatten.
In de praktijk
Voor zover wij na hebben kunnen gaan zijn er nog geen gratis implementaties van deze techniek - we I lijkt het in de commerciele editie van Zorp te zitten, dat in afgeslankte vorm ook onder de GPL beschikbaar is. Ook
ettereap, een open-source tool om Man-inthe-Middle-aanvallen uit te voeren, biedt voorzover wij hebben kunnen nagaan geen mogelijkheid om de firewall ais CA te laten optreden. Om c’Hezers toch wat hands-on ervarmg te kunnen bieden hebben we een proof-of-concept-implementatie gemaakt op basis van webmitm uit het dsniff-pakket. Dit werkt alleen op Linux-servers.
Om aan de slag te kunnen heb je onder andere de versleutelbibliorheek OpenSSL nodig en het programma dsniff van Dug Song. Pak dsniff uit en vervang het bestand webmitm.c in webmitm door de versie op de cd of van [7]. Voeg eventueel je filtering toe aan dojfilter Compileer nu de gepatchte webmitm met ./configure; make libmissing.a; make webmitm en genereer het sleutelpaar en CA-certificaat voor de transparante proxy met:
openssl genrsa -out ca.key 2048 openssl req -new -key ca.key \
-x509 -days 1095 -out ca.crt
De private key ca.key houd je goed geheim op de proxy-server, het certificaat ca.crt tmporteer je als Vertrouwde CA* in Je browser, In Firefox doe je dat door met Preferences / Advanced / View Certificates / Authorities / Import het crt-bestand te importeren. Safari-gebruikers gebruiken de Keychain Access-applicatie die bij Mac OS X geleverd wordt. Als je nog Explorer gebruikt vind je de “Key Store* onder View / Tools / Internet Options / Content / Personal / Certificates.
Op de proxy-server leidje nu het verkeer om langs de proxy-software. Afhankelijk van je configuratie gaat dat ongeveer als volgt:
iptables -t nat -A PREROUTING -p tcp -dport 441 -j / DNAT -to 192.168.1.2:12321
Vervang hier 192.168.T2 door het IP-adres van de proxy-server/firewall. Doorgaande pakketten naar HTTPS-poort 443 gaan vanaf nu naar de server zelf op poort 12327 en dus niet naar de gewone proxy-software (bijv. Squid). Met ./webmitm start je nu de proxy-software, zodat deze op die poort gaat luisteren en zorgt voor het genereren van de certificaten en de afhandeling van de request,
Conclusie
Het is fundamenteel onmogelrjk HTTPS-verbindingen te beschermen zonder de inhoud te bekijken. Paranoïde systeembeheerders zouden dus kunnen beslissen helemaal geen HTTPS toe te staan. Door de firewall op te laten treden als Certificate Authority, is er echter een middenweg die de privacy van de gebruiker slechts beperkt (want alleen op de firewall) schendt. Je zou er zelfs voor kunnen kiezen wel directe verbindingen toe te staan naar specifieke vertrouwde sites, bijvoorbeeld die van banken. Zo wordt er een mooie balans gevonden tussen de gewenste screening aan de ene kant en de bruikbaarheid en betrouwbaarheid voor de gebruiker aan de andere kant.
