HTTPS

Innen telekommunikasjon og IT er HyperText Transfer Protocol over Secure Socket Layer ( HTTPS ), (også kjent som HTTP over TLS , [1] [2] HTTP over SSL [3] og HTTP Secure [4] [5] ) en protokoll for sikker kommunikasjon gjennom et datanettverk som brukes på Internett . Porten som vanligvis brukes (men ikke nødvendigvis) er 443. Den består av kommunikasjon via HTTP - protokollen(Hypertext Transfer Protocol) innenfor en kryptert tilkobling , ved bruk av asymmetrisk kryptering , av Transport Layer Security ( TLS ) eller dets forgjenger, Secure Sockets Layer ( SSL ) som gir som nøkkelkrav:

  1. en autentisering av nettstedet som er besøkt;
  2. personvern ( konfidensialitet eller konfidensialitet );
  3. integriteten til dataene som utveksles mellom de kommuniserende partene.

Generell informasjon

I sin populære operasjon på Internett gir HTTPS sikkerheten til nettstedet og den tilhørende webserveren som en av partene kommuniserer med, og beskytter kommunikasjonen mot kjente angrep gjennom mannen i midten- teknikken . Videre gir HTTPS en toveis kryptering av kommunikasjon mellom en klient og en server , som beskytter den samme mot mulige avlyttingsoperasjoner , ( en handling der den private samtalen mellom partene i hemmelighet lyttes uten deres samtykke ) og tukling ( bokstavelig talt tukling med eller endring av kommunikasjonen ) som forfalsker innholdet. [6] I praksis gir denne mekanismen en tilfredsstillende garanti for at du kommuniserer nøyaktig med den ønskede nettsiden (i motsetning til en falsk nettside), samt sikrer at innholdet i kommunikasjonen mellom brukeren og nettstedet ikke kan fanget opp eller endret av tredjeparter.

Historisk sett ble HTTPS-forbindelser hovedsakelig brukt til betalinger i transaksjoner på World Wide Web (spesielt for elektronisk handel ), e-post og for sensitive transaksjoner i bedriftens informasjonssystemer . På slutten av 2000-tallet og begynnelsen av 2010-tallet begynte HTTPS å ha utbredt og utbredt bruk for å beskytte autentisiteten til nettsider , sikkerheten til brukerkontoer, og for å holde kommunikasjonen, identiteten og nettsurfingen til nettet privat.

Historie

Dette systemet ble designet av Netscape Communications Corporation som omhandler autentisering og kryptert kommunikasjon og er mye brukt på World Wide Web for situasjoner som krever spesielle sikkerhetskrav som å betale for netttransaksjoner. I dette tilfellet garanterer SSL kryptering av data som sendes og mottas over internett .

Beskrivelse

I nettlesere har URI ( Uniform Resource Identifier ) ​​som refererer til denne teknologien et skjemanavn httpsog ligner på alle måter URIer http. HTTPS signaliserer imidlertid nettleseren til å bruke det ekstra SSL / TLS-krypteringslaget for å beskytte Internett-trafikk. SSL / TLS er spesielt egnet for HTTP-protokollen, da den kan gi en viss beskyttelse, selv om bare en av de kommuniserende partene er autentisert. Dette er tilfellet med HTTP i internetttransaksjoner, hvor typisk serveren er den eneste parten som skal autentiseres, mens klienten undersøker serversertifikatet.

HTTPS tar seg av å skape en sikker kommunikasjonskanal gjennom et usikret datanettverk. Dette sikrer akseptabel beskyttelse mot avlyttere ( nysende lyttere ) og man-in-the-midten-angrep , så lenge tilstrekkelig kommunikasjonskryptering brukes og serversertifikatet er verifisert og klarert.

I bunnen av operasjonen til HTTPS, over Transport Layer Security , ligger HTTP-protokollen i sin helhet; av denne grunn kan sistnevnte være fullstendig kryptert. HTTP-protokollkryptering inkluderer:

