D9ping

TLS 1.3 is de opvolger van TLS 1.2. Dat is het gebruikte communicatie protocol voor het opzetten en onderhouden van een beveiligde verbinding.
Zowel de webbrowser Google Chrome/chromium als Mozilla Firefox hebben TLS 1.3 ondersteuning nu toegevoegd aan hun webbrowser.
TLS 1.3 bied mogelijk betere beveiliging dan TLS 1.2 door nieuwe encryptie algoritmes(ciphers) toe te staan en oude onveilige encryptiealgoritme niet meer toe te staan. Zo is het gebruik van de stream cipher RC4 niet meer toegestaan. De RC4 cipher is inmiddels al jaren onveilig bevonden voor korte data mee te versleutelen. RC4 wordt standaard door webbrowsers al niet meer ondersteund of alleen in absolute nood nog gebruikt als de server echt niets beters kan gebruiken. TLS 1.3 biedt standaard geen ondersteuning voor terugvallen naar een oudere versie van het TLS protocol. Dat betekent dat als de webbrowser en server beide TLS 1.3 ondersteunen er geen oudere versie gebruikt mag gaan worden.
TLS 1.3 biedt ook enkele snelheidsverbeteringen door het gebruik van een pre-shared key(PSK) voor een TLS 1.3 verbinding met een server die al eens is gebruikt kan de sleutel uitwisseling direct versleuteld gebeuren in plaats van opnieuw overeenstemming te bereiken over een nog niet versleutelde verbinding over wat gebruikt moet gaan worden voor de beveiligde verbinding verstuurt moet gaan worden. Op deze manier is een beveiligde verbinding sneller en helemaal versleuteld met sleutel onderhandeling ook. Cloudflare bruikt o.a. al TLS 1.3 in productie en er zijn tot nu toe maar een paar kleine probleempje.

Sinds dit jaar heeft o.a. google een nieuwe ontwerp voor een standaard voor: SMTP Strict Transport Security. De beveiliging van SMTP is momenteel nog niet goed doordat bij het gebruikte STARTTLS het opzetten van een SMTP sessie tussen twee mailservers(MTA) en van een client(MUA) naar een mailserver(MTA) bijna altijd opportunistische encryptie(ongeldig of ongevalideerd certificaat) en/of onversleutelde verbindingen toelaat. Dit komt vooral vanwege de noodzakelijke compatibiliteit met andere mailservers(MTA) en misgeconfigreerde mail clienten(MUA). (Zorg ervoor dat je poort 587/submission met STARTTLS gebruikt en niet poort 25 voor e-mail verzending gebruikt). Wat betreft de communicatie tussen mailservers over poort 25 is de harde keuze is er alleen de keuze voor wel of geen e-mail uitwisselen als de verbinding alleen onveilig(bij geen STARTTLS ondersteuning) opgezet kan worden.

Er bestaat al enige jaren de HTTP Strict Transport Security header. Deze HTTP header wordt gezet na het opzetten van een veilige HTTPS connectie en zorgt ervoor de webbrowser voor een lange tijd onthoudt om alleen veilig verbindingen te maken met die website. Op die manier zal er bij terugkomst op de website nooit een downgrade van een veilige verbinding naar een onveilige verbinding kunnen plaatsvinden. De HTTP header wordt echter wel na een veilige HTTPS sessie gezet. Bij SMTP STARTTLS is dit niet mogelijk omdat de verbinding begint met een onveilige SMTP verbinding om te onderhandelen of dat encryptie gebruikt gaat worden. Nu maakt SMTP strict transport security gebruik van een TXT DNS record om het SMTP Strict Transport Security beleid te vinden op een subdomain _mta_sts.
Een mailserver die een e-mail naar een andere mailserver gaat versturen moet immer toch al via DNS het ip adres van de mailserver om mee te verbinden opzoeken. Maar omdat DNS onveilig is als er geen DNSsec gebruikt wordt moet dit DNS record weer gevalideerd worden met een JSON beleid over HTTPS. Want wanneer er geen DNSsec gebruikt op het domain moet nu het hele HTTPS protocol gebruikt gaan worden om de authenticiteit en integriteit van een SMTP Strict Transport Security DNS record te kunnen garenderen. Het SMTP Strict Transport Security lijkt me momenteel zonder DNSsec nog niet eenvoudig te implementeren wat het gebruik en de adoptie ervan voorlopig in de weg kan zitten. Wat jammer is want DNSsec en vooral DANE wordt nog steeds vaak niet ondersteund. Voorlopig blijft daarom e-mail verkeer tussen mail servers bijna altijd niet volledig veilig beveiligd.

