Toppdomäners användande av TLS

Jag gjorde en snabb körning på hur det ser ut med TLS hos våra toppdomäner i världen. Med den nuvarande tillväxten av nya toppdomäner har vi idag 1082 delegerade toppdomäner i root, och det växer sakta tills dess att ICANN har delegerat alla nya toppdomäner.

Eftersom vi vill att TLS ska finnas på alla webbsajter är det intressant att se hur toppdomäner skyddar sin kommunikation med allmänheten. Så min första enkla analys är att helt enkelt se vilken URL man registrerat hos IANA, och se om de har https som default. IANA har en WHOIS-databas för toppdomänerna där man kan registrera sin webbsida. Detta har 1010 av 1082 toppdomäner gjort, dvs 93% av alla toppdomäner.

Men sedan kommer det lite nedslående resultatet. Tittar jag efter https i resultatet så är det bara 23 registryn som registrerat en webbsida med HTTPS:

am. https://www.amnic.net/
ar. https://nic.ar
bank. https://www.ftld.com/
bw. https://registry.nic.net.bw
cfa. https://www.cfainstitute.org
cloud. https://www.getdotcloud.com
fi. https://domain.fi
frl. https://registreer.frl
id. https://register.pandi.or.id
iq. https://registrar.cmc.iq
jo. https://www.dns.jo/login.aspx
lds. https://www.lds.org
lidl. https://www.nic.lidl
mo. https://www.monic.mo
mp. https://get.mp/
mt. https://www.nic.org.mt/
nl. https://www.sidn.nl/
schwarz. https://www.nic.schwarz
trust. https://nccgroupdomainservices.com
xn--j1amh. https://namestore.u-registry.com
xn--tckwe. https://www.verisigninc.com
xn--y9a3aq. https://www.amnic.net/
zm. https://registry.zicta.zm

Dvs, enbart 2% av alla toppdomäner har registrerat en webbsida som skyddas av HTTPS. En närmare analys ger förhoppningsvis ett bättre resultat, då man kanske glömt att registrera en webbsida med https istället för http.

Script:

Hela resultatet hos Pastebin.

 

27
Oct 2015
POSTED BY
POSTED IN DNS Säkerhet Svammel
DISCUSSION 0 Comments
TAGS

Många alternativa programvaror för DNS

Nästan alla kör BIND från ISC för sin DNS. Så är det bara. Men det finns många nya alternativa namnservrar som är minst lika bra, och som inte lider av det kod-arv som BIND 9 gör. BIND har skrivits om från grunden två gånger i modern tid, först från BIND 4 till BIND 8, och sedan till BIND 9. Ett tredje försök har gjorts under de senaste åren från ISCs sida, nämligen med det havererade BIND 10-projektet. ISC har dock varit väldigt öppna med hur och varför projektet havererade, och det är bara att konstatera att vi kommer att få dras med BIND 9 ett väldigt långt tag framöver.

 

Men under de senaste åren har ett par riktigt bra alternativ till BIND tagits fram av andra aktörer. Min favorit för auktoritativ DNS är Knot DNS från CZ.NIC. Som också ISC själva säger, framtida DNS-innovation kommer sannolikt att komma från andra aktörer än ISC. Ett av de nuvarande problemen med BIND är att den försöker göra allt. Den är både auktoritativ namnserver, och cacheande resolver, och säkert mycket annat också samtidigt. Knot DNS är “nästan bara” en auktoritativ namnserver. Men i nuvarande versioner har de även lagt till online-signering för DNSSEC, och kommer att i version 1.6 komma närmare OpenDNSSEC vad gäller hanteringen för nyckelsigneringspolicy – något som andra DNS-programvaror saknar helt. Man håller också på att byta från OpenSSL till GnuTLS, dels av kända anledningar, och dels för att GnuTLS har betydligt bättre stöd för PKCS#11, något som krävs om man vill använda HSM:er. Vidare har man även möjlighet att köra sina egna moduler för att utföra dynamisk hantering av DNS-svar, och för IPv6 kan man exempelvis också dynamiskt generera reverse-svaren för IP-adresserna. Se gärna presentationen från RIPE68.