Siden verts-IP-adresser ( nettsteder ) og portnumre er en del av de underliggende protokollene til TCP/IP, kan imidlertid ikke HTTPS beskytte avsløringen av dem. I praksis betyr det at selv om en webserver er riktig konfigurert, kan avlyttere utlede IP-adressen og portnummeret (noen ganger til og med domenenavnet, for eksempel "www.example.org", men ikke resten av nettadressen) til nettet serveren du kommuniserer med, i tillegg til mengden data som overføres og kommunikasjonens varighet (lengden på økten), men ikke innholdet i kommunikasjonen. [6]

Nettlesere vet hvordan de kan stole på de autorisasjonssertifikatbaserte HTTPS-nettstedene som er forhåndsinstallert i programvaren deres. Sertifiseringsinstanser (som Symantec, Comodo, GoDaddy og GlobalSign ) er klarert av nettleserskapere for å gi gyldige sertifikater for kommunikasjonsformål. Derfor bør en bruker stole på en HTTPS-tilkobling til et nettsted hvis og bare hvis alt av følgende er bekreftet:

HTTPS er spesielt viktig over usikre nettverk (som offentlige WiFi-hotspots), ettersom alle på det samme lokale nettverket kan snuse pakker og oppdage sensitiv, ikke-HTTPS-beskyttet informasjon. I tillegg får mange betalt for å engasjere seg i pakkeinjeksjon i trådløse nettverk med det formål å tilby en tjeneste for annonsering av nettsidene deres, mens andre gjør det fritt. Imidlertid kan denne operasjonen utnyttes skadelig på mange måter, for eksempel å injisere skadelig programvare på nettsider og stjele privat informasjon fra brukere. [7]

HTTPS er også veldig viktig med tilkoblinger på Tor -nettverket (akronym for The Onion Router) for å bevare anonymiteten på internett, da ondsinnede Tor-noder kan skade eller endre innholdet som passerer gjennom dem på en usikker måte og injisere skadevare i forbindelsen. Av denne grunn har Electronic Frontier Foundation ( EFF ) og Tor-prosjektet startet utviklingen av HTTPS Everywhere -protokollen [6] , som er inkludert i Tor Browser-pakken. [8]

Selv om mer informasjon blir avslørt om global masseovervåking og tyveri av personlig informasjon fra hackere , blir bruken av HTTPS for sikkerhet på alle nettsteder stadig viktigere, uavhengig av hvilken type internettforbindelse som brukes. . [9] [10] Mens metadataene til de enkelte sidene en bruker besøker ikke er sensitiv informasjon, kan den når denne informasjonen kombineres avsløre mye om brukerens identitet og kompromittere deres personvern. [2] [11] [12]

Bruken av HTTPS tillater også bruk av SPDY / HTTP / 2 -protokollene , som er nye generasjoner av HTTP-protokollen, designet for å redusere innlastingstider og ventetid for nettsider.

Det anbefales å bruke HTTP Strict Transport Security (HSTS) med HTTPS for å beskytte brukere mot angrep fra mann i midten, spesielt SSL-stripping . [12] [13]

HTTPS må ikke forveksles med den lite brukte Secure HTTP (S-HTTP)-protokollen beskrevet i RFC 2660 -spesifikasjonen .

Bruk på nettsteder

Per 3. mai 2017 har 56,8 % av de 139 032 store nettstedene en sikker implementering av HTTPS-protokollen. [14] HTTPS brukes av 5,24 % av de totale registrerte italienske domenene [15] .

Integrasjon i nettlesere

De fleste nettlesere viser en advarsel hvis de mottar et ugyldig sertifikat fra serveren som fungerer som sertifiseringsinstans. Eldre nettlesere, når de koblet til et nettsted med et ugyldig sertifikat, viste brukeren en dialogmelding som spurte dem om de ønsket å fortsette å surfe. De nyeste nettleserne, derimot, viser en advarsel som dekker hele vinduet, og viser brukeren sikkerhetsinformasjonen til nettstedet som er besøkt i nettleserens adresselinje. I moderne nettlesere viser utvidet sertifikatvalidering adressefeltet med en grønn farge. Videre viser de fleste nettlesere en advarsel til brukeren når de besøker et nettsted som inneholder en blanding av kryptert og ukryptert innhold.