Vanaf 2017 worden alle http:// pagina’s onder de google chrome(en chromium) webbrowser als onveilig weergegeven als er een invoer veld op staat. Dit betekend dat er nog meer noodzakelijk wordt voor webontwikkelaars al het web verkeer standaard over https aan te bieden. Het is gelukkig mogelijk gratis een certificaat te krijgen met o.a.:   Let’s Encrypt of anders StartCom(gestopt). Het Chinese WoSign geef ook gratis certificaten maar met deze certificaat authority zijn nogal wat probleempjes mee. Let’s Encrypt is makkelijk in gebruik als je beheer over de webserver hebt. Google zoekrobots gaven website’s die https gebruiken al een iets hogere vindbaarheid. Maar nu zal ook iedereen zich gaan storen aan de waarschuwing vanaf 2017 als je webpagina nog ongeautoriseerd en onversleuteld niet over https beschikbaar is. Omdat Chrome tegenwoordig een groot marktaandeel heeft qua webbrowser zal dit leiden tot een grote toename van https gebruik. Gaat het hele web dan nu wel over op https? Omdat ik niet wil dat deze website vanaf 2017 als onveilig getoont wordt ben ik alvast een Let’s encrypt certificaat gaan gebruiken i.v.p. een niet standaard vertrouwd certificaat.

Het SSL 3.0 protocol met CBC block encryptie is gekraakt. Het zijn werknemers van google erin geslaagd SSL 3.0 versleuteld verkeer te ontsleutelen. De aanval op het SSL 3.0 protocol om beveiling verkeer te ontsleutelen heeft de naam POODLE gekregen (de P in POODLE staat voor Padding). Het SSL 3.0 protocol is inmiddels al 18jaar oud het iets nieuwere TLS 1.0 protocol was in combinaties met CBC block encryptie algoritmes ook al gekraakt met de BEAST aanval. De POODLE aanval op zich zelf lijkt erg op de BEAST aanval om versleuteld TLS 1.0 verkeer met CBC block encryptie te ontsleutelen. Het oude SSL 3.0 protocol bevat in tegen stelling tot het TLS minder functionaliteit zo is het niet mogelijk meerdere SSL website op hetzelfde publieke ip adres te gebruiken iets wat met het nieuwere TLS 1.0/1.1 en 1.2 protocol wel kan. Momenteel is alleen TLS 1.1 en TLS 1.2 protocol nu nog veilig. Om ervoor te zorgen dat SSL 3.0 niet meer gebruikt wordt in Firefox kun je de SSLVersionControl extensie(niet meer) gebruiken of in je adresbalk naar about:config gaan en daar de instelling security.tls.version.min verhogen naar 1. De nog te verwachten Firefox 34 en later zal automatisch deze instelling hebben. Google Chrome gebruikers kunnen chrome opstarten met de –ssl-version-min=tls1 parameter om SSL 2.0 en SSL 3.0 niet meer te gebruiken. Veel webserver gebruiken helaas nog alleen TLS 1.0 dus je webbrowser geen TLS 1.0 laten gebruiken maar wel TLS 1.1 en hoger is, omdat TLS 1.0 dat met CBC block encryptie nog kwetsbaar is voor de BEAST aanval, is helaas nu nog vaak geen oplossing.