image

Firewalls worstelen met SSL-decryptie

vrijdag 14 juni 2013, 13:47 door Redactie, 8 reacties

Op dit moment is het nog niet mogelijk om versleuteld verkeer over de gehele bandbreedte via Deep Packet Inspection te inspecteren, de hardware kan het gewoon nog niet aan. Dat stelt John Pirc van onderzoeksbureau NSS Labs. Hij onderzocht de prestaties van verschillende Next Generation Firewalls (NGFW) bij het ontsleutelen van SSL-verkeer en de resultaten zijn schokkend.

Op dit moment is SSL-verkeer verantwoordelijk voor 25% tot 35% van al het verkeer bij bedrijven. In sommige gevallen piekt dit naar 70%. Als het gaat om het inspecteren van SSL-verkeer dat een 1024-bit cipher gebruikt, dan is er een gemiddeld prestatieverlies op de bandbreedte van 74%.

Dreiging
Uitgevers van SSL-certificaten stoppen vanaf 31 december dit jaar met het uitgeven van SSL-certificaten met een 1024-bit cipher. De standaard wordt dan 2048-bit. Bij deze certificaten is er een gemiddeld prestatieverlies van 81% op de bandbreedte. Als er wordt gekeken naar het aantal verloren transacties per seconde dan is dit bij een 2048-bit cipher 92,3%

"Hoewel de prestaties reden tot zorgen zijn, is de aanwezigheid van malware binnen versleutelde kanalen een realistisch, maar relatief kleine dreiging in zakelijke omgevingen die het ontsleutelen en scannen als best practice rechtvaardigt", stelt Pirc. Hij adviseert een oplossing die het verkeer niet direct op de firewall ontsleutelt.

Reacties (8)
14-06-2013, 15:06 door Orion84
Voor de hoofdmoot van de encryptie / decryptie worden die 1024 / 2048 bits a-symmetrische ciphers toch helemaal niet gebruikt? Daarvoor worden snelle symmetrische ciphers zoals AES en RC4 gebruikt (waar deze toename in key-strength ook helemaal niet op van invloed is).

Apart dat dat dan toch zo'n verschil maakt. Of zou dat komen omdat die firewalls continu nieuwe verbindingen moeten afhandelen, waardoor ze wel veel met de a-symmetrische crypto stappen bezig zijn?

Ah, even het artikel gelezen: de test gaat uit dat er per transactie een handshake + 1 get request plaatsvindt. Dan kan ik me inderdaad voorstellen dat de key strength voor de handshake wel behoorlijke invloed heeft ja.

Ik vraag me wel af hoe realistisch zo'n test is. Iemand hier die daar inzicht in kan geven?
14-06-2013, 16:10 door [Account Verwijderd]
[Verwijderd]
14-06-2013, 16:11 door AcidBurn
Ik vraag me wel af hoe realistisch zo'n test is. Iemand hier die daar inzicht in kan geven?

Het is zeker realistische. Ik heb het zelf vorig jaar getest met een Sonicwall Appliance, prachtige firewall maar zodra ik DPI aangezet had was het werken op een Citrix omgeving achter de firewall een compleet drama. Niet alleen werd het minder responsive, soms ook gewoon timeouts op de verbinding.
14-06-2013, 16:12 door AcidBurn
Door pe0mot: Kan het niet volgen, de 2048 is inderdaad voor het authenticatie certificaat, niet voor de encryptie sleutels.
DPI wil de inhoud zien, niet het certificaat. Maar voor de inhoud is de key plus de IV niet bekend.
Dus het artikel ook maar even gelezen.
Kan het nog steeds niet volgen, gaat het hier over DPI met een bekende sleutel, of gaat het hier over high speed VPN dozen?

Het gaat over het decrypten van SSL versleuteld verkeer wat door een firewall heen gaat.
14-06-2013, 16:15 door [Account Verwijderd]
[Verwijderd]
14-06-2013, 21:20 door Anoniem
Door Orion84: Voor de hoofdmoot van de encryptie / decryptie worden die 1024 / 2048 bits a-symmetrische ciphers toch helemaal niet gebruikt? Daarvoor worden snelle symmetrische ciphers zoals AES en RC4 gebruikt (waar deze toename in key-strength ook helemaal niet op van invloed is).

Apart dat dat dan toch zo'n verschil maakt. Of zou dat komen omdat die firewalls continu nieuwe verbindingen moeten afhandelen, waardoor ze wel veel met de a-symmetrische crypto stappen bezig zijn?

Ah, even het artikel gelezen: de test gaat uit dat er per transactie een handshake + 1 get request plaatsvindt. Dan kan ik me inderdaad voorstellen dat de key strength voor de handshake wel behoorlijke invloed heeft ja.

Ik vraag me wel af hoe realistisch zo'n test is. Iemand hier die daar inzicht in kan geven?

Mijn natte-vinger gevoel gaat wel in die richting.
Zolang SSL geen 'standaard' is, kun je inderdaad wel verwachten dat een behoorlijk deel van het SSL verkeer alleen de transacties zijn die veilig 'moeten' zijn (inloggen, betalen) terwijl de bulk-site in plain http gaat.
En van dat soort inlog of andere authorisatie access kan ik me wel voorstellen dat het een korte transactie is, en dat handshake/public key dan groot is ten opzichte van de 'bulk' data.

Pas als het erg normaal is dat alle webverkeer via SSL verloopt, zal het deel sessie-setups ten opzichte van transport verkeer wat kleiner worden.
Het totaal aantal sessie setups wordt dan natuurlijk wel groter, want dat zijn dan gewoon 'alle' web sessie setups.
16-06-2013, 12:51 door Anoniem
Als het om een relatief kleine dreiging gaat waarom er dan toch zo groot op in willen zetten? Wordt de angst van bedrijven nu niet misbruikt om via DPI een totaal overzicht te verkrijgen binnen versleutelde verbindingen? In hoeverre kunnen we dan nog vertrouwen op een versleutelde verbinding als deze via DPI eenvoudig uit te lezen is? Als een device het kan dan kan een mens het ook.
Ik vrees dat het verkeerd gaat aflopen met de encryptie zoals we deze ten heden dagen kennen, want niemand vertrouwd het straks meer.
18-06-2013, 20:49 door Anoniem
Je verspilt je tijd met het monitoren van gebruikers. Besteed eens aandacht aan network security monitoring (besteed er ook tijd aan), endpoint protection voor servers, centrale logboeken, standaardisatie van software deployment, een serieuze Certificate Authority, private vlans, en wellicht dingen als host-based IDS oplossingen voor servers in je DMZ.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.