Firefox bruker HTTPS-protokollen for Google-søk siden versjon 14, [16] med sikte på å "beskytte brukerne våre mot nettverksinfrastrukturen som kan samle inn data fra brukere eller modifisere / sensurere søkeresultatene deres". [17]

Electronic Frontier Foundation uttrykte den oppfatning at: " I en ideell verden kan enhver nettforespørsel som standard transformeres til en HTTPS-forespørsel ". For nettleserne Google Chrome , Mozilla Firefox (også på Android ) og Opera er det et tillegg kalt " HTTPS Everywhere " som aktiverer standard HTTPS-protokollen for hundrevis av nettsteder.

Sikkerhet

Sikkerheten til HTTPS er sikret av den underliggende TLS -protokollen , som i hovedsak bruker langsiktige private og offentlige nøkler for å generere kortsiktige sesjonsnøkler. Disse nøklene brukes deretter til å kryptere dataflyten som utveksles mellom klient og server. Sertifikater definert av X.509 -standarden brukes til å autentisere serveren (noen ganger til og med klienten). Følgelig kreves det sertifikatmyndigheter og offentlige nøkkelsertifikater for å verifisere forholdet mellom sertifikatet og dets eier, samt generere signaturen og administrere gyldigheten til sertifikatene. Selv om dette kan være mer fordelaktig enn å verifisere identiteter gjennom et nett av tillit, trakk masseovervåkingsavsløringer i 2013 oppmerksomhet til sertifiseringsmyndighetene som et potensielt svakt punkt for mann-i-midten-angrep . [18] [19] En viktig egenskap i denne sammenhengen er forward hemmelighold , som sikrer at kryptert kommunikasjon registrert i fortiden ikke kan gjenopprettes og dekrypteres og langsiktige krypteringsnøkler eller passord ikke kompromitteres i fremtiden. Ikke alle webservere gir videre hemmelighold . [20]

Et nettsted må være fullt hostet på HTTPS-protokollen, uten å ha deler av innholdet over HTTP - for eksempel ha skript lastet online på en usikker måte (i det klare) - ellers vil brukeren være sårbar for visse angrep og utsatt for overvåking . Å ha bare en bestemt nettside på et nettsted som inneholder sensitiv informasjon (som en påloggingsside) under HTTPS-protokollen, men å ha resten av nettstedet lastet over HTTP-protokollen i klartekst, vil utsette brukeren for mulige angrep . På et nettsted som har sensitiv informasjon et sted på seg, når nettstedet åpnes i HTTP i stedet for HTTPS, vil brukeren og økten bli eksponert på nettverket. Tilsvarende må informasjonskapsler på et nettsted som er aktivt via HTTPS-protokollen ha sikkerhetsattributtet aktivert. [12]

Tekniske aspekter

Forskjellen fra HTTP

HTTPS-protokoll URL-er starter med https: // og bruker port 443 som standard , mens HTTP URL-er starter med http:// og bruker port 80.

HTTP er ikke kryptert, så det er sårbart for avlytting og man-in-the-midten-angrep: angripere kan få tilgang til nettstedskontoer med sensitiv informasjon, eller endre nettsider for å injisere skadelig programvare eller ondsinnet reklame. HTTPS er designet for å motstå slike angrep og anses som trygt mot dem (med unntak av de mest foreldede og foreldede versjonene av SSL -protokollen ).

Nettverksnivåer

HTTPS opererer på det høyeste nivået av TCP/IP-modellen, applikasjonslaget; det samme gjør TLS -sikkerhetsprotokollen (fungerer som et lavere underlag på samme nivå).

