Het HTTPS-protocol beschermt het internetverkeer tegen manipulatie en meelezen door het te versleutelen. Maar dat belemmert firewalls om verborgen trojans in downloads te ontdekken. Met TLS-inspectie kan een firewall de malware toch opsporen.
In dit artikel laten we je zien hoe TLS-inspectie werkt bij het ontdekken van malware en welke voor- en nadelen die techniek heeft.
De klassieke webproxy fungeert als een onzichtbare tussenpersoon tussen de internetgebruiker en de webserver. De gebruiker communiceert met de proxy, die op zijn beurt communiceert met de server. Vroeger werden proxies gebruikt om webinhoud lokaal op te slaan en dataverkeer te verminderen. Tegenwoordig moeten firewalls en webfilters versleuteld verkeer ontsleutelen om de inhoud te controleren. Dit is hoe het proces verloopt:
Om HTTPS-verbindingen te vertrouwen, moet de browser van de client de certificaten van de proxy vertrouwen. Dit kan worden bereikt door de proxy als root-certificeringsautoriteit (CA) in te stellen. Het certificaat wordt geïmporteerd in het besturingssysteem van de client. Het CA-certificaat kan automatisch worden uitgegeven aan beheerde clients via groepsbeleid of Mobile Device Management (MDM). Je kunt de geldigheid van het certificaat controleren door een website zoals ct.nl op te roepen. Problemen met zelf ondertekende certificaten en zwakke protocollen kunnen worden onderzocht via www.badssl.com.
Als je een divers assortiment IT-apparaten beheert, kun je gefrustreerd raken bij het verspreiden van het nieuwe CA-certificaat. Je zult problematische gevallen tegenkomen waarbij het certificaat weigert te worden geïmporteerd. Denk hierbij aan betaalkaartterminals, privésmartphones van medewerkers, smart-tv’s en IoT-apparaten.
Een oplossing voor dergelijke problemen zou een certificaat voor Intermediate Certification Authorities zijn, dat is ondertekend door een CA die al in de apparaten aanwezig is. Let’s Encrypt, populair bij webservers, is niet geschikt omdat het alleen standaard servercertificaten levert. Hierdoor zouden mensen hun eigen certificaten kunnen uitgeven voor bijvoorbeeld *.microsoft.com en valse updates kunnen verspreiden naar computers die op Windows draaien in hun netwerk.
Het idee van een eigen publieke CA strandt al snel vanwege de enorme financiële en tijdsinvestering. Voor goed geïnformeerde gebruikers voelt TLS-inspectie ongemakkelijk omdat de ‘vijand’ meeluistert en elk datapakket bekijkt. TLS-inspectie is eenvoudig te detecteren doordat alle bezochte websites certificaten hebben die zijn ondertekend door dezelfde CA, wat normaal gesproken niet voorkomt bij HTTPS-verkeer.
Er is echter een voor de hand liggende manier om het filter te omzeilen: gebruikers kunnen via een VPN tunnelen naar hun eigen router vanuit het bedrijfsnetwerk. Het is de taak van de beheerder om dit te voorkomen via de bedrijfsfirewall.
De zelf toegevoegde man-in-the-middle onderbreekt de end-to-end versleuteling en maakt spontaan gegenereerde certificaten die ondertekend zijn door de als betrouwbaar ingestelde Certificate Authority. De clients vertrouwen daarop, en dat brengt nieuwe risico’s met zich mee. Beheerders moeten hun zelfgemaakte CA beveiligen, zodat de veiligheid ervan in ieder geval vergelijkbaar is met die van een publieke CA.
Het is niet eenvoudig, omdat een CA gemaakt kan worden met een paar OpenSSL-commando’s en snel wordt toegevoegd aan de productieve infrastructuur. Om het goed te doen, moet je de richtlijnen en best practices volgen voor het veilig beheer van digitale certificaten.
Een ander kwetsbaar punt is dat de client niet langer de betrouwbaarheid controleert tot aan de webserver, maar alleen de korte route naar de proxy. De proxy valideert of de verdere route vertrouwd en veilig is. Als de webserver bijvoorbeeld een ongeldig, zelf ondertekend of verlopen certificaat levert, moet de proxy dat opmerken en voor de client een opzettelijk fout certificaat genereren. Zo kan de gebruiker zien dat de communicatie met het doelwit mogelijk onveilig is en de sessie beëindigen voordat er schade wordt aangericht.
Over ongeldige certificaten gesproken: als de proxy en de client verschillende sets CA-certificaten hebben opgeslagen, kunnen individuele TLS-verbindingen geldig zijn voor de proxy, maar niet voor de client – en andersom. Hierdoor kan de gebruiker nietsvermoedend naar een website gaan waar zijn browser zonder TLS-inspectie voor gewaarschuwd zou hebben.
Beheerders krijgen meer werk, omdat naast browsers ook besturingssystemen en toepassingen HTTPS gebruiken voor updates. Sommige updates, zoals Windows-updates, zijn niet compatibel met TLS-inspectie. Daarom moeten ze worden uitgesloten van TLS-inspectie met behulp van een lijst die regelmatig moet worden bijgewerkt als er veranderingen zijn in het updateproces van de betreffende systemen.
Doordat het extern versleutelde webverkeer in platte tekst door de firewall gaat, is het eenvoudig om de gegevens uit de firewall te halen en te analyseren. Vertrouwen in de infrastructuur en de beheerders is essentieel, maar dat vertrouwen kan worden geschonden.
Voor gebruikers van dergelijke netwerken geldt daarom het volgende: vermijd alle privé-internetactiviteiten op bedrijfsapparaten, vooral als het gaat om vertrouwelijke informatie en betalingsverkeer (internetbankieren, creditcardbetalingen). Als je werkgever een ongefilterd gastwifi aanbiedt, kun je beter je privé-smartphone gebruiken. Schakel anders over op mobiele data of gebruik je eigen vertrouwde VPN.
De firewall vereist extra rekenkracht voor dubbele cryptografie, zoals TLS-decodering en hernieuwde encryptie van elk pakket. Onderschat deze vereiste niet. Als de cpu van de firewall tot het uiterste wordt gedreven, wordt de proxy een bottleneck en vertraagt het grote downloads, zelfs bij een snelle internetverbinding.
Een snelle internetverbinding vereist dus ook een krachtige processor om onbelemmerd te kunnen surfen. Fabrikanten bieden mogelijk cryptoversnellers aan als achteraf in te bouwen uitbreidingskaarten voor firewallapparatuur. Een upgrade naar een krachtigere firewall (verticale schaalvergroting) of het toevoegen van een extra firewall (horizontale schaalvergroting) is vaak een betere optie.
Blijf op de hoogte omtrent alles wat met (cyber)security te maken heeft, schrijf je in voor de gratis nieuwsbrief:
TLS-inspectie wordt betwist omdat het de veiligheid van TLS en certificaten ondermijnt.
Beveiliging is echter mogelijk zonder TLS-inspectie door de malwareanalyse of virusscanner naar de clients te verplaatsen. Dit heeft ook voordelen voor de systeembelasting. De centrale firewall hoeft dan niet alle verbindingen te controleren, maar legt die taak bij de clients.
Als de client een beveiligingsprobleem detecteert, kan hij optioneel een centraal dashboard informeren en handelen volgens een vooraf ingesteld beleid: blokkeren, toestaan of waarschuwen.
Dit wordt problematisch als er apparaten zijn die niet onder het beheer van het bedrijf vallen, te oud zijn of onvoldoende prestaties bieden.
Bovendien zijn dergelijke softwareoplossingen uiteraard niet gratis.
De opensource firewalls vertrouwen op de proxyserver Squid en de ClamAV-virusscanner. OPNsense is ontstaan als een afsplitsing van pfSense en heeft sindsdien een eigen koers gevolgd. De webinterface van pfSense combineert de proxyserver en virusscanner, waardoor de configuratie er meer gestroomlijnd uitziet. Beide diensten communiceren via het Internet Content Adaptation Protocol (ICAP), maar de complexiteit die vereist is bij OPNsense blijft bij pfSense op de achtergrond.
De Endian-firewall maakt gebruik van dezelfde componenten, maar biedt de beheerder veel minder instelmogelijkheden via de configuratiepagina’s. Endian werkt goed als webproxy, maar is niet flexibel genoeg voor alle netwerkomgevingen en ondersteunt nog geen IPv6.
OpenWrt kiest de minimalistische route en verwacht dat de beheerder een volledige Squid-configuratie via de browserinterface doorgeeft. Dit zorgt voor maximale flexibiliteit, maar vereist diepgaande kennis van Squid. Een beetje meer gebruiksgemak is echter prettig, daarom is OpenWrt hooguit de eerste keuze voor TLS-inspectie als het al als router fungeert.
Sophos biedt met zijn beveiligingsproducten UTM en XG het verwachte gemak, maar de configuratiepagina’s van de twee producten verschillen fundamenteel. Daarbij fungeert zelf ontwikkelde software als proxy. Aangezien Sophos groot is geworden met virusscanners, komt ook dat onderdeel uit eigen huis. De XG firewall is het eenvoudigst in te stellen: zodra je webfiltering activeert in een regel, start de webproxy. Een ander selectievakje activeert de TLS-inspectie.
Het configureren van UTM is iets complexer: de webinterface koppelt filters, profielen, HTTPS, categorieën, gebruikers en acties. Het resultaat is een zeer gedetailleerde set regels voor complete HTTPS-filtering, inclusief IPv6
Een firewall kan virussen en malware scannen in verzonden gegevens van een versleutelde verbinding tussen client en server. Dit vereist configuratie en vertrouwen van alle betrokken partijen aan de clientzijde.
Als beheerders alles correct instellen, vergroot het de veiligheid doordat TLS-inspectie HTTPS-verbindingen kan bewaken zonder risico’s voor onversleutelde inhoud.
Je kunt TLS-inspectie instellen met Linux-tools Squid en iptables/nftables, maar dat is mogelijk te complex voor velen. Kant-en-klare firewallappliances hebben een minder steile leercurve.
Ze gebruiken dezelfde software en hebben een webinterface waarmee beheerders begrijpelijke regels en instellingen kunnen definiëren.
Opensource- en commerciële producten kunnen gratis worden gebruikt in kleine netwerken op eigen hardware. De tabel hieronder toont geschikte firewalldistributies voor webfiltering en TLS-inspectie.
Blijf op de hoogte omtrent alles wat met (cyber)security te maken heeft, schrijf je in voor de gratis nieuwsbrief:
Kun je ChatGPT gebruiken als hacking-tool? We neigden naar de duistere kant en onderzochten of de assistentie van een AI van elke scriptkiddie een eli...
Een kleine Raspberry Pi board is zo volgepakt met alle componenten dat er geen ruimte meer over was om de 40 GPIO pinnen van informatie te voorzien. O...
