Krönika: "Lita på det gröna hänglåset?"

@rektor och @GilbertG. Jag nämnde bara två exempel. Utmärkt att ni fyller på med fler! Tack.

Precis.

EV validering går ju ut på att kolla "äktheten" genom att styrelsen är riktigt personer, företaget är korrekt registrerat i landet, kolla bokslut etc så det finns ekonomisk bärighet etc. Att domäner ägs av en organisation vars org.nr (eller motsvarande) stämmer med övriga register, underlag som bokföring etc. Dessutom kan det skilja sig kraftigt om certifikatutfärdaren och landet företaget befinner är olika, är ju inte så lätt att få ut register från olika länder. I slutändan handlar det om trovärdiga dokument och att registreringsnummer stämmer i de olika registrerna.

Jäkligt dryg process med EV, men hindrar ju inte om företaget har "tvivelaktiga" avsikter egentligen, det är garanterat säkert att du är på rätt webbplats som representerar företaget, men det finns ingen"total" säkerhet eller validering att företaget har goda avsikter.

Jag förstår inte heller varför krönikören tycker det är så extremt viktigt för en fri webb att allt måste vara gratis? Gratis är inte fundament för att "fritt" ska kunna existera. Vi har ju domänavgifter av den mycket enkla anledningen att det inte hade fungerat om det vore gratis (Inte så svårt att räkna ut varför..), detsamma gäller SSl certifikat. Det går utmärkt att använda egensignerade SSL certifikat, gör man på rätt sätt är dessa lika säkra som köpcertifikat och ger exakt samma funktioner som certifikat man betalar pengar för, enda nackdelen är att det poppar upp en varning att det ev inte är betrott, men trafiken är ju krypterad för det. Likaså kan jag sätta upp egna DNS servrar och ha egna domännamn också helt gratis, men det skulle ju bara fungera på mina enheter.

Gratis är inte detsamma som fritt!

Bra liten krönika! Roligt att läsa något som ligger lite utanför swec vanliga ämnen!

Det stämmer. Om du signerar ditt eget certifikat kommer alla datorer som du installerar det på att lita på det (och därmed ansluta krypterat och autentiserat). Detta blir lika säkert som att få ett certifikat från Let’s encrypt eller någon annan av certifikatutfärdarna. Nackdelen är att du i förväg måste förse alla klienter med certifikatet. När de har certifikatet installerat försvinner varningen (eftersom anslutningen då är säker).

Fördelen med att installera ett certifikat från en etablerad certifikatutfärdare är att de då har signerat certifikatet åt dig. Eftersom våra operativsystem har de etablerade certifikatutfärdarnas certifikat förinstallerade, litar de på alla certifikat som är signerade med dem. Det blir som en tillitskedja där datorerna litar på ditt certifikat i och med att de litar på utfärdarens certifikat.

Firefox har sin egen samling med certifikat. Om du vill använda ett eget certifikat i både Chrome och Firefox måste du därför installera certifikatet i både Windows/Mac OS (används av Chrome) och Firefox.

Ja, det har tyvärr varit mycket problem med säkerhetssviter och företagsbrandväggar som bryter upp krypterade TLS-anslutningar. Detta är möjligt för säkerhetssviterna i och med att de installerar sina egna rotcertifikat på datorn, så att anslutningen autentiseras mot säkerhetssviten som i sin tur autentiseras mot den faktiska servern. På samma sätt kan företagsbrandväggar bryta upp TLS-anslutningar genom att administratören installerar brandväggens eget certifikat på alla företagsmaskiner.

Jag förstår varför detta görs. Eftersom en allt större andel av trafiken blir krypterad måste säkerhetssviterna och företagsbrandväggarna bryta upp anslutningarna för att kunna inspektera innehållet. Utan att bryta upp anslutningarna kan de inte göra sitt jobb. Samtidigt måste uppbrytningen göras med stor noggrannhet och försiktighet, vilket tyvärr missas ofta idag. Vi har fått flera exempel på där säkerhetssviter och företagsbrandväggar nedgraderar säkerheten i anslutningar för att de inte stöder lika moderna tekniker som webbläsarna. För er som är intresserade kan jag rekommendera rapporten ”The Security Impact of HTTPS Interception” (https://kjll.cm/tlsinspec).

Jag håller med dig om att situationen är ganska tragisk just nu, men lösningen som finns är det bästa vi har. Den är trots allt bättre än att allt är helt okrypterat medan vi väntar på säkrare lösningar.

Det vill säga: Man kan inte alltid lita på det gröna hänglåset. Det säger att anslutningen är krypterad till någon endpoint (som inte behöver vara den riktiga). Det krävs certificate/public key pinning för att vara hundra på att den i andra änden besitter rätt certifikat (någon kan ju även ha snott den privata nyckeln för ex.vis Google), men fortfarande utan garant att det är rätt server man pratar med. Sannolikt är det rätt och man lägger säkerheten på denna nivå i nästan alla fall, men det är ingen garanti vilket är viktigt att förstå.

Detta vore ett intressant ämne. Som jag förstår det är DNS inte speciellt säkert alls. Finns många steg i kedjan som kan användas för att lura användare; modifiera Hosts-filen, byta ut DNS-servrarna, DNS cache poisoning o.s.v. DNS kom väl till på 80-talet, då man tänkte sig kanske ett hundratal datorer på olika universitet i ett nätverk. Alla kunde lita på alla och allt var frid och fröjd...

Just modifiering av inställningar på klienten (både hosts-fil och vilka DNS-servrar som operativsystemets ska använda vid namnuppslag) känns väl snarare som ett problem gällande den allmänna säkerheten på klientmaskinen; om någon obehörig har kunnat ändra detta så finns det massor av minst lika skadliga saker de skulle kunna göra istället.
Så att lösa att just detta ska vara säkert utan att radikalt förbättra den allmänna säkerheten på klientdatorn känns lite hopplöst.

Sedan kan man vara lite petig och påpeka att hosts-filen inte har med DNS att göra, däremot det större begreppet namnuppslag; hosts-filen är ju en del av ett äldre alternativ till DNS.

Vad gäller DNS i sig så är det ju precis som du är inne på ett protokoll som inte skapades med säkerhet i åtanke. Traditionellt så skickar man okrypterad och oautentiserad data över UDP.

Dvs, för den som sitter längs vägen trafiken går så är det möjligt att både se vilka frågor och svar som skickas samt även att ändra det som skickats utan att det märks.
Användandet av UDP lämnar även öppet för t.ex.:
* Att någon där ute fejkar avsändaradressen och försöker få in sitt påhittade svar först (måste gissa rätt port + id och komma först), grunden för att få till s.k. "cache poisoning"
* Att någon skickar frågor med fejkad avsändaradress för att få ett större svar skickat till den påhittade avsändaradressen, grunden för DNS-baserad amplifieringsattack.

DNSSEC adresserar specifikt bara att svar skickas utan autentisering. Dvs, det går med DNSSEC på plats inte längre att ändra eller hitta på svar hur som helst, detta OM frågan gäller en zon som är DNSSEC-signerad och resolverservern (helst även klienten) validerar signaturerna.

Med DNSSEC på plats i alla leden, så att man faktiskt kan ha viss tillit till data ur DNS, uppstår det en del intressanta möjligheter utöver att det förstås förbättrar säkerheten för dagens användningsområden.
T.ex. DANE, där man lägger information om vilket certifikat som är giltigt för ett visst domännamn i DNS. Dvs, ett klientprogram kan då själv kolla domänägarens avsikt gällande vilket cert som är acceptabelt, helt oberoende av CAs.