HTTPS - HTTPS

Hypertext Transfer Protocol Secure ( HTTPS ) är en förlängning av Hypertext Transfer Protocol (HTTP). Den används för säker kommunikation över ett datornätverk och används ofta på Internet. I HTTPS krypteras kommunikationsprotokollet med Transport Layer Security (TLS) eller tidigare Secure Sockets Layer (SSL). Protokollet kallas därför också HTTP över TLS eller HTTP över SSL .

De huvudsakliga motiveringarna för HTTPS är autentisering av den åtkomliga webbplatsen och skydd av integriteten och integriteten för de utbytta data under transport. Det skyddar mot man-in-the-middle-attacker och dubbelriktad kryptering av kommunikation mellan en klient och server skyddar kommunikationen mot avlyssning och manipulering . Autentiseringsaspekten för HTTPS kräver att en pålitlig tredje part signerar digitala certifikat på serversidan . Detta var historiskt sett en dyr operation, vilket innebar att fullständigt autentiserade HTTPS -anslutningar vanligtvis endast hittades på säkra betaltransaktionstjänster och andra säkra företagsinformationssystem på World Wide Web . 2016 ledde en kampanj av Electronic Frontier Foundation med stöd av webbläsarutvecklare till att protokollet blev allt vanligare. HTTPS används nu oftare av webbanvändare än den ursprungliga osäkra HTTP, främst för att skydda sidautenticitet på alla typer av webbplatser; säkra konton; och för att hålla användarkommunikation, identitet och surfning privat.

Översikt

URL som börjar med HTTPS -schemat och WWW -domännamnsetiketten

Den Uniform Resource Identifier (URI) schema HTTPS har identisk användning syntax till HTTP systemet. HTTPS signalerar dock webbläsaren att använda ett extra krypteringslager av SSL/TLS för att skydda trafiken. SSL/TLS är särskilt lämpad för HTTP, eftersom det kan ge ett visst skydd även om bara ena sidan av kommunikationen är autentiserad . Detta är fallet med HTTP -transaktioner över Internet, där vanligtvis bara servern autentiseras (av klienten som undersöker serverns certifikat ).

HTTPS skapar en säker kanal över ett osäkert nätverk. Detta säkerställer rimligt skydd mot avlyssnare och man-in-the-middle-attacker , förutsatt att lämpliga krypteringssviter används och att servercertifikatet verifieras och litas på.

Eftersom HTTPS piggybacks HTTP helt ovanpå TLS kan hela det underliggande HTTP -protokollet krypteras. Detta inkluderar begäran URL (vilken viss webbsida begärdes), frågeparametrar, rubriker och cookies (som ofta innehåller identifierande information om användaren). Men eftersom webbadresser och portnummer nödvändigtvis är en del av de underliggande TCP/IP -protokollen kan HTTPS inte skydda deras avslöjande. I praktiken betyder detta att även på en korrekt konfigurerad webbserver kan avlyssnare utläsa webbserverns IP -adress och portnummer, och ibland även domännamnet (t.ex. www.example.org, men inte resten av webbadressen) som en användare kommunicerar med, tillsammans med mängden data som överförs och kommunikationens varaktighet, men inte kommunikationens innehåll.

Webbläsare vet hur man litar på HTTPS-webbplatser baserat på certifikatutfärdare som finns förinstallerade i deras programvara. Certifikatmyndigheterna litar på detta sätt av webbläsarskapare för att tillhandahålla giltiga certifikat. Därför bör en användare lita på en HTTPS -anslutning till en webbplats om och bara om allt följande är sant:

Användaren litar på att webbläsarprogramvaran implementerar HTTPS korrekt med korrekt förinstallerade certifikatutfärdare.
Användaren litar på att certifikatmyndigheten endast garanterar legitima webbplatser.
Webbplatsen tillhandahåller ett giltigt certifikat, vilket betyder att det är undertecknat av en betrodd myndighet.
Certifikatet identifierar webbplatsen korrekt (t.ex. när webbläsaren besöker " https://example.com " är det mottagna certifikatet korrekt för "example.com" och inte någon annan enhet).
Användaren litar på att protokollets krypteringslager (SSL/TLS) är tillräckligt säkert mot avlyssning.