Själv har jag kört Knot DNS ett långt tag på en av mina egna namnservrar. Den är både betydligt enklare att konfigurera, men den har också betydligt bättre prestanda än BIND. Något som jag förvisso inte har något större behov av, eftersom mina domäner inte drar särskilt mycket trafik. Som ett alternativ till Knot DNS finns också självklart NSD 4 från NLNet Labs, som har funnits betydligt längre, och används kanske mest av TLD:er idag – men också Yadifa från EURid.

Unbound

För att köra en cacheande resolver så kan man med fördel använda Unbound, också från NLNet Labs. Unbound har också givetvis fördelarna med att den är betydligt enklare att konfigurera, och har betydligt högre prestanda än BIND. En cacheande resolver kör man med fördel med DNSSEC påslaget för DNSSEC-validering, så nära de tjänster man har som behöver lita på DNS (det är i princip samtliga internet-tjänster).

Om man känner sig lite osäker på att behöva byta från BIND kan man kanske titta på antalet kända sårbarheter… Och som med alla monokulturer, de är sårbara för breda attacker. Därför är det också bra att börja köra alternativa programvara. Gärna på någon udda  CPU-arkitektur, så att inte alla kör Intel.

(Jag har fullständigt medvetet inte skrivit om programvaror som inte är öppen källkod.)

24
Jun 2014
POSTED BY
POSTED IN DNS
DISCUSSION 2 Comments
TAGS

DNS Privacy – krypterad DNS

I en serie poster tänkte jag nu framöver posta lite mer renskrivna texter om DNS från mina anteckningar på olika internet-konferenser. Jag hoppas detta kan vara till glädje för någon som är intresserad av vad som händer i DNS-världen.

DNS har funnits i drift i över 25 år. Det är bara under de senaste 15 åren som säkerhet i protokollet diskuterats, och 2005 gick RFC:erna för DNSSEC genom IETF. Men kravet i protokollet för att skydda den personliga integriteten har aldrig funnits – förrän under det senaste året.

Med anledning av Edward Snowdens avslöjanden så har IETF sakta börjat se över de protokoll som IETF i någon form ansvarar för, och med publiceringen av RFC 6973, “Privacy Considerations for Internet Protocols” så kan man säga att arbetet satt igång på allvar. Inom IETF har man också satt upp en mailinglista för att diskutera “pervasive surveillance” med ett lite bredare perspektiv, perpass@ietf.org.

Gamla protokoll designades i en annan tidsålder, innan övervakning var på agendan. Dessa protokoll läcker mycket för mycket metadata (och data). Men det finns många begränsningar i dessa protokoll som kan förhindra eller försvåra att man gör tillägg för att gynna den personliga integriteten såsom latency, stabilitet och att protokollen blivit universella.

En DNS-fråga avslöjar vem som frågar, och vad som frågas efter. Detta underminerar säkerheten i andra protokoll, som till exempel HTTPS. Vad finns då i qname-delen av en DNS-fråga? “www.political-party.example”, eller “_bittorrent-tracker._tcp.domain.example” – MPAA kan vara intresserade. “le-pc-de-pascal.domain.example” – personlig information, eller t.ex. PGP-nycklar i DNS. Helt enkelt saker som avslöjar saker om ditt internet-beteende som de protokoll du använder dig av normalt kanske skyddar – men där informationen skickas i klartext i DNS. Detta beteende i DNS vill man ju ändra på.

Vi behöver en lösning för att skydda informationen “on the wire” och “på servern”. Resolvrar kan också läcka information genom t.ex. sysadmins, och en cache innehåller också all denna information i klartext. Att skydda DNS-informationen på protokollnivå kräver dock ändå olika lösningar, en för att skydda klient-kommunikationen mot en resolver, och en annan för att skydda kommunikationen från en resolver till auktoritativa namnservrar.

Från att ha diskuterats på perpass flyttade diskussionen till dnsop, och nu är flyttad till en egen dnsprivacy-lista. Det finns en möjlig lösning implementerad (men inga andra), DNSoverTLSoverTCP. Ingen officiell working group ännu, men vem som helst kan ändå posta förslag till IETF.

Problem statement: draft-bortzmeyer-dnsop-dns-privacy – problemet behöver dokumenteras innan man kan lösa det…