I praksis, mellom TCP- og HTTP -protokollen, er et krypterings- / autentiseringsnivå lagt inn (gjennomsiktig for brukeren) , slik som Secure Sockets Layer (SSL) eller Transport Layer Security (TLS) som krypterer HTTP-meldingen før overføring og dekrypterer meldingen når den når målet. I utgangspunktet opprettes en kryptert kommunikasjonskanal mellom klienten og serveren gjennom en utveksling av sertifikater ; når denne kanalen er etablert, brukes HTTP-protokollen internt for kommunikasjon. Strengt tatt regnes ikke HTTPS som en separat protokoll fra HTTP, men refererer nettopp til bruken av sistnevnte gjennom en kryptert SSL/TLS-forbindelse. Denne typen kommunikasjon sikrer at kun klienten og serveren er i stand til å vite innholdet i kommunikasjonen.

Alt i HTTPS-meldingen er kryptert, inkludert overskriftene og meldingsforespørselen/svarbelastningen. Med unntak av det mulige CCA-krypteringsangrepet som er beskrevet i " Grenser "-delen nedenfor, kan angriperen bare vite at det har oppstått en forbindelse mellom de to kommuniserende partene og kan kjenne deres domenenavn og IP-adresser.

Anskaffelse av sertifikater

Autoritativt signerte sertifikater kan være gratis [21] [22] eller koste mellom $8 [23] og $ 70 [24] per år. (2012-2014). Organisasjoner kan også ta i bruk sine egne sertifiseringsmyndigheter, spesielt hvis de er ansvarlige for å konfigurere nettlesere for å få tilgang til nettstedene deres (for eksempel nettsteder på et bedriftsintranett eller større universiteter). Slike organisasjoner kan enkelt legge til kopier av sertifikatsignaturen til pålitelige sertifikater distribuert med nettleseren. I tillegg finnes det peer-to-peer- sertifiseringsmyndigheter , for eksempel CACert . Sistnevnte er imidlertid ikke inkludert i de pålitelige opprinnelsessertifikatene til mange populære nettlesere (f.eks . Firefox , Chrome , Internet Explorer ), som kan vise advarsler til sluttbrukere. En sertifiseringsinstans, " Let's Encrypt " ble lansert i slutten av 2015 [25] og tilbyr gratis automatiske SSL / TLS-sertifikater for nettsteder. [26] I følge Electronic Frontier Foundation vil "Let's Encrypt" gjøre overgangen fra HTTP til HTTPS "like enkelt som å kjøre en kommando eller klikke på en knapp." [27]

Bruk som tilgangskontroll

Systemet kan også brukes til klientautentisering for å begrense tilgangen til webserveren til kun autoriserte brukere. For å gjøre dette oppretter nettstedsadministratoren vanligvis et sertifikat for hver bruker, som lastes inn i brukerens nettleser. Vanligvis inneholder den navnet og e-postadressen til den autoriserte brukeren og verifiseres automatisk av serveren ved hver tilkobling for å bekrefte brukerens identitet, potensielt uten å oppgi passordet.

I tilfelle kompromittert hemmelig privat nøkkel

En viktig egenskap i denne sammenheng er perfekt fremadrettet hemmelighold (PFS). Å ha en langsiktig asymmetrisk hemmelig privat nøkkel brukt til å etablere en HTTPS-økt bør ikke gjøre det enklere å utlede den kortsiktige øktnøkkelen og deretter dekryptere samtalen, selv på et senere tidspunkt. Diffie-Hellman (DHE) nøkkelutveksling og Diffie-Hellman (ECDHE) elliptiske kurver er siden 2013 de eneste ordningene som er kjent for å ha den perfekte fremadrettede hemmelighetsegenskapen. Bare 30 % av Firefox-, Opera- og Chromium-nettleserøktene bruker denne egenskapen og nesten 0 % av Apples Safari- og Microsoft Internet Explorer-nettleserøkter. [20] Blant de største internettleverandørene er det bare Google som har støttet PFS siden 2011. Et sertifikat kan trekkes tilbake før det utløper, for eksempel fordi hemmeligholdet til den private nøkkelen er kompromittert. De fleste moderne versjoner av populære nettlesere som Firefox, [28] Opera, [29] og Internet Explorer på Windows Vista [30] implementerer Online Certificate Status Protocol (OCSP) og myndigheten svarer og forteller nettleseren om sertifikatet fortsatt er gyldig eller ikke. [31]

Operasjon

HTTPS er en protokoll som integrerer interaksjonen til HTTP-protokollen gjennom en Transport Layer Security ( SSL/TLS ) krypteringsmekanisme. Denne teknikken øker beskyttelsesnivået mot mann i midtangrep .

Standardporten for HTTPS-protokollen er nummer 443 (mens den for HTTP-protokollen er nummer 80).

For å sette opp en webserver til å akseptere HTTPS-tilkoblinger, må nettverksadministratoren opprette et digitalt sertifikat som er et elektronisk dokument som knytter en persons identitet til en offentlig nøkkel . Disse sertifikatene kan lages av UNIX -baserte servere ved hjelp av verktøy som OpenSSL ssl-ca eller ved å bruke SuSE gensslcert (TinyCA2, CA.pl, Perl-skript). Disse sertifikatene må utstedes av en sertifiseringsinstans eller i alle fall av et system som verifiserer gyldigheten av det samme for å definere den sanne identiteten til eieren (nettlesere opprettes for å bekrefte gyldigheten gjennom en forhåndsinnstilt liste ).

I spesielle situasjoner (som når det gjelder bedrifter med privat intranett ) er det mulig å ha ditt eget digitale sertifikat som kan utstedes til dine brukere.

Denne teknologien kan derfor også brukes til å tillate begrenset tilgang til en webserver . Administratoren lager ofte sertifikater for hver bruker som lastes inn i deres nettlesere som inneholder informasjon som navn og e - postadresse på en slik måte at serveren kan gjenkjenne brukeren når sistnevnte prøver å koble til på nytt uten å skrive inn brukernavn og/eller passord .

For en bedre grad av beskyttelse av HTTPS-tilkoblinger i møte med man-in-the-middle-angrep , og spesielt for å møte " SSL-stripping "-teknikken , anbefales det å bruke HTTP Strict Transport Security , en ekstra sikkerhetsmekanisme. som tvinger bruken av HTTPS. [12] [13]

Begrensninger

SSL / TLS-protokollen er tilgjengelig med to alternativer, enkel og gjensidig. I den enkle versjonen er det kun serveren som sørger for sikkerheten i kommunikasjonen. Den gjensidige versjonen er sikrere, men krever at brukeren installerer et personlig klientsertifikat i nettleseren for å autentisere seg. Uansett hvilken strategi som brukes (enkel eller gjensidig), avhenger beskyttelsesnivået sterkt av korrektheten til nettleserimplementeringen, serverprogramvaren og de faktiske støttede kryptografiske algoritmene. SSL/TLS hindrer ikke hele nettstedet fra å bli indeksert ved hjelp av en webcrawler , og i noen tilfeller kan URIen til den krypterte ressursen utledes ved kun å vite størrelsen på den avlyttede forespørselen/svaret. [32] Dette lar en angriper ha tilgang til uformatert tekst (det offentlig tilgjengelige statiske innholdet) og chiffertekst (den krypterte versjonen av det statiske innholdet), noe som tillater et kryptografisk angrep.

Siden TLS opererer under HTTP-protokollen og ikke har kunnskap om protokoller på høyere nivå, kan TLS-servere strengt tatt bare presentere ett sertifikat for en bestemt kombinasjon av port og IP-adresse. [33] Dette betyr at det i de fleste tilfeller ikke er mulig å bruke navnebasert virtuell hosting med HTTPS. Det finnes en løsning som heter Server Name Indication (SNI) som sender vertsnavnet til serveren før kryptering av tilkoblingen, selv om mange eldre nettlesere ikke støtter denne utvidelsen. SNI-støtte er tilgjengelig fra og med: Firefox 2, Opera 8, Safari 2.1, Google Chrome 6 og Internet Explorer 7 på Windows Vista. [34] [35] [36]

Fra et arkitektonisk synspunkt:

  1. En SSL/TLS-tilkobling håndteres av den første synlige maskinen som starter TLS-tilkoblingen. Hvis denne maskinen av en eller annen grunn (ruting, trafikkoptimalisering osv.) ikke er applikasjonsserveren og trenger å dekryptere dataene, må det finnes løsninger for å spre brukerautentiseringsinformasjonen eller applikasjonsserversertifikatet, som må være klar over hvem som skal koble seg til.
  2. For versjonen av SSL/TLS med gjensidig autentisering, administreres SSL/TLS-økten av den første serveren som starter tilkoblingen. I situasjoner der kryptering må forplantes langs en kjede av servere, blir timeout-administrasjonen komplisert å implementere.
  3. Med den gjensidige versjonen av SSL / TLS er sikkerheten maksimal, men på klientsiden er det ingen måte å avslutte SSL / TLS-tilkoblingen på riktig måte og logge av brukeren, bortsett fra å vente til sesjonen på serversiden utløper eller alle tilkoblede klienter applikasjoner.

En sofistikert type mann-i-midten-angrep kalt SSL-stripping ble avduket på Blackhat-konferansen i 2009. Denne typen angrep beseirer sikkerheten gitt av HTTPS-protokollen ved å endre https:-lenken til en http:-lenken ved å utnytte av det faktum at noen Internett-brukere faktisk skriver "https" fra nettlesergrensesnittet: de kommer til et sikkert nettsted ved å klikke på en lenke, og blir derfor lurt til å tro at de bruker HTTPS mens de faktisk bruker HTTP. Angriperen kommuniserer deretter i det klare med klienten. Dette førte til utviklingen av et HTTP-mottiltak kalt HTTP Strict Transport Security (HSTS).

I mai 2010 avslørte en artikkel skrevet av forskere ved Microsoft Research og Indiana University at detaljerte sensitive brukerdata kan utledes fra side-/marginalkanaler som pakkestørrelse. Mer spesifikt fant forskerne at en avlytter kan utlede brukerens sykdommer / medisiner / operasjoner, familieinntekten og investeringshemmelighetene, til tross for HTTPS-beskyttelsen som finnes i de ulike høyprofilerte og bedre nettapplikasjonene. innen helsevesen, skattlegging , investeringer og nettforskning.

I juni 2014 demonstrerte et team av forskere fra University of California, Berkeley og Intel ledet av Brad Miller en generalisert tilnærming til maskinlæringsbasert HTTPS-trafikkanalyse . [37] [38] Forskere demonstrerte angrepet på en rekke nettsteder, inkludert Mayo Clinic , Planned Parenthood og YouTube . [39] Angrepet forutsetter at angriperen er i stand til å besøke de samme nettsidene som offeret for å samle informasjon om nettverkstrafikk som fungerer som datatrening. Angriperen er deretter i stand til å identifisere likheter i pakkestørrelser og sortering mellom offertrafikk og dataopplæringstrafikk, noe som gjør at angriperen ofte kan utlede den nøyaktige nettsiden offeret besøker. Dette angrepet kan for eksempel brukes til å finne ut om en bruker som besøker nettstedet Planned Parenthood, ser etter informasjon om en forebyggende helseundersøkelse eller en abort. Merk at angrepet ikke kan brukes til å oppdage brukerspesifikke verdier innebygd i en nettside. Mange banker tilbyr for eksempel nettgrensesnitt som lar brukere se gjeldende kontosaldo. Selv om angriperen vil kunne oppdage at brukeren ser på en visningsside for gjeldende kontosaldo, vil de ikke kunne vite den nøyaktige verdien av gjeldende kontosaldo eller brukerens kontonummer.

SEO-implikasjoner

8. august 2014 kunngjør Google at nettsteder som er vert under HTTPS-protokollen vil bli ansett som mer pålitelige i søkemotorens øyne. HTTPS-protokollen er offisielt annonsert som en rangeringsfaktor.

Merknader

  1. ^ Network Working Group, HTTP Over TLS , på tools.ietf.org , The Internet Engineering Task Force, mai 2000. Hentet 27. februar 2015 ( arkivert 31. oktober 2018) .
  2. ^ a b HTTPS som rangeringssignal , på Google Webmaster Central Blog , Google Inc., 6. august 2014. Hentet 27. februar 2015 (arkivert fra originalen 8. mars 2016) .
    "Du kan gjøre nettstedet ditt sikkert med HTTPS (Hypertext Transfer Protocol Secure) [...]"
  3. ^ Aktivering av HTTP over SSL , på docs.adobe.com , Adobe Systems Incorporated. Hentet 27. februar 2015 ( arkivert 8. mars 2015) .
  4. ^ Sikre nettstedet ditt med HTTPS , på Google Support , Google, Inc .. Hentet 27. februar 2015 ( arkivert 15. desember 2017) .
  5. ^ Hva er HTTPS? , på instantssl.com , Comodo CA Limited . Hentet 27. februar 2015 (arkivert fra originalen 12. februar 2015) .
    "Hyper Text Transfer Protocol Secure (HTTPS) er den sikre versjonen av HTTP [...]"
  6. ^ a b c HTTPS Everywhere FAQ , på eff.org . Hentet 3. mai 2012 ( arkivert 20. april 2018) .
  7. ^ Hotell Wifi JavaScript Injection , på justinsomnia.org . Hentet 24. juli 2012 ( arkivert 24. juli 2012) .
  8. ^ The Tor Project, Inc., Tor , på torproject.org . Hentet 12. mai 2016 ( arkivert 17. juli 2013) .
  9. ^ Konigsburg, Eitan, Pant, Rajiv og Kvochko, Elena, Embracing HTTPS , på open.blogs.nytimes.com , The New York Times, 13. november 2014. Hentet 27. februar 2015 (arkivert fra originalen 22. april 2018. ) .
  10. ^ Gallagher, Kevin, Femten måneder etter NSA-avsløringene, hvorfor bruker ikke flere nyhetsorganisasjoner HTTPS? , på freedom.press , Freedom of the Press Foundation, 12. september 2014. Hentet 27. februar 2015 (arkivert fra originalen 2. desember 2016) .
  11. ^ Grigorik, Ilya e Far, Pierre, Google I/O 2014 - HTTPS Everywhere , på youtube.com , Google Developers, 26. juni 2014. Hentet 27. februar 2015 ( arkivert 15. mars 2018) .
  12. ^ a b c d Hvordan distribuere HTTPS riktig , på eff.org . Hentet 13. juni 2012 ( arkivert 14. mars 2018) .
  13. ^ a b HTTP Strict Transport Security , på Mozilla Developer Network . Hentet 14. oktober 2015 (arkivert fra originalen 15. mai 2012) .
  14. ^ SSL Pulse , på trustworthyinternet.org , Trustworthy Internet Movement, 3. oktober 2015. Hentet 7. mai 2017 (arkivert fra originalen 15. mai 2017) .
  15. ^ Internettstatistikk på italiensk centroli.it , på centroli.it . Hentet 7. mai 2017 (arkivert fra originalen 16. februar 2017) .
  16. ^ Firefox 14.0.1 versjonsmerknader , på mozilla.org . Hentet 24. juli 2012 ( arkivert 22. juli 2012) .
  17. ^ Firefox ruller ut HTTPS Google-søk , på blog.mozilla.org . Hentet 24. juli 2012 ( arkivert 20. juli 2012) .
  18. ^ Law Enforcement Appliance Subverts SSL.Archived 15. mars 2014 på Internet Archive ., Wired, 2010-04-03.
  19. ^ Ny forskning antyder at regjeringer kan forfalske SSL-sertifikater arkivert 4. januar 2016 på Internet Archive ., EFF, 2010-03-24.
  20. ^ a b SSL: Oppfanget i dag, dekryptert i morgen. Arkivert 21. september 2013 på Internet Archive ., Netcraft, 2013-06-25.
  21. ^ Gratis SSL-sertifikater fra en gratis sertifiseringsinstans , på sslshopper.com . Hentet 24. oktober 2009 ( arkivert 9. februar 2010) .
  22. ^ Justin Fielding, Secure Outlook Web Access med (gratis) SSL: Del 1 , på techrepublic.com , TechRepublic , 16. juli 2006. Hentet 24. oktober 2009 ( arkivert 24. mars 2011) .
  23. ^ Namecheap.com SSL Services , på namecheap.com , namecheap. Hentet 30. januar 2012 ( arkivert 4. februar 2012) .
  24. ^ Secure Site Pro med SSL-sertifikat , på ssl.comodo.com . Hentet 23. august 2014 ( arkivert 26. august 2014) .
  25. ^ Lanseringsplan , på Let's Encrypt . Hentet 21. september 2015 ( arkivert 27. september 2015) .
  26. ^ Kerner, Sean Michael, Let's Encrypt Effort Aims to Improve Internet Security , eWeek.com , Quinstreet Enterprise, 18. november 2014. Hentet 27. februar 2015 .
  27. ^ Eckersley, Peter, Launching in 2015: A Certificate Authority to Entire the Entire Web , eff.org , Electronic Frontier Foundation , 18. november 2014. Hentet 27. februar 2015 ( arkivert 10. mai 2018) .
  28. ^ Mozilla Firefox retningslinjer for personvern , på mozilla.com , Mozilla Foundation , 27. april 2009. Hentet 13. mai 2009 (arkivert fra originalen 26. mai 2009) .
  29. ^ Opera 8 lansert på FTP , Softpedia , 19. april 2005. Hentet 13. mai 2009 (arkivert fra originalen 12. juli 2009) .
  30. ^ Eric Lawrence, HTTPS Security Improvements in Internet Explorer 7 , fra msdn.microsoft.com , MSDN , 31. januar 2006. Hentet 13. mai 2009 ( arkivert 1. oktober 2017) .
  31. ^ Myers, M, Ankney, R, Malpani, A, Galperin, S og Adams, C, Online Certificate Status Protocol - OCSP , på tools.ietf.org , Internet Engineering Task Force , juni 1999. Hentet 13. mai 2009 ( arkivert 25. november 2017) .
  32. ^ Stanislaw Pusep, The Pirate Bay un-SSL , på sysd.org , 31. juli 2008. Hentet 6. mars 2009 (arkivert fra originalen 8. mars 2009) .
  33. ^ SSL / TLS sterk kryptering: FAQ , på apache.org . Hentet 1. mai 2019 ( arkivert 19. oktober 2018) .
  34. ^ Eric Lawrence, Upcoming HTTPS Improvements in Internet Explorer 7 Beta 2 , på blogs.msdn.com , Microsoft , 22. oktober 2005. Hentet 12. mai 2009 ( arkivert 26. januar 2010) .
  35. ^ Servernavnindikasjon (SNI) på innsiden av aebrahims hode . Hentet 13. mai 2016 (Arkiveret fra originalen 30. juni 2017) .
  36. ^ Julien Pierre, Browser support for TLS server name indication , Bugzilla , Mozilla Foundation, 19. desember 2001. Hentet 15. desember 2010 (arkivert fra originalen 8. oktober 2018) .
  37. ^ Statistiske triks trekker ut sensitive data fra kryptert kommunikasjon , på technologyreview.com , MIT Technology Review, 19. juni 2014.
  38. ^ Researchers Use Big Data to Get Around Encryption , blogs.wsj.com , The Wall Street Journal, 23. juni 2014. Hentet 13. mai 2016 ( arkivert 18. mars 2016) .
  39. ^ Brad Miller, Ling Huang, Anthony D. Joseph, JD Tygar, I Know Why You Went to the Clinic: Risks and Realization of HTTPS Traffic Analysis ( PDF ), på bradmiller.io . Hentet 13. mai 2016 ( arkivert 31. mai 2016) .

Relaterte elementer

Andre prosjekter

Eksterne lenker

Offisielle dokumenter

Nettleserutvidelser