HTTPS är särskilt viktigt över osäkra nätverk och nätverk som kan utsättas för manipulering. Osäkra nätverk, till exempel offentliga Wi-Fi- åtkomstpunkter, gör att alla i samma lokala nätverk kan paket-sniffa och upptäcka känslig information som inte skyddas av HTTPS. Dessutom har vissa gratis och användbara WLAN- nätverk observerats manipulera med webbsidor genom att delta i paketinjektion för att kunna visa sina egna annonser på andra webbplatser. Denna praxis kan utnyttjas skadligt på många sätt, till exempel genom att injicera skadlig kod på webbsidor och stjäla användarnas privata information.

HTTPS är också viktigt för anslutningar via Tor -nätverket , eftersom skadliga Tor -noder annars kan skada eller förändra innehållet som passerar dem på ett osäkert sätt och injicera skadlig kod i anslutningen. Detta är en anledning till att Electronic Frontier Foundation och Tor -projektet startade utvecklingen av HTTPS Everywhere , som ingår i Tor Browser.

I takt med att mer information avslöjas om global massövervakning och kriminella som stjäl personlig information blir användningen av HTTPS -säkerhet på alla webbplatser allt viktigare oavsett vilken typ av internetanslutning som används. Även om metadata om enskilda sidor som en användare besöker kanske inte anses vara känsliga, kan det vid aggregering avslöja mycket om användaren och äventyra användarens integritet.

Genom att implementera HTTPS kan man också använda HTTP/2 (eller dess föregångare, det nu utfasade protokollet SPDY ), som är en ny generation HTTP som är utformad för att minska sidladdningstider, storlek och latens.

Det rekommenderas att använda HTTP Strict Transport Security (HSTS) med HTTPS för att skydda användare från man-in-the-middle-attacker, särskilt SSL-strippning .

HTTPS bör inte förväxlas med den sällan använda Secure HTTP (S-HTTP) som anges i RFC 2660.

Användning på webbplatser

I april 2018 använder 33,2% av Alexa topp 1 000 000 webbplatser HTTPS som standard, 57,1% av Internets 137 971 mest populära webbplatser har en säker implementering av HTTPS och 70% av sidbelastningar (mätt med Firefox Telemetry) använder HTTPS.

Webbläsarintegration

De flesta webbläsare visar en varning om de får ett ogiltigt certifikat. Äldre webbläsare, när de ansluter till en webbplats med ett ogiltigt certifikat, skulle presentera användaren med en dialogruta som frågar om de vill fortsätta. Nyare webbläsare visar en varning i hela fönstret. Nyare webbläsare visar också webbplatsens säkerhetsinformation på ett tydligt sätt i adressfältet . Utökade valideringscertifikat visar den juridiska personen på certifikatinformationen. De flesta webbläsare visar också en varning för användaren när du besöker en webbplats som innehåller en blandning av krypterat och okrypterat innehåll. Dessutom returnerar många webbfilter en säkerhetsvarning när du besöker förbjudna webbplatser.

Jämförelse mellan olika typer av SSL/TLS -certifikat
(med Firefox som exempel)

Många webbläsare, inklusive Firefox (visas här), använder adressfältet för att berätta för användaren att deras anslutning är säker, ett utökat valideringscertifikat bör identifiera den juridiska enheten för certifikatet.
Vid åtkomst till en webbplats endast med ett gemensamt certifikat, i adressfältet i Firefox och andra webbläsare , visas ett "lås" -skylt.
De flesta webbläsare varnar användaren vid besök på webbplatser som har ogiltiga säkerhetscertifikat.

Den Electronic Frontier Foundation , opining att "I en perfekt värld skulle varje webbsida begäran som standard HTTPS", har gett en add-on kallas HTTPS Everywhere för Mozilla Firefox , Google Chrome , Krom , och Android , som gör det möjligt HTTPS som standard för hundratals vanliga webbplatser.

säkerhet