Minimizing the qname – fulla frågenamnet behöver inte skickas till auktoritativa namnservrar högre upp i hierarkin. Detta går att implementera i Unbound och BIND, men ingen har gjort det ännu. Påverkar DNS-OARC och DITL, eftersom informationen att göra forskning på minskar. Vilket ju också är lite av poängen…

Tyvärr förekommer det alldeles för lite diskussion om dessa förslag på listorna, och intresset verkar lågt (trots riktigt stora möten på IETF). Att förändra DNS är också väldigt svårt.

Efter förra helgens DNS-OARC-möte skickade Paul Vixie ett mail till IETF:s dnsop-arbetsgrupp och uttalat sitt stöd för minimering av innehållet i frågorna, så det arbetet kanske tar lite fart igen.

21
May 2014
POSTED BY
DISCUSSION 0 Comments
TAGS

När DNS ljuger

Man kan väl minst sagt konstatera att DNS hamnat i fokus den senaste veckan, inte minst i ljuset av Verisigns ompekningar av ett större antal domäner, men också Wikileaks problem med att vara tillgängliga. Senast ut med Wikileaks är att deras DNS-tjänst som sköttes av EveryDNS plockade bort wikileaks.org från sina namnservrar. Anledningen är att namnservrarna utsattes för en DDoS-attack, vilket skulle få nästan vilken leverantör som helst att ta bort det domännamn som är orsaken till problemet, eftersom detta går ut över alla andra kunder.

Företaget Renesys, känt för sina rapporter om olika aspekter av Internet, mer eller mindre bra, har i en bloggpost skissat på ett litet betygssystem för hur DNS hanteras i olika länder. Vi vet ju att man från operatörshåll i Sverige filtrerar visst innehåll. Så hur illa är detta i Renesys betygssystem? Först listar jag detta betygsystem här:

★★★★★

Entirely safe. Providers in this country respect DNS integrity and never rewrite DNS responses. Even if you mistype a domain, you get an obvious non-existent domain (NXDOMAIN) error message and not an advertisement. When asking questions you always receive the intended answers.

★★★★

Mostly safe. Providers in this country are allowed to rewrite queries to unknown domains to make money, but otherwise they leave DNS alone.

★★★

Use caution. In this country, DNS providers may be required to modify the recursive resolver responses in order to enforce local content laws.

★★

Strong caution. In this country, ISPs may be required to modify the recursive resolver responses in flight in order to enforce local content laws. In other words, ISPs listen in on your requests and alter the responses, no matter which server you query.

Danger. In this country, root server responses as well as recursive responses may be modified in flight, without warning, by any infrastructure providers.

Så var hamnar Sverige på betygsskalan? Den filtrering som görs sker ju på frivillig basis, men där Rikskriminalen tar fram blocklistorna. Dessa blocklistor är dock inte offentliga. Jag skulle nog påstå att Sverige får ★★★★. Men detta kan ju snabbt ändras. Vi har ju inga lagar om att innehåll måste blockeras av operatörerna genom DNS.

Men som vanligt, kör din egen DNS om du inte litar på hur andra gör. Och använd DNSSEC för att detektera omskrivningar av DNS-svar. Vid DNSSEC-validering måste man dessvärre signera sina domäner med DNSSEC, och till en utbredd användning här har vi en bit kvar.

03
Dec 2010
POSTED BY
POSTED IN DNS Säkerhet
DISCUSSION 3 Comments
TAGS

En kommande fragmentering av DNS

Med anledningen av att den “amerikanska regeringen” (Immigration & Customs Enforcement inom Department of Homeland Security) för snart en vecka bad Verisign peka om ett antal .com-domäner till en spärrsida liknande den som svenska ISP:er på frivillig basis implementerat mot barnpornografi, så har piratnördarna med Peter Sunde i spetsen skapat något slags initiativ för att bygga en P2P-baserad DNS-toppdomän, .p2p.

