Nettlesere har de siste årene fått mye spennende teknologi for å gjøre hverdagen på nett enda tryggere. I samme stil som SSL Labs med deres test for oppsett av sikker HTTP (TSL/SSL), har vi nå securityheaders.io. Mål nummer én var å lære mer om disse standardene, og mål to selvsagt å få en A+ selv. HTTP-headere (sikkerhetshoder) sendes etter at autentisering og kryptering er startet ved TSL/SSL, men før HTML og innhold blir overført mellom server og klient. Og alt dette påvirker bare klienter, dersom "hodene" støttes.



Innledningsvis skal det sies at det er mulig å få en høy score på denne testen, uten at sikkerhetsnivået nødvendigvis blir noe bedre, nettopp fordi det er mange måter å konfigurere dem opp på. Det er nå 6 hoder som sjekkes:

x-xss-protection, X-Content-Type-Options og X-Frame-Options er alle veldig trivielle. Den første aktiverer beskyttelse mot "cross site scripting" i nettlesere som støtter dette. Anbefalt er "X-XSS-Protection: 1; mode=block". Den andre skrur av gjetting av "filtype" der serveren eksplisitt deklarere såkalt MIME-type. Settes til "nosniff". Den tredje brukes for å begrense muligheten for at siden kan bli "framed" ("vist inni et vindu på en annen side"). "SAMEORIGIN" anbefales for denne.

strict-transport-security forteller nettleseren at, fra og med nå, skal du ikke be om noe fra mitt domene uten at det går kryptert over HTTPS. Det er selvsagt viktig å ikke sende denne headeren dersom deler av nettstedet fremdeles serveres ukryptert. Man konfigurerer "max-age" til antall sekunder dette skal gjelde. Denne verdien oppdateres/"nullstilles" hver gang nettleseren henter ned en ny side fra nettstedet.

Content-Security-Policy og Public-Key-Pins krever begge en del omtanke før de settes i drift. Den første er ganske interessant. Den er en slags "brannmur" for hvilke ressurser (javascript, bilder, video, css osv) som denne siden tillater seg selv å laste inn. Slike ressurser kan både lastes inn via filer, og de kan være "inline", dvs. lagt direkte inn i HTML-siden. Og siden inline kode typisk er det innbrytere prøver å lure inn på populære nettområder, er innline script og css som standard deaktivert. Her er det altså store muligheter for å knekke masse funksjonalitet om headeren blir implementert for strengt.

Jeg valgte en variant slik som dette:

default-src 'self'; style-src 'self' 'unsafe-inline'; script-src 'self' 'nonce-{{csrf-token}}'

Jeg tillater i utgangspunktet bare ressurser fra eget domene. For css måtte jeg tillate inline (via "unsafe-inline") grunnet at Djangorammeverket bruker inline når den lager skjema. For javascript (script-src) har jeg noen få inline script-snutter her og der i forbindelse med noen grafer. En rask fiks var derfor å bruke "nonce" (et tilfeldig nummer) satt til djangos csrf-token. Den er dermed unik per besøkende, og jeg slipper å måtte bruke en "unsafe-inline" generelt. Et greit kompromiss slik jeg ser det. Se blant annet html5rocks.com for mere detaljer.

Public-Key-Pins ber nettleseren om å huske et sett med sertifikater, som den så skal bruke for å nekte å koble til dersom klienten ikke gjenkjenner noen av sertifikatene ved en senere anledning. Alle sertifikatutstedere kan lage sertifikater for alle domener, og dette tiltaket lager en binding mellom det som faktisk er autentisk og domenet, slik at eventuelle "falske" (men gyldige) sertifikat nektes. Denne headeren kan være litt "skummel", siden det er fort gjort å "låse seg selv ute" dersom man endrer sertifikatutsteder eller privat nøkkel. Det er derfor krav om minst én reservenøkkel. Som nevnt må bare ét av sertifikatene matche et gyldig sertifikat, og man kan velge å "pinne" hvor man vil i sertifikatkjeden. Man kan altså pinne mot et root-sertifikat (sertifikatutstedere), en intermediate CA, eller man kan pinne mot eget sertifikat (mer kontroll, større risiko). Man kan selvsagt legge til nye reserver underveis, så lenge forbindelsen blir godkjent. En pinning/(reserve)nøkkel er en hash-verdi basert på den offentlige nøkkelen, som både er i sertifikat og i CSR (certificate signing request). Så lenge den ikke endres, f.eks. ved resignering av CA, vil hash-verdien være lik. En gyldighetsperiode brukes for å instruere nettleseren hvor lenge bindingen skal gjelde, og denne oppdateres også for hver gang nettleseren mottar en gyldig oppkobling mot domenet.