Säkerheten för HTTPS är den för den underliggande TLS, som vanligtvis använder långsiktiga offentliga och privata nycklar för att generera en kortsiktig sessionsnyckel , som sedan används för att kryptera dataflödet mellan klienten och servern. X.509 -certifikat används för att autentisera servern (och ibland även klienten). Som en konsekvens är certifikatmyndigheter och certifikat för allmänna nycklar nödvändiga för att verifiera förhållandet mellan certifikatet och dess ägare, samt för att generera, underteckna och administrera certifikatens giltighet. Även om detta kan vara mer fördelaktigt än att verifiera identiteterna via ett nät av förtroende , uppmärksammade massövervakningsupplysningarna från 2013 uppmärksamhet på certifikatmyndigheter som en potentiell svag punkt som möjliggör attacker i mitten . En viktig egenskap i detta sammanhang är sekretess framåt , vilket säkerställer att krypterad kommunikation som spelats in tidigare inte kan hämtas och dekrypteras om långsiktiga hemliga nycklar eller lösenord äventyras i framtiden. Alla webbservrar ger inte sekretess framåt.

För att HTTPS ska vara effektiv måste en webbplats vara helt värd över HTTPS. Om en del av webbplatsens innehåll laddas över HTTP (skript eller bilder, till exempel), eller om bara en viss sida som innehåller känslig information, till exempel en inloggningssida, laddas över HTTPS medan resten av webbplatsen laddas över vanlig HTTP är användaren sårbar för attacker och övervakning. Dessutom måste cookies på en webbplats som serveras via HTTPS ha det säkra attributet aktiverat. På en webbplats som har känslig information kommer användaren och sessionen att avslöjas varje gång webbplatsen öppnas med HTTP istället för HTTPS.

Teknisk

Skillnad från HTTP

HTTPS -webbadresser börjar med "https: //" och använder port 443 som standard, medan HTTP -webbadresser börjar med "http: //" och använder port 80 som standard.

HTTP är inte krypterat och är därför sårbart för attacker från människan i mitten och avlyssning , som kan låta angripare få tillgång till webbplatskonton och känslig information och ändra webbsidor för att injicera skadlig kod eller annonser. HTTPS är utformat för att motstå sådana attacker och anses vara säkert mot dem (med undantag för HTTPS -implementeringar som använder utfasade versioner av SSL).

Nätverkslager

HTTP fungerar på det högsta lagret i TCP/IP -modellen - applikationslagret ; liksom TLS -säkerhetsprotokollet (som fungerar som ett lägre underlager av samma lager), som krypterar ett HTTP -meddelande före överföring och dekrypterar ett meddelande vid ankomst. Strikt taget är HTTPS inte ett separat protokoll, utan hänvisar till användningen av vanlig HTTP över en krypterad SSL/TLS -anslutning.

HTTPS krypterar allt meddelandeinnehåll, inklusive HTTP -rubriker och förfrågnings-/svarsdata. Med undantag för den möjliga CCA -kryptografiska attacken som beskrivs i begränsningsavsnittet nedan, bör en angripare högst kunna upptäcka att en anslutning sker mellan två parter, tillsammans med deras domännamn och IP -adresser.

Serverinställning

För att förbereda en webbserver för att acceptera HTTPS -anslutningar måste administratören skapa ett offentligt nyckelcertifikat för webbservern. Detta certifikat måste vara signerat av en betrodd certifikatutfärdare för att webbläsaren ska kunna acceptera det utan förvarning. Myndigheten intygar att certifikatinnehavaren är operatören för webbservern som presenterar den. Webbläsare distribueras i allmänhet med en lista över signeringscertifikat från större certifikatmyndigheter så att de kan verifiera certifikat signerade av dem.

Skaffa certifikat

Det finns ett antal kommersiella certifikatmyndigheter som erbjuder betalda SSL/TLS-certifikat av ett antal typer, inklusive Extended Validation Certificates .

