Posts Tagged ‘DNSSEC’

SMTP Strict Transport Security

vrijdag, oktober 28th, 2016

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.
TLS Strict Transport Security HTTP header
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.

DNS servers KPN gekraakt

maandag, februari 13th, 2012

Vorige week zaterdag gaf KPN een code rood qua beveilig situatie uit. Rede: hackers hadden toegang tot de interne netwerk van KPN gekregen via verouderde software op een van de servers van KPN. De hackers zeiden dat ze konden alles doen, ook hadden ze toegang tot de DNS servers van KPN. Als bewijs is het administrator wachtwoord voor het beheer van de DNS server op internet geplaatst.
De hack van de DNS server is ernstig omdat als de hackers daadwerkelijk de DNS servers aanpassen hadden een groot deel van de 2 miljoen klanten mogelijk niet meer de legitieme websites kunnen kregen. De meeste mensen kiezen gebruiken immers automatisch hun DNS server van de provider omdat hun router en besturingssysteem dat automatisch doet. Dit is ook weer een goede reden dat men DNSSEC implementeert, want de dns zones die met DNSSEC beveiligt waren konden door de kraakt op de dns server van KPN vervalst niet werken.
KPN kwam toen vorige week zondag uit met het statement dat er ‘geen gegevens gekopieerd waren maar alleen gezien’ echter is zo’n statement dubieus je kunt immers alles wat je ziet kopiĆ«ren. Dus een paar uur later plaatste een grapjas op pastbin.com, een populaire website voor het plaatsen van teksten, de klantgegevens van KPN klanten die uit een andere datalek (zoals er iedere dag zo veel zijn, kijk maar eens op datalossdb.org). Wat onder veel klanten tot onnodige paniek leed. En vervolgens heeft KPN terecht uit voorzorg, in eerste instantie. de mailserver offline gehaalt. Wat helaas voor KPN klanten tot veel hinder lijden, wat niet bepaalt ongemerkt ging.

SOPA gaat met DNS prutsen

maandag, december 19th, 2011

DNS servers vormen een gedeeltelijke kritisch onderdeel van het internet.
Een dns server zorgt ervoor dan een internet naam in ip adres nummers omgezet worden.
Hierdoor hoeft men geen nummers hoeft te onthouden om een website te bezoeken. Het ‘web’ en ook software is allemaal sterkt afhankelijk van dns.
DNS verkeer kan zowel TCP als UDP pakketjes zijn. In de praktijk zijn het bijna altijd UDP pakketjes.
UDP t.o.v. TCP is simpel, snel en onveiliger. DNS heeft jaren lang goed gewerkt omdat men zich er weinig mee heeft bemoeit. Echter de afgelopen jaren bleek het toch wenselijk te zijn dns verkeer tegen vervalsing te beschermen met DNSSEC.
Echter dreigt het vertrouwen in DNS wel eens ondermijnt te worden onder het nom van piraterij bestrijding.
SOPA is een nieuwe wetgeving van de verenigde staten die websites die piraterij veroorzaken, hun website dns zone deze niet meer correct laat functioneren.
Dit is onverstandig om dit te doen omdat de garantie dat een website dns naam je ook bij het juiste ip adres van de webserver brengt nu meer twijfelachtig geworden is.
Stel je gaat naar de website van je bank, je hebt het (dns) adres juist ingevult. Dan wil je echt zeker weten dat je de website van de bank krijgt.
Zoals ik al zei, dns werkt goed omdat we jarenlang (blind?) vertrouwen in dns servers hebben. Dat een dns server altijd het correcte resultaat teruggaf van de eigenaar van de desbetreffende dns zone van het adres van de website die je invulde.
Om correctheid van een dns zone echt te garanderen, i.v.p. er blind op vertrouwen dat je dns server correct is, is dnssec bedacht. Dnssec is dus een vrij gecompliceerde techniek is om te garanderen dat het dns resultaat klopt. Echter als door de nieuwe SOPA wetgeving kan de Amerikaanse overheid in dns servers in de VS, dns antwoorden gaan om websites die piraterij veroorzaken te blokkeren, echter doordat dns ongeautoriseerd is aangepast (niet door dns zone eigenaar) slaat DNSSEC hier juist “alarm”.
SOPA ondermijnt dus de DNSSEC technologie. Daarnaast werkt SOPA ook censuur in de hand want als een overheid een dns zone mag aanpassen dan gaan je een websites die ongewenste informatie over een overheid geeft, diep in de inhoud op auteursrechten problemen graven om onder dat de website te laten blokkeren. Gelukkig kun je feiten niet onder het auteursrecht laten vallen, echter SOPA is omstreden zeker voor grote media website met zowel legale bronnen als illegale bronnen, dan is het hele domein blokkeren hetzelfde als met een shotgun een mug schieten. Het kan ook anders. Allemaal even te snel en ingewikkeld? deze youtube video legt het nog eens uit.