HTTPS - HTTPS

Hypertext Transfer Protocol Secure ( HTTPS ) er en udvidelse af Hypertext Transfer Protocol (HTTP). Det bruges til sikker kommunikation over et computernetværk og bruges i vid udstrækning på Internettet. I HTTPS er kommunikationsprotokollen krypteret ved hjælp af Transport Layer Security (TLS) eller tidligere Secure Sockets Layer (SSL). Protokollen kaldes derfor også HTTP over TLS eller HTTP over SSL .

De vigtigste motiver for HTTPS er godkendelse af det tilgængelige websted og beskyttelse af privatlivets fred og integritet af de udvekslede data under transport. Det beskytter mod mand-in-the-middle-angreb , og det tovejs kryptering af kommunikation mellem en klient og server beskytter kommunikationen mod aflytning og manipulation . Godkendelsesaspektet ved HTTPS kræver, at en tredjepart, der er tillid til, signerer digitale certifikater på serversiden . Dette var historisk set en dyr operation, hvilket betød, at fuldt godkendte HTTPS -forbindelser normalt kun blev fundet på sikrede betalingstransaktionstjenester og andre sikrede virksomhedsinformationssystemer på World Wide Web . I 2016 førte en kampagne fra Electronic Frontier Foundation med støtte fra webbrowserudviklere til, at protokollen blev mere udbredt. HTTPS bruges nu oftere af webbrugere end den originale ikke-sikre HTTP, primært for at beskytte sideægthed på alle typer websteder; sikre konti; og for at holde brugerkommunikation, identitet og webbrowsing privat.

Oversigt

URL, der begynder med HTTPS -skemaet og WWW -domænenavnetiketten

Den Uniform Resource Identifier (URI) ordning HTTPS har identisk brug syntaks til HTTP ordningen. HTTPS signalerer dog browseren til at bruge et tilføjet krypteringslag af SSL/TLS til at beskytte trafikken. SSL/TLS er især velegnet til HTTP, da det kan give en vis beskyttelse, selvom kun den ene side af kommunikationen er godkendt . Dette er tilfældet med HTTP -transaktioner over internettet, hvor typisk kun serveren er godkendt (ved at klienten undersøger serverens certifikat ).

HTTPS opretter en sikker kanal over et usikkert netværk. Dette sikrer rimelig beskyttelse mod aflyttere og man-in-the-middle-angreb , forudsat at der bruges passende chiffer-suiter , og at servercertifikatet er verificeret og betroet.

Fordi HTTPS piggybacks HTTP helt oven på TLS, kan hele den underliggende HTTP -protokol krypteres. Dette inkluderer anmodningswebadressen (hvilken bestemt webside der blev anmodet om), forespørgselsparametre, overskrifter og cookies (som ofte indeholder identificerende oplysninger om brugeren). Fordi webstedsadresser og portnumre nødvendigvis er en del af de underliggende TCP/IP -protokoller, kan HTTPS imidlertid ikke beskytte deres offentliggørelse. I praksis betyder det, at selv på en korrekt konfigureret webserver kan aflyttere udlede webserverens IP -adresse og portnummer, og nogle gange endda domænenavnet (f.eks. Www.example.org, men ikke resten af ​​webadressen), der en bruger kommunikerer med, sammen med mængden af ​​data, der overføres og kommunikationens varighed, dog ikke kommunikationens indhold.

Webbrowsere ved, hvordan de kan stole på HTTPS-websteder baseret på certifikatmyndigheder, der er forudinstalleret i deres software. Certifikatmyndigheder er på denne måde betroet af webbrowserskabere til at levere gyldige certifikater. Derfor bør en bruger stole på en HTTPS -forbindelse til et websted, hvis og kun hvis alle følgende er sande:

  • Brugeren har tillid til, at browsersoftwaren korrekt implementerer HTTPS med korrekt forudinstallerede certifikatmyndigheder.
  • Brugeren har tillid til, at certifikatmyndigheden kun står inde for legitime websteder.
  • Webstedet giver et gyldigt certifikat, hvilket betyder, at det er underskrevet af en betroet myndighed.
  • Certifikatet identificerer webstedet korrekt (f.eks. Når browseren besøger " https://example.com ", er det modtagne certifikat korrekt for "example.com" og ikke en anden enhed).
  • Brugeren har tillid til, at protokollens krypteringslag (SSL/TLS) er tilstrækkeligt sikkert mod aflyttere.