Let's Encrypt , som lanserades i april 2016, erbjuder gratis och automatiserad tjänst som levererar grundläggande SSL/TLS -certifikat till webbplatser. Enligt Electronic Frontier Foundation kommer Let's Encrypt att göra bytet från HTTP till HTTPS "lika enkelt som att utfärda ett kommando eller klicka på en knapp." Majoriteten av webbhotell och molnleverantörer utnyttjar nu Let's Encrypt och tillhandahåller gratis certifikat till sina kunder.

Använd som åtkomstkontroll

Systemet kan också användas för klientautentisering för att begränsa åtkomsten till en webbserver till auktoriserade användare. För att göra detta skapar webbplatsadministratören vanligtvis ett certifikat för varje användare som användaren läser in i sin webbläsare. Normalt innehåller certifikatet den auktoriserade användarens namn och e-postadress och kontrolleras automatiskt av servern på varje anslutning för att verifiera användarens identitet, eventuellt utan att ens behöva ett lösenord.

Vid komprometterad hemlig (privat) nyckel

En viktig egenskap i detta sammanhang är perfekt framåt sekretess (PFS). Att ha en av de långsiktiga asymmetriska hemliga nycklarna som används för att upprätta en HTTPS-session bör inte göra det lättare att härleda den kortvariga sessionsnyckeln för att sedan dekryptera konversationen, även vid ett senare tillfälle. Nyckelutbyte Diffie – Hellman (DHE) och Elliptic curve Diffie – Hellman -nyckelbyte (ECDHE) är 2013 de enda systemen som är kända för att ha den egenskapen. År 2013 använde endast 30% av Firefox-, Opera- och Chromium -webbläsarsessionerna det och nästan 0% av Apples Safari- och Microsoft Internet Explorer -sessioner. TLS 1.3, publicerad i augusti 2018, tappade stödet för chiffer utan sekretess. Från och med februari 2020 stöder 96,6% av de undersökta webbservrarna någon form av sekretess framåt, och 52,1% använder sekretess framåt med de flesta webbläsare.

Ett certifikat kan återkallas innan det löper ut, till exempel eftersom sekretessen för den privata nyckeln har äventyrats. Nyare versioner av populära webbläsare som Firefox , Opera och Internet Explorer på Windows Vista implementerar Online Certificate Status Protocol (OCSP) för att verifiera att så inte är fallet. Webbläsaren skickar certifikatets serienummer till certifikatmyndigheten eller dess ombud via OCSP (Online Certificate Status Protocol) och myndigheten svarar och berättar för webbläsaren om certifikatet fortfarande är giltigt eller inte. CA kan också utfärda en CRL för att berätta för folk att dessa intyg återkallas.

Begränsningar

SSL (Secure Sockets Layer) och TLS (Transport Layer Security) kryptering kan konfigureras i två lägen: enkel och ömsesidig . I enkelt läge utförs autentisering endast av servern. Den ömsesidiga versionen kräver att användaren installerar ett personligt klientcertifikat i webbläsaren för användarautentisering. I båda fallen beror skyddsnivån på riktigheten i implementeringen av programvaran och de kryptografiska algoritmer som används.

SSL/TLS förhindrar inte indexering av webbplatsen av en webbsökare , och i vissa fall kan URI för den krypterade resursen härledas genom att bara känna till den avlyssnade begäran/svarsstorleken. Detta gör det möjligt för en angripare att ha tillgång till klartext (det allmänt tillgängliga statiska innehållet) och den krypterade texten (den krypterade versionen av det statiska innehållet), vilket möjliggör en kryptografisk attack .

Eftersom TLS fungerar på en protokollnivå under HTTP och inte har kunskap om protokollen på högre nivå, kan TLS-servrar endast strikt presentera ett certifikat för en viss adress- och portkombination. Tidigare innebar detta att det inte var möjligt att använda namnbaserad virtuell hosting med HTTPS. Det finns en lösning som heter Server Name Indication (SNI), som skickar värdnamnet till servern innan den krypterar anslutningen, även om många gamla webbläsare inte stöder detta tillägg. Stöd för SNI är tillgängligt sedan Firefox 2, Opera 8, Apple Safari 2.1, Google Chrome 6 och Internet Explorer 7 på Windows Vista .