Jeg fant masse gode tips på scotthelme.co.uk og timtaubert.de.

Oppdatering Det viser seg at man må bruke dobbelquote (") rundt sha256-verdiene i public-key-pinning. Jeg hadde brukt enkeltquote (') og fikk derfor failed på SSLlabs test. Fikset det, og gikk opp til A+. Det er viktig å ha minst én reservenøkkel, samt en max-age større enn 0. Jeg kom også over en ganske artig artikkel om feil bruk av key-pinning.

Public-Key-Pins:pin-sha256="ntaa4dzdzEmjCVMrlFOJTlfUQJKu3LoMqi1qlyCjoek="; pin-sha256="orne4NMB+gRZ5FIMhpzlzLZQ/M6Xk6ml0Fd/c6qp2lQ="; pin-sha256="181NMJKq1c28dYCENy2lsu33dkifRayer4wlWhYAoRg="; max-age=5184000;

Norge.no har oversikt over Norske offentlige digitale tjenester. Det de fleste av tjenestene har til felles, er at de trenger å bekrefte din identitet. Direktorat for forvaltning og IKT drifter derfor en felles portal kalt ID-porten som tar hånd om innlogging på vegne av alle disse tjenestene. ID-porten er en "single sign on"-løsning, der du (nettleseren din) i praksis blir logget inn hos alle som bruker ID-porten. Hvis du f.eks. logger inn på Skatteetaten for å sjekke selvangivelsen din, kan du gå rett videre til NAV for å sjekke din pensjon, uten å måtte logge inn på nytt.

Elektronisk bekreftelse av identitet har to viktige dimensjoner.

• Knyttning mellom fysisk person og elektronisk identitet (utstedelse).
  
• Mekanisme for identifisering (autentiseringsmekanisme). For eksempel brukernavn/passord, kode på SMS, kode fra kodegenerator, kode fra skrapekort osv. De fleste kodegeneratorene er basert på en form for asymmetrisk kryptografi som enten er tid eller sekvensbasert.

Se forøvrig dette blogginnlegget for en fin forklaring. I Norge er det 4 sikkerhetsnivåer for elektronisk identiet, definert i Rammeverk for autentisering og uavviselighet i elektronisk kommunikasjon med og i offentlig sektor



Det er opp til den offentlige tjenesten å vurdere krav til sikkerhetsnivå for sine tjenester. Difi's dokumentasjon Integrasjonsguide for ID-porten forklarer hvordan innloggingen (fødereringen) fungerer. Som figurene viser er løsningen svært "klient-tung". Den XML-baserte protokollen SAML 2.0 benyttes for å overføre informasjon mellom tjeneste og ID-porten, via brukerens klient. Se forøvrig denne siden for en fin forklaring på grunnleggende SAML.



Difi tilbyr også et "kontakt- og reservasjonsregister" med e-post og telefon, samt status på om bruker har reservert seg fra digital kommunikasjon (At de vil ha alt på papir). Steg 5 i denne figuren viser at denne informasjonen går direkte mellom tjeneste og ID-portalen.



All informasjon knyttet til autentiseringen går via klienten, og kan dermed manipuleres eller fanges opp av en 3.part. For å unngå at slike situasjoner kompromitterer sikkerheten i systemet, signeres AuthnRequest, LogoutRequest og LogoutResponse med partenes private nøkler. Signeringen sørger for integritet. Fra hva jeg kan se, sendes ikke AuthnResponse via klienten. I stedet videreformidler klienten en SAMLart-referanse, som den offentlige tjenesten så bruker for å verifisere innloggingsdetaljer direkte med ID-porten.



All kommunikasjon går naturligvis over sikker HTTP, og som vi vet etableres sikker forbindelse før HTTP-forespørsler med GET/POST data sendes. Krypteringen sørger for konfidensialitet.

Etter oppgraderingen fra Windows 7 til Windows 10 har startmenyen til tider plaget meg ganske mye. Så mye at jeg la alle programmene jeg bruker rett i oppgavelinjen. Hver gang Microsoft finner ut at de vil restrukturere menyer, skaper det litt hodebry for oss som nå har innlært hvor vi skal trykke for å finne frem. Det er likevel et par konkrete ting som nå er blitt unødvendig komplisert. F.eks. er det nå to kontrollpanel. Det er det gamle "kontrollpanelet", og det er et nytt "PC-innstillinger". Programmene dine er også nå todelt. Det er den gamle kjente startmenyen, og i tillegg virker det til å være et eget område for "apps". Dessuten er disse firkantene, de såkalte "titles"'ene utrolig stygge. Jeg ønsker heller ikke nyheter i startmenyen min.



Løsningen er enkel. Den heter Classic shell og lar deg velge blant flere kjente versjoner. Det er gratis programvare, som du kan støtte ved å donere. Det eneste jeg savner er at søkeboksen automatisk er aktiv når man trykker på startmenyen. Det er heldigvis lett å stille inn:



Det har vært rapportert om mye rart knyttet til personvern der Windows 10 påstås å sende opplysninger tilbake til moderskipet, selv etter at personverninnstillinger er skrudd til. Det har stort sett vært basert på misforståelser og mislykkede testoppsett, men det er klart at Windows 10 kan settes opp til å samle inn og sende ut svært mye personlig informasjon dersom brukeren ønsker visse typer funksjonalitet. For eksempel Cortana (personlig assistent) og funksjonen der Windows lærer hvordan du skriver. Ønsket om at alle enheter skal være synkronisert, medfører i praksis at dataene må ligge sentralt. Nye versjoner av operativsystemet kommer typisk med ny "usynlig" sikkerhetsteknologi som er med på å gjøre det vanskeligere for skadevare å ta over maskinen. Så jeg er ellers positiv til operativsystemet.

Digitale sertifikater brukes for å bekrefte identitet. Ofte skilles det mellom å identifisere seg, og det å bekrefte sin identitet, og i denne sammenheng menes da bekreftelse av identitet. Det man ønsker er selvsagt å bekrefte handlinger til fysiske personer, eller f.eks. virksomheter, mens det i praksis alltid vil være datamaskiner som besitter tilgangsparametere (nøkler) og som utfører verifikasjonsprosedyrene. Selv med smartkort og fingeravtrykklesere.

Identifisering kan være både én-veis og to-veis. En-veis er mest vanlig på det åpne Internett, typisk i den hensikt at du som nettsurfer kan stole på at nettsteder du besøker, og programvare du installerer kommer fra en pålitelig kilde. Uten slik verifikasjon er det trivielt for uvedkommende å utgi seg for å være en annen, f.eks. banken din. To-veis verifikasjon er i prinsippet bare to instanser av en-veis identifisering, en i hver retning, og brukes ofte i forbindelse med fjernpålogging. Enten som et supplement, eller erstatning for brukernavn/passord. Autorisasjon er et relatert begrep til identifikasjon. Kort fortalt handler autorisasjon om hva du skal få lov til å gjøre, når identiteten din først er bekreftet. Men det er et annet tema.



For å forstå digitale sertifikater må vi først forklare kryptografi med såkalt privat-offentlig nøkkelpar. Også kjent som asymmetrisk kryptografi. Kryptografi er enkelt forklart teknikker for å gjøre informasjon helt uforståelig, men på en slik måte at de som kjenner til en hemmelighet likevel er i stand til å forstå innholdet. For eksempel en tekst eller et bilde. Motstykket til asymmetrisk kryptografi er symmetrisk kryptografi. Der brukes samme nøkkel i prosessen med å "stokke om på" og "sette sammen" det opprinnelige budskapet. Symmetrisk kryptografi er relevant i denne sammenheng grunnet ytelse. Etter at identitet er bekreftet, utveksles typisk nøkler for en symmetrisk kryptoalgoritme, som så i tur beskytter resten av samtalen.

Tilbake til privat-offentlige nøkkelpar. Her er prinsippet at to forskjellige nøkler brukes henholdsvis for å "stokke om på" og "sette sammen" en mengde informasjon. To kjente slike algoritmer er ECC og RSA. Den ene nøkkelen er privat og må holdes hemmelig. Den andre er offentlig og kan deles fritt. Det den private nøkkelen brukes for å kryptere, kan den offentlig dekryptere (reversere). Tilsvarende dersom den offentlige brukes for å kryptere. Da kan bare den private nøkkelen brukes for å dekryptere. En nøkkel i denne sammenheng er et antall tilfeldige 1-ere og 0-ere, og lengden varierer fra rundt 100 til flere tusen slike «bit».



Dette har noen interessante egenskaper: De som kjenner din offentlige nøkkel kan sende deg noe bare du er i stand til å se. Dette ved å kryptere den med din offentlige nøkkel. I tillegg kan du som besitter den private nøkkelen "signere" noe, for eksempel en e-post, slik at alle med din offentlige nøkkel kan verifisere at det faktisk er du som sendte den. Men vi har fortsatt et problem: hvordan vet jeg at den offentlige nøkkelen jeg har som påstår at den er fra deg, faktisk tilhører den private nøkkelen du har laget og holder skjult? Her kommer digitale sertifikater og offentlig nøkkeldistribusjon (PKI) inn i bildet.

Et sertifikat er enkelt forklart en offentlig nøkkel og en identitet, pakket sammen. Det legges på en del metadata som bruksområde og gyldighet, og så signeres hele pakken av en tiltrodd tredjepart. Denne signeringen skjer da selvsagt med tredjepartens private nøkkel. Tilliten til systemet er altså fundert på disse tredjepartene. Disse tredjepartene har såkalte "selvsignerte" sertifikat, også kalt root-sertifikat. Disse består av den offentlige nøkkelen til "tredjeparten", signert med den tilsvarende private nøkkelen. Root-sertifikater fra sertifikatutstedere (Certificate Authorities, CA) ligger forhåndsinstallert i våre operativsystem og nettlesere. De oppdateres kontinuerlig. Det er ganske mange av dem, fra alle verdens hjørner. De er 100% avhengig av tillit i markedet, og det er eksempler på leverandører som er sperret ut fra de store plattformene grunnet dårlig hendelsehåndtering. I praksis, og for å minimere konsekvens av en kompromittert privat nøkkel, finnes det mange mellomutstedere (intermediate CA), ofte i flere ledd. Sertifikatutsteder signerer da første mellomutsteder. Første mellomutsteder signerer andre mellomutsteder... og siste mellomutsteder signerer et sertifikat som bekrefter identitet på et webområde, en utvikler, en person eller tilsvarende.



Det er selvsagt ikke nødvendig å bruke slik offentlig nøkkeldistribusjon, og for visse skjermingsverdige systemer er det anbefalt å ha egen nøkkelproduksjon og distribusjon. I praksis betyr det bare at root-sertifikat også må distribueres internt, da de ikke vil eksistere i kommersielle produkter. Dette er forsåvidt også en utfordring for systemer som av en eller annen grunn ikke får oppdatert root-sertifikatlagret automatisk over Internett.

Transport Layer Security (TLS), tidligere Secure Socket Layer (SSL) er en teknologi som ved hjelp av sertifikater utfører identitetsverifikasjonen, samt etablering av en kryptert kanal for overføring mellom to parter. For eksempel når du besøker en webside over sikker HTTP (https). Designet til SSL/TLS-protokollen er bygget rundt antakelsen at uvedkommende sitter mellom A og B, og er i stand til både å lytte og manipulere alt som blir kommunisert mellom A og B. Denne "uvedkommende" er en såkalt "man-in-the-middle" (noen foretrekker person-in-the-middle for å være kjønnsnøytrale). Stegene i prosessen handler om utveksling av sertifikater og valg av nøkler for kryptering av den nyopprettede samtalen. I tillegg brukes metoder for å kunne oppdage om noe har blitt endret underveis. Det er mange alternative algoritmer for kryptering og nøkkelutveksling. Det er funnet sårbarheter i de eldste, samtidig som at gammelt utstyr ikke støtter nye algoritmer. Det vil derfor være en prosess for å bestemme det høyeste sikkerhetsnivået begge parter støtter. Her er det særlig viktig at ikke uvedkommende skal kunne manipulere denne prosessen, slik at et lavt sikkerhetsnivå blir valgt.

Måten sesjonsnøkler blir valgt ut på er også viktig. Det vil si de nøklene som skal brukes til den symmetriske krypteringsprosessen for gjeldende samtale (ytelse). Det vi ønsker er såkalt "Perfect Forward Secrecy". Opprinnelig ble en nøkkel "valgt ut" av den ene parten, og sendt til motparten kryptert med motpartens offentlige nøkkel. Problemet med denne måten å gjøre det på, er at dersom motpartens private nøkkel en gang i fremtiden skulle komme på avveie, ja så vil det være mulig for en tredjepart som har tatt vare på alt som har blitt kommunisert, å rekonstruere all kryptert trafikk under denne private nøkkelen. For å unngå dette har vi matematikk som lar part A og B komme opp med hver sin del av nøkkelen, sende hverandre disse delene, og så sette sammen en felles nøkkel, uten at noen som lytter er i stand til å vite hva denne felles nøkkelen er. Algoritmen heter Diffie-Hellman, og den finnes i flere varianter. Poenget er da at bekreftelse av identitet og beskyttelse av innhold (konfidensialitet) blir adskilt. Sesjonsnøkkelen "eksisterer ikke" i samtalen. SSL-labs har en praktisk SSL/TLS test som sjekker etter kjente konfigurasjon og versjons-svakheter.

Sertifikater til websider varer typisk 1-2 år, noen ganger lenger. I prinsippet er alle sertifikat helt like. De gir alle mulighet til å kryptere med sterk kryptografi. Det som i praksis skiller dem er i hvilken grad utsteder har sjekket at du faktisk er du, før sertifikatet blir utstedet til deg. Det enkleste sertifikater for websider er domeneverifikasjon. Det eneste kravet er at du skal kunne verifisere at du har kontroll på domenet du søker sertifikat for. For eksempel vg.no. Det er vanlig at det sendes en e-post til da eksempelvis admin@vg.no, hvorfra det må aksepteres at sertifikatet signeres. I forkant har eieren av VG laget en privat og en offentlig nøkkel. Den offentlige nøkkelen sendes til sertifikatutstederen, som så legger ved at denne gjelder for vg.no, og signerer sertifikatet med sin private nøkkel. Sertifikatet installeres så på vg.no, sammen med alle mellomsertifikater i sertifikathierarkiet. Root-sertifikatet legges selvsagt ikke ved. Eneste grunnen til at en tilkoblet avissurfer (i dette tilfellet) ønsker å stole på VG sitt sertifikat, er at hele hierarkiet kan verifiseres basert på egen kopi av root-sertifikatet oppbevart lokalt.

Betaler man mer, er det mulig å få såkalte "Extended validation" sertifikat. Det innebærer en mye mer omfattende prosess der man knytter virksomheter og personer opp mot sertifikatet. Eksemplet øverst på siden fra nettleseren Chrome (skandiabanken.no) viser en grønn adresselinje, og navnet "Skandiabanken ASA [NO]" i tillegg til domenet. Tilsvarende nivåer eksisterer også for personsertifikater, men prinsippet er det samme. Altså prosessene rundt utstedelse.

Til sist et par ord om tilbakekallelse av sertifikater (revokering). Private nøkler vil før eller siden kunne komme på avveie. Eller de kan mistes. Det er derfor et behov for å kunne markere et sertifikat (med tilhørende offentlige nøkkel) som "ikke gyldig lenger". En måte dette kan skje på, er at det regelmessig sendes ut komplette lister over hvilke sertifikat som er utgåtte. Disse listene kan fort bli veldig store og uhåndterlige. Dette til tross for at de normalt bare varer 1-2 år og deretter ikke trenger å stå på noen liste lenger. En annen måte å løse dette på, er at den verifiserende part sjekker status via nettverket hver gang (OCSP). OCSP lekker informasjon til sertifikatutsteder relatert til hvilke nettsteder en bruker besøker, men det finnes et alternativ kalt "OCSP stapling" som skal løse denne utfordringen.

Så i dag fikk jeg enda en slik anonym scam-melding via chatteprogrammet Viber. Må være den 4. de siste månedene. En ting er at dette er plagsomt, men man kan virkelig lure på om noen går på dette. Et langt +1 (USA/Canada) telefonnummer, «i sosiale nettverk» og «alltid på nett her» samt en fordekket nettadresse (i dette tilfellet free-date-hookup.com/352/, sjekket med checkshorturl.com) får alle scam-varsellampene mine til å blinke, for ikke å nevne hvor meningsløst innholdet er på generelt grunnlag. Riktignok er norsken/grammatikken nokså grei.

Skadepotensialet ved å oppsøke ukjente adresser, slik som denne, er at nettleseren din kan få lastet ned skadelig programkode som i verste fall kan ta over kontrollen av enheten din, for eksempel via en sårbarhet i Java eller flash. Du kan selvsagt også bli lurt til å oppgi både det ene og det andre :)

Krebs har 3 enkle prinsipper for sikkerhet på nett. Et av dem er "If you didn’t go looking for it, don’t install it!". I denne sammenhengen må vel en avart av dette prinsippet benyttes. Vær skeptisk til ting som blir tilbudt deg.

Jeg liker måten nettleseren Chrome viser den faktiske URL'en til klikkbare linker, nederst til venstre i nettleservinduet, men det hjelper lite med slike forkortede adresser.