De krav (eller “mål”) som man har med detta är att få till en toppdomän där innehållet inte går att filtrera på det sätt som gjorts ovan. Men för att ta ett mål i taget, från deras wiki:

  • Undgå den “kontroll” som ICANN har idag. Ja, ICANN har inte särskilt mycket kontroll över ccTLD:er som t.ex. .se idag. De kan förstås tillsammans med NTIA ta bort .se från kartan, men det blir med största sannolikhet förhållandevis ganska komplicerade diplomatiska förhållanden mellan Sverige och USA då, samtidigt som ICANN förminskar sin egen roll genom minskat förtroende. Risken för detta är minimal. Att servera sina domäner under .com som drivs av ett amerikanskt företag har ju visat sig vara ödesdigert, men då borde slutsatsen vara att köra sina domäner under toppdomäner som har lagstiftning och myndigheter som man vet hur man uppför sig.
  • Kryptera DNS-uppslagningarna genom mekanismer i P2P-lösningen. Visst, det är ju bra. Men allt som skjuts långt bort i nätet, och bygger på någon form av realtidskrypto sänker prestandan. Nu kan man ju argumentera för att med högre säkerhet och anonymitet, så kan man offra prestanda. Nu har P2P-nät mycket sämre prestanda än DNS ändå, så oavsett vad man gör så blir uppslagningarna långsammare än vanlig DNS. Dessutom vill man inte göra särskilt mycket avancerad krypto i sådana här protokoll, eftersom detta lätt leder till DoS-attacker riktade mot den som ska validera signaturer eller dekryptera information.
  • Återanvända så mycket färdig bittorrent-kod som möjligt. Jag förstår inte varför detta ska vara ett mål, det känns som en teknikerlösning på ett teknikerproblem. Först designar man ett protokoll, sedan tittar man på om det finns färdig kod som kan lösa implementationsbiten.
  • Stöd för .p2p i alla OS och applikationer, genom “open source”. Ja, det är ju bra. Men det är inte så man designar protokoll. Man gör det genom att skriva extremt bra specifikationer som har flera oberoende implementationer, som faktiskt fungerar mellan varandra.
  • Denna uppslagningsmekanism ska inte påverka det övriga DNS-systemet, och här vill man inte betraktas som ett malware. Bra. Men svårt att undvika, eftersom vem som helst kommer att prångla ut “Phree Warez for the .p2p-domainz!1!”-applikationer, eftersom detta inte kommer att ingå som en standardkomponent i ditt operativsystem.
  • Zeroconf. Bra, men det är ju egentligen ingen protokollfråga, utan upp till den specifika applikationen att avgöra. Dessutom kan ju implementationen bara bli zeroconf i klientläge, knappast i den del som ska servera namn till .p2p-namnrymden.
  • Uppslagningsmekanismen ska vara säker och krypterad (sista punkten, end2end…). Ja, why not. DNS är ju inte krypterat idag, även om det förekommit flera förslag på hur man gör detta. Och med DNSSEC kan du vara säker på att DNS-svaren inte är manipulerade.

Min betraktelse här är att kravspecifikationen på ett nytt DNS-liknande protokoll så här långt är väldigt luddiga. Det är en massa önskemål. Men ingen information om hur man publicerar namn, vilka nycklar man ska lita på, och vem som litar på vem. (Det finns något obegripligt om web-of-trust och GPG.) Men mycket Alice and Bob blir det.

Rick Falkvinge har ökat på förvirringen genom att hävda att DNS redan är fragmenterat. Detta baserat på att man i Danmark har lagstiftat att operatörers resolvrar måste filtrera ut piratebay.org. Lösningen ovanför (vad den nu blir) kommer inte att lösa andra resolvrars DNS-filtrering. Här är lösningen givetvis att köra sin DNS-resolver själv. Men det måste man ju ändå om man ska få DNSSEC att skydda DNS-informationen hela vägen till klient-datorn. För det gör ni väl?

Jag är positiv till allt som utvecklar Internet och DNS. Men man löser inte diffusa problem med diffusa tekniska lösningar. Jag gissar att målet i förlängningen är att helt ersätta DNS, men att man vill börja med .p2p, eftersom det är något rimligare. Det är bra. Men då måste man modellera protokollet med vad DNS idag hanterar. Annars kommer det att bli något annat, och då ska man nog inte parasitera på DNS-namnrymden ens.

01
Dec 2010
POSTED BY
POSTED IN DNS Hacks Svammel
DISCUSSION 3 Comments
TAGS