Ur arkitektonisk synvinkel:

En SSL/TLS -anslutning hanteras av den första frontmaskinen som initierar TLS -anslutningen. Om denna frontmaskin av några skäl (routning, trafikoptimering etc.) inte är applikationsservern och den måste dechiffrera data måste lösningar hittas för att sprida användarautentiseringsinformation eller certifikat till applikationsservern, som måste vet vem som ska anslutas.
För SSL/TLS med ömsesidig autentisering hanteras SSL/TLS -sessionen av den första servern som initierar anslutningen. I situationer där kryptering måste spridas längs kedjade servrar blir hantering av session timeOut extremt knepig att implementera.
Säkerheten är maximal med ömsesidig SSL/TLS, men på klientsidan finns det inget sätt att korrekt avsluta SSL/TLS-anslutningen och koppla bort användaren förutom genom att vänta på att serversessionen löper ut eller genom att stänga alla relaterade klientprogram.

En sofistikerad typ av man-i-mitten-attack som kallas SSL-strippning presenterades vid Blackhat-konferensen 2009 . Denna typ av attack besegrar säkerheten från HTTPS genom att ändra https:länken till en http:länk, med fördel att få Internetanvändare faktiskt skriver "https" i deras webbläsargränssnitt: de kommer till en säker webbplats genom att klicka på en länk, och blir därför lurade att tro att de använder HTTPS när de faktiskt använder HTTP. Angriparen kommunicerar sedan tydligt med klienten. Detta föranledde utvecklingen av en motåtgärd i HTTP som kallas HTTP Strict Transport Security .

HTTPS har visat sig vara sårbart för en rad olika trafikanalysattacker . Trafikanalysattacker är en typ av sidokanalangrepp som förlitar sig på variationer i tidpunkten och storleken på trafiken för att dra slutsatser om själva den krypterade trafiken. Trafikanalys är möjlig eftersom SSL/TLS -kryptering ändrar trafikinnehållet, men har minimal inverkan på trafikens storlek och tidpunkt. I maj 2010 upptäckte en forskningsrapport av forskare från Microsoft Research och Indiana University att detaljerad känslig användardata kan härledas från sidokanaler som paketstorlekar. Forskarna fann att, trots HTTPS-skydd i flera högprofilerade, högklassiga webbapplikationer inom vård, beskattning, investeringar och webbsökning, kan en avlyssning utläsa användarens sjukdomar/mediciner/operationer, hans/hennes hennes familjens inkomst och investeringshemligheter. Även om detta arbete visade sårbarheten hos HTTPS för trafikanalys, krävde den metod som presenterades av författarna manuell analys och fokuserade specifikt på webbapplikationer som skyddas av HTTPS.

Det faktum att de flesta moderna webbplatser, inklusive Google, Yahoo! Och Amazon, använder HTTPS orsakar problem för många användare som försöker komma åt offentliga Wi-Fi-hotspots, eftersom en inloggningssida för Wi-Fi-hotspot inte kan laddas om användaren försöker öppna en HTTPS -resurs. Flera webbplatser, till exempel neverssl.com och nonhttps.com , garanterar att de alltid kommer att vara tillgängliga med HTTP.

Historia

Netscape Communications skapade HTTPS 1994 för sin webbläsare Netscape Navigator . Ursprungligen användes HTTPS med SSL -protokollet. När SSL utvecklades till Transport Layer Security (TLS) specificerades HTTPS formellt av RFC 2818 i maj 2000. Google meddelade i februari 2018 att dess Chrome -webbläsare skulle markera HTTP -webbplatser som "Inte säkra" efter juli 2018. Detta steg var att uppmuntra webbplatsen ägare att implementera HTTPS, som ett försök att göra World Wide Web säkrare.

Se även

Bullrun (dekrypteringsprogram) -ett hemligt antikrypteringsprogram som drivs av USA: s nationella säkerhetsbyrå
Datorsäkerhet
HSTS
HTTPsec
Moxie Marlinspike
Opportunistisk kryptering
Stunnel

Languages

In other projects