Secure sockets layer (ssl) is niet zo secure als de naam doet vermoeden. SSLv1 en SSLv2 werden al snel na introductie als ‘niet veilig’ beschouwd. Ook het SSLv3-protocol is een bekend doel van aanvallen op zowel het gebruikte mechanisme voor de key exchange als het encryptieschema dat wordt gebruikt. Hoe dan wel?
Om dit op te lossen, werd in 1999 transport layer security 1.0 (TLS1.0) als opvolger geïntroduceerd, gevolgd in 2006 met TLS1.1 en in 2008 met TLS1.2. Om de compatibiliteit tussen verschillende systemen te optimaliseren, beschikt de tls-standaard echter over de mogelijkheid om terug te vallen op SSLv3. Daar gaat het fout, want juist deze mogelijkheid om terug te vallen op de niet veilige SSLv3-standaard maakt ook tls onderwerp van gesprek.
Lapmiddelen
Het gevolg is dat de browser-ontwikkelaars druk in de weer gaan met hun ondersteuning voor SSLv3. Chrome 39 stopt met fallback en Chrome 40 stopt volledig met SSLv3. Firefox is al gestopt met de ondersteuning en ook Microsoft stopt de ondersteuning in de komende periode.
Eind 2014 bewees het Google security-team met de Poodle-aanval dat met een man-in-the-middle exploit tls kwetsbaar is, juist door terug te (kunnen) vallen op SSLv3. Daarnaast zijn de binnen TLS1.0 gebruikte symmetrische encryptie algoritme RC4 en de cryptografische hash MD5 als onveilig verklaard. Daarmee werd heel TLS1.0 als onveilig bestempeld en zal Google ook stoppen met ondersteuning voor SHA-1-certificaten in 2016/2017. Steeds meer fabrikanten meldden zich dat men kwetsbaar is voor bepaalde ssl- en tls-verbindingen.
Hoe moet het dan wel?
In de nieuwe draft voor een IETF (Internet Engineering TaskForce) standaard ‘thomson-sslv3-diediedie-00’ staat dat momenteel uitsluitend TLS1.2 als veilig wordt gezien, en gebruikt moet worden. De key exchange (sleuteluitwisseling) en de encryptie-methodes (ciphers), in combinatie met beperkingen in de terugvalmogelijkheden op oude standaarden, zorgen ervoor dat deze methode van verbinden momenteel als enige als veilig wordt gezien.
Maatregelen
Binnen uw eigen omgeving moet je beoordelen welke veilige verbindingen worden opgebouwd. Hierbij moet je niet alleen denken aan webservers, maar ook aan managementsystemen en zeker de wijze waarop bijvoorbeeld applicatie, desktop virtualisatie en vdi-systemen zijn ingericht.
Enerzijds zul je op de clients aanpassingen moeten uitvoeren, en toegestane browsers en vpn-clients/receivers bepalen. Ook de serversystemen moeten worden aangepast, zodat ze alleen TLS1.2 ondersteunen. Het aanpassen van servers is afhankelijk van het besturingssysteem en een tijdrovende zaak die uitsluitend tijdens service windows kan worden uitgevoerd. Daarom is het aan te bevelen om een proxy te gebruiken voor ssl/tls. Deze proxy kan in eerste instantie TLS1.2 ondersteunen richting de clients,, zonder aanpassingen aan de servers. Hierna kun je tijdens de service windows de servers aanpassen in je eigen tijdslijn. Hierbij is het van belang dat de ssl/vpn-concentrator TLS1.2 ondersteunt.
Veiligheid garanderen blijft een heikel punt, maar zeker als nieuwe standaarden koppelingen blijven maken met oude, niet veilige varianten komen we niet verder. Soms moet een grotere stap worden gezet om echt vooruit te komen.
Beheerders van websites moeten de ondersteuning voor SSL3.0 (en eigenlijk ook al TLS1.0) uitschakelen. Maar nog genoeg beheerders lopen te slapen (of zijn gewoon incompetent).
https://www.trustworthyinternet.org/ssl-pulse/ (zie Protocol Support)
Hugo, ik vind dat je nogal kort door de bocht bent, niet in de laatste plaats omdat je zelf een relevante fout maakt!
Niet de beheerder van de website, maar de beheerder van de webserver is verantwoordelijk voor de inrichting van SSL!
Ik kom nogal wat incompetente beheerders tegen (jij vast ook) maar ik beoordeel dat dan toch liever op wat meer kriteria.
Goddank hoef ik dat soort ellende niet meer te beheren.
@Hugo,
Ook ik beoordeel incompetentie niet zo snel en inderdaad zoals Pascal aangeeft ook op basis van wat meer criteria.
Je hebt het hier weer gelijk over websites maar dit gaat veel verder dan websites. Binnen windows platformen zijn er diverse services aan te wijzen die SSL / TLS gebruiken zoals: Remote Desktop services, Remote Access (VPN), SQL components, SMTP relay etc etc. Ik mis in dit artikel de opmerking dat TLS 1.2 bv alleen maar vanaf windows 2008R2 aanwezig is en dat iedere lagers OS versie dus in essentie niet veilig is als 1 van de bovenstaande services draaien. Dit heeft dan nogal wat meer impact dan je webserver aanpassen of je client. Je dient namelijk volledige systemen te upgraden of herinstalleren. Dit gemakshalve vergeten getuigd meer van gebrekkige kennis van zaken. Incompetentie zou ik het niet durven nomen.
@Han
Je maakt een goede opmerking door te stellen dat TLS1.2 niet ondersteund wordt door veel (oudere) services en websites. Daarnaast kost het aanpassen een enorme hoeveelheid tijd, wellicht meer tijd dan er servicewindows zijn.
Maar gelukkig heeft ook daarvoor de industrie een oplossing. Zoals Jack aangeeft ligt de oplossing in een Application Delivery Controller (ADC) die als Full Proxy tussen de server en de client wordt geplaatst. Deze ADC laat naar de client alleen TLS1.2 toe en richting de server binnen het trusted Data Center het oorspronkelijke protocol. Zo kun je snel een groot aantal servers beveiligen.
Deze slimmigheid wordt ook toegepast bij IPv4 – IPv6 conversie, HTTP1.1 – HTTP/2 conversie, et cetera.