HTTPS er især vigtig over usikre netværk og netværk, der kan blive udsat for manipulation. Usikre netværk, f.eks. Offentlige Wi-Fi- adgangspunkter, gør det muligt for alle på det samme lokale netværk at pakke-snuse og opdage følsomme oplysninger, der ikke er beskyttet af HTTPS. Derudover er der observeret nogle gratis og betalte WLAN- netværk, der manipulerer med websider ved at deltage i pakkeindsprøjtning for at vise deres egne annoncer på andre websteder. Denne praksis kan udnyttes ondsindet på mange måder, f.eks. Ved at injicere malware på websider og stjæle brugernes private oplysninger.

HTTPS er også vigtig for forbindelser over Tor -netværket , da ondsindede Tor -noder ellers kan beskadige eller ændre indholdet, der passerer dem på en usikker måde og injicere malware i forbindelsen. Dette er en af ​​grundene til, at Electronic Frontier Foundation og Tor -projektet startede udviklingen af HTTPS Everywhere , som er inkluderet i Tor Browser.

Efterhånden som der afsløres flere oplysninger om global masseovervågning og kriminelle stjæler personlige oplysninger, bliver brugen af ​​HTTPS -sikkerhed på alle websteder stadig vigtigere, uanset hvilken type internetforbindelse der bruges. Selvom metadata om individuelle sider, som en bruger besøger, måske ikke betragtes som følsomme, kan de ved sammenlægning afsløre meget om brugeren og kompromittere brugerens privatliv.

Implementering af HTTPS tillader også brug af HTTP/2 (eller dens forgænger, den nu udfasede protokol SPDY ), som er en ny generation af HTTP designet til at reducere sidens indlæsningstid, størrelse og latenstid.

Det anbefales at bruge HTTP Strict Transport Security (HSTS) med HTTPS for at beskytte brugere mod man-in-the-middle-angreb, især SSL-stripping .

HTTPS må ikke forveksles med den sjældent anvendte Secure HTTP (S-HTTP), der er angivet i RFC 2660.

Anvendelse på websteder

Fra april 2018 bruger 33,2% af Alexa top 1.000.000 websteder HTTPS som standard, 57,1% af Internets 137.971 mest populære websteder har en sikker implementering af HTTPS, og 70% af sidens indlæsning (målt ved Firefox Telemetry) bruger HTTPS.

Browser integration

De fleste browsere viser en advarsel, hvis de modtager et ugyldigt certifikat. Ældre browsere, når de opretter forbindelse til et websted med et ugyldigt certifikat, vil præsentere brugeren for en dialogboks, der spørger, om de vil fortsætte. Nyere browsere viser en advarsel på tværs af hele vinduet. Nyere browsere viser også stedets sikkerhedsoplysninger på en fremtrædende måde i adresselinjen . Udvidede valideringscertifikater viser den juridiske enhed på certifikatoplysningerne. De fleste browsere viser også en advarsel til brugeren, når de besøger et websted, der indeholder en blanding af krypteret og ukrypteret indhold. Derudover returnerer mange webfiltre en sikkerhedsadvarsel, når de besøger forbudte websteder.

Den Electronic Frontier Foundation , opining, at "I en ideel verden, kunne hver webanmodning blive misligholdt til HTTPS", har givet en add-on kaldet HTTPS Everywhere til Mozilla Firefox , Google Chrome , Chrom , og Android , der gør det muligt HTTPS som standard til hundredvis af ofte anvendte websteder.

Sikkerhed

Sikkerheden ved HTTPS er den underliggende TLS, som typisk bruger langsigtede offentlige og private nøgler til at generere en kortsigtet sessionsnøgle , som derefter bruges til at kryptere datastrømmen mellem klienten og serveren. X.509 -certifikater bruges til at godkende serveren (og undertiden også klienten). Som en konsekvens heraf er certifikatmyndigheder og offentlige nøglecertifikater nødvendige for at verificere forholdet mellem certifikatet og dets ejer samt for at generere, underskrive og administrere gyldigheden af ​​certifikater. Selvom dette kan være mere fordelagtigt end at verificere identiteterne via et tillidsnet , henledte masseovervågningsoplysningerne fra 2013 opmærksomheden på certifikatmyndigheder som et potentielt svagt punkt, der tillader mand-i-midten-angreb . En vigtig egenskab i denne sammenhæng er fremadrettet hemmeligholdelse , som sikrer, at krypteret kommunikation, der er optaget tidligere, ikke kan hentes og dekrypteres, hvis langsigtede hemmelige nøgler eller adgangskoder kompromitteres i fremtiden. Ikke alle webservere giver fortrolig hemmelighed.

For at HTTPS skal være effektiv, skal et websted hostes fuldstændigt via HTTPS. Hvis noget af webstedets indhold indlæses via HTTP (f.eks. Scripts eller billeder), eller hvis kun en bestemt side, der indeholder følsomme oplysninger, f.eks. En log-in-side, indlæses over HTTPS, mens resten af ​​webstedet indlæses over almindelig HTTP, vil brugeren være sårbar over for angreb og overvågning. Derudover skal cookies på et websted, der serveres via HTTPS, have den sikre attribut aktiveret. På et websted, der har følsomme oplysninger om det, vil brugeren og sessionen blive udsat hver gang dette websted åbnes med HTTP i stedet for HTTPS.

Teknisk

Forskel fra HTTP

HTTPS URL'er begynder med "https: //" og bruger port 443 som standard, hvorimod HTTP URL'er begynder med "http: //" og bruger port 80 som standard.

HTTP er ikke krypteret og er derfor sårbar over for angreb fra man-i-midten og aflytning , som kan lade angribere få adgang til webstedskonti og følsomme oplysninger og ændre websider for at injicere malware eller reklamer. HTTPS er designet til at modstå sådanne angreb og anses for at være sikkert mod dem (med undtagelse af HTTPS -implementeringer, der bruger forældede versioner af SSL).

Netværkslag

HTTP fungerer på det højeste lag i TCP/IP -modellen - applikationslaget ; det samme gør TLS -sikkerhedsprotokollen (fungerer som et lavere underlag af det samme lag), som krypterer en HTTP -besked før transmission og dekrypterer en besked ved ankomsten. Strengt taget er HTTPS ikke en separat protokol, men refererer til brugen af ​​almindelig HTTP over en krypteret SSL/TLS -forbindelse.

HTTPS krypterer alt beskedindhold, herunder HTTP -overskrifterne og anmodnings-/svardataene. Med undtagelse af det mulige CCA -kryptografiske angreb, der er beskrevet i afsnittet om begrænsninger nedenfor, bør en angriber højst kunne opdage, at der finder en forbindelse sted mellem to parter, sammen med deres domænenavne og IP -adresser.

Server opsætning

For at forberede en webserver til at acceptere HTTPS -forbindelser skal administratoren oprette et offentligt nøglecertifikat til webserveren. Dette certifikat skal være underskrevet af en betroet certifikatmyndighed, for at webbrowseren kan acceptere det uden advarsel. Myndigheden attesterer, at certifikatholderen er operatøren af ​​den webserver, der præsenterer den. Webbrowsere distribueres generelt med en liste over signaturcertifikater fra større certifikatmyndigheder, så de kan verificere certifikater underskrevet af dem.

Erhvervelse af certifikater

Der findes en række kommercielle certifikatmyndigheder , der tilbyder betalte SSL/TLS-certifikater af en række typer, herunder udvidede valideringscertifikater .

Let's Encrypt , der blev lanceret i april 2016, tilbyder gratis og automatiseret service, der leverer grundlæggende SSL/TLS -certifikater til websteder. Ifølge Electronic Frontier Foundation vil Let's Encrypt gøre skift af HTTP til HTTPS "lige så let som at udstede en kommando eller klikke på en knap." Størstedelen af ​​webværter og cloududbydere udnytter nu Let's Encrypt og leverer gratis certifikater til deres kunder.

Brug som adgangskontrol

Systemet kan også bruges til klient -godkendelse for at begrænse adgangen til en web-server til autoriserede brugere. For at gøre dette opretter stedets administrator typisk et certifikat for hver bruger, som brugeren indlæser i deres browser. Normalt indeholder certifikatet navn og e-mail-adresse på den autoriserede bruger og kontrolleres automatisk af serveren på hver forbindelse for at verificere brugerens identitet, muligvis uden selv at kræve et kodeord.

I tilfælde af kompromitteret hemmelig (privat) nøgle

En vigtig egenskab i denne sammenhæng er perfekt fremadrettet hemmeligholdelse (PFS). Besiddelse af en af ​​de langsigtede asymmetriske hemmelige nøgler, der bruges til at oprette en HTTPS-session, bør ikke gøre det lettere at udlede den kortsigtede sessionsnøgle for derefter at dekryptere samtalen, selv på et senere tidspunkt. Diffie - Hellman nøgleudveksling (DHE) og elliptisk kurve Diffie - Hellman nøgleudveksling (ECDHE) er i 2013 de eneste ordninger, der vides at have denne ejendom. I 2013 brugte det kun 30% af Firefox-, Opera- og Chromium -browsersessioner og næsten 0% af Apples Safari- og Microsoft Internet Explorer -sessioner. TLS 1.3, der blev offentliggjort i august 2018, droppede støtten til cifre uden fremadrettet hemmeligholdelse. Fra februar 2020 understøtter 96,6% af de adspurgte webservere en eller anden form for fremadrettet hemmeligholdelse, og 52,1% vil bruge fremadrettet hemmeligholdelse med de fleste browsere.

Et certifikat kan tilbagekaldes, før det udløber, for eksempel fordi hemmeligholdelsen af ​​den private nøgle er blevet kompromitteret. Nyere versioner af populære browsere, f.eks. Firefox , Opera og Internet Explorer i Windows Vista, implementerer Online Certificate Status Protocol (OCSP) for at kontrollere, at dette ikke er tilfældet. Browseren sender certifikatets serienummer til certifikatmyndigheden eller dennes delegerede via OCSP (Online Certificate Status Protocol), og myndigheden reagerer og fortæller browseren, om certifikatet stadig er gyldigt eller ej. CA kan også udstede en CRL for at fortælle folk, at disse certifikater tilbagekaldes.

Begrænsninger

SSL (Secure Sockets Layer) og TLS (Transport Layer Security) kryptering kan konfigureres i to tilstande: enkel og gensidig . I enkel tilstand udføres godkendelse kun af serveren. Den gensidige version kræver, at brugeren installerer et personligt klientcertifikat i webbrowseren til brugergodkendelse. I begge tilfælde afhænger beskyttelsesniveauet af rigtigheden af implementeringen af softwaren og de anvendte kryptografiske algoritmer .

SSL/TLS forhindrer ikke indeksering af webstedet ved en webcrawler , og i nogle tilfælde kan URI for den krypterede ressource udledes ved kun at kende den aflyttede anmodning/svarstørrelse. Dette giver en hacker mulighed for at få adgang til klarteksten (det offentligt tilgængelige statiske indhold) og den krypterede tekst (den krypterede version af det statiske indhold), hvilket tillader et kryptografisk angreb .

Fordi TLS opererer på et protokolniveau under HTTP's og ikke har kendskab til protokollerne på højere niveau, kan TLS-servere kun strengt præsentere ét certifikat for en bestemt adresse og portkombination. Tidligere betød dette, at det ikke var muligt at bruge navnebaseret virtuel hosting med HTTPS. Der findes en løsning kaldet Server Name Indication (SNI), som sender værtsnavnet til serveren, før forbindelsen krypteres, selvom mange gamle browsere ikke understøtter denne udvidelse. Understøttelse af SNI er tilgængelig siden Firefox 2, Opera 8, Apple Safari 2.1, Google Chrome 6 og Internet Explorer 7Windows Vista .

Fra et arkitektonisk synspunkt:

  • En SSL/TLS -forbindelse administreres af den første frontmaskine, der starter TLS -forbindelsen. Hvis denne frontmaskine af en eller anden grund (routing, trafikoptimering osv.) Ikke er applikationsserveren, og den skal dechiffrere data, skal der findes løsninger for at sprede brugerautentificeringsoplysninger eller certifikat til applikationsserveren, som skal vide, hvem der vil blive forbundet.
  • For SSL/TLS med gensidig godkendelse administreres SSL/TLS -sessionen af ​​den første server, der starter forbindelsen. I situationer, hvor kryptering skal spredes langs kædet servere, bliver administration af session timeout ekstremt vanskelig at implementere.
  • Sikkerheden er maksimal med gensidig SSL/TLS, men på klientsiden er der ingen måde at afslutte SSL/TLS-forbindelsen korrekt og afbryde brugeren, undtagen ved at vente på, at serversessionen udløber eller ved at lukke alle relaterede klientprogrammer.

En sofistikeret type mand-i-midten-angreb kaldet SSL-stripping blev præsenteret på Blackhat-konferencen i 2009 . Denne type angreb besejrer sikkerheden fra HTTPS ved at ændre https:linket til et http:link og drage fordel af det faktum, at få internetbrugere faktisk skriver "https" i deres browserinterface: de kommer til et sikkert websted ved at klikke på et link, og bliver derfor narret til at tro, at de bruger HTTPS, når de faktisk bruger HTTP. Angriberen kommunikerer derefter klart med klienten. Dette fik udviklingen af ​​et modforanstaltning i HTTP kaldet HTTP Strict Transport Security .

HTTPS har vist sig at være sårbar over for en række trafikanalyseanfald . Trafikanalyseangreb er en type sidekanalangreb, der er afhængig af variationer i trafikkens timing og størrelse for at udlede egenskaber om selve den krypterede trafik. Trafikanalyse er mulig, fordi SSL/TLS -kryptering ændrer trafikindholdet, men har minimal indflydelse på trafikkens størrelse og timing. I maj 2010 opdagede et forskningsoplæg af forskere fra Microsoft Research og Indiana University , at detaljerede følsomme brugerdata kan udledes fra sidekanaler, f.eks. Pakkestørrelser. Forskerne fandt ud af, at på trods af HTTPS-beskyttelse i flere højt profilerede, top-of-the-line webapplikationer inden for sundhedspleje, beskatning, investeringer og websøgning, kunne en aflyttere udlede brugerens sygdomme/medicin/operationer, hans/ hendes familieindkomst og investeringshemmeligheder. Selvom dette arbejde demonstrerede HTTPS 'sårbarhed over for trafikanalyse, krævede forfatterens fremgangsmåde manuel analyse og fokuserede specifikt på webapplikationer beskyttet af HTTPS.

Det faktum, at de fleste moderne websteder, herunder Google, Yahoo !, og Amazon, bruger HTTPS forårsager problemer for mange brugere, der prøver at få adgang til offentlige Wi-Fi-hotspots, fordi en login-side til Wi-Fi-hotspot ikke kan indlæses, hvis brugeren forsøger at åbne en HTTPS -ressource. Flere websteder, såsom neverssl.com og nonhttps.com , garanterer, at de altid vil forblive tilgængelige via HTTP.

Historie

Netscape Communications oprettede HTTPS i 1994 til sin Netscape Navigator -webbrowser. Oprindeligt blev HTTPS brugt med SSL -protokollen. Da SSL udviklede sig til Transport Layer Security (TLS), blev HTTPS formelt specificeret af RFC 2818 i maj 2000. Google meddelte i februar 2018, at dens Chrome -browser ville markere HTTP -websteder som "Ikke sikre" efter juli 2018. Dette skridt var at opmuntre webstedet ejere til at implementere HTTPS, som et forsøg på at gøre World Wide Web mere sikkert.

Se også

Referencer

eksterne links