HTTPS — HTTPS

Hypertext Transfer Protocol Secure ( HTTPS ) jest rozszerzeniem Hypertext Transfer Protocol (HTTP). Służy do bezpiecznej komunikacji w sieci komputerowej i jest szeroko stosowany w Internecie. W HTTPS protokół komunikacyjny jest szyfrowany przy użyciu protokołu Transport Layer Security (TLS) lub wcześniej Secure Sockets Layer (SSL). Protokół jest zatem również określany jako HTTP przez TLS lub HTTP przez SSL .

Główną motywacją dla HTTPS jest uwierzytelnianie odwiedzanej strony internetowej oraz ochrona prywatności i integralności wymienianych danych podczas przesyłania. Chroni przed atakami typu man-in-the-middle , a dwukierunkowe szyfrowanie komunikacji między klientem a serwerem chroni komunikację przed podsłuchem i manipulacją . Aspekt uwierzytelniania protokołu HTTPS wymaga podpisania certyfikatów cyfrowych po stronie serwera przez zaufaną firmę zewnętrzną . Była to historycznie kosztowna operacja, co oznaczało, że w pełni uwierzytelnione połączenia HTTPS były zwykle znajdowane tylko w zabezpieczonych usługach transakcji płatniczych i innych zabezpieczonych korporacyjnych systemach informatycznych w sieci WWW . W 2016 roku kampania Electronic Frontier Foundation przy wsparciu twórców przeglądarek internetowych doprowadziła do tego, że protokół stał się bardziej rozpowszechniony. HTTPS jest obecnie częściej używany przez użytkowników sieci niż oryginalny niezabezpieczony protokół HTTP, przede wszystkim w celu ochrony autentyczności stron we wszystkich typach witryn internetowych; bezpieczne konta; oraz aby zachować prywatność komunikacji użytkownika, tożsamości i przeglądania stron internetowych.

Przegląd

URL rozpoczynający się schematem HTTPS i etykietą nazwy domeny WWW

Schemat Uniform Resource Identifier (URI) HTTPS ma identyczną składnię użycia jak schemat HTTP. Jednak protokół HTTPS sygnalizuje przeglądarce użycie dodatkowej warstwy szyfrowania SSL/TLS w celu ochrony ruchu. Protokół SSL/TLS jest szczególnie odpowiedni dla protokołu HTTP, ponieważ może zapewnić pewną ochronę, nawet jeśli uwierzytelniona jest tylko jedna strona komunikacji . Tak jest w przypadku transakcji HTTP przez Internet, gdzie zazwyczaj uwierzytelniany jest tylko serwer (przez klienta badającego certyfikat serwera ).

HTTPS tworzy bezpieczny kanał w niezabezpieczonej sieci. Zapewnia to rozsądną ochronę przed podsłuchiwaniem i atakami typu man-in-the-middle , pod warunkiem, że używane są odpowiednie mechanizmy szyfrowania, a certyfikat serwera jest zweryfikowany i zaufany.

Ponieważ HTTPS łączy HTTP całkowicie z TLS, cały podstawowy protokół HTTP może być zaszyfrowany. Obejmuje to adres URL żądania (której konkretna strona internetowa została zażądana), parametry zapytania, nagłówki i pliki cookie (które często zawierają informacje identyfikujące użytkownika). Jednak ponieważ adresy witryn internetowych i numery portów są koniecznie częścią podstawowych protokołów TCP/IP, protokół HTTPS nie może chronić ich ujawnienia. W praktyce oznacza to, że nawet na poprawnie skonfigurowanym serwerze WWW podsłuchujący mogą wywnioskować adres IP i numer portu serwera WWW, a czasem nawet nazwę domeny (np. www.example.org, ale nie resztę adresu URL), które użytkownik komunikuje się wraz z ilością przesyłanych danych i czasem trwania komunikacji, ale nie treścią komunikacji.

Przeglądarki internetowe wiedzą, jak ufać witrynom HTTPS w oparciu o urzędy certyfikacji, które są fabrycznie zainstalowane w ich oprogramowaniu. W ten sposób twórcy przeglądarek internetowych ufają urzędom certyfikacji, które dostarczają ważne certyfikaty. Dlatego użytkownik powinien ufać połączeniu HTTPS z witryną internetową wtedy i tylko wtedy, gdy spełnione są wszystkie poniższe warunki:

  • Użytkownik ufa, że ​​oprogramowanie przeglądarki poprawnie implementuje protokół HTTPS z prawidłowo zainstalowanymi urzędami certyfikacji.
  • Użytkownik ufa, że ​​urząd certyfikacji ręczy tylko za legalne witryny.
  • Witryna dostarcza ważny certyfikat, co oznacza, że ​​została podpisana przez zaufany urząd.
  • Certyfikat poprawnie identyfikuje stronę internetową (np. gdy przeglądarka odwiedza „ https://example.com ”, otrzymany certyfikat jest poprawnie dla „example.com”, a nie jakiegoś innego podmiotu).
  • Użytkownik ufa, że ​​warstwa szyfrowania protokołu (SSL/TLS) jest wystarczająco zabezpieczona przed podsłuchem.

HTTPS jest szczególnie ważny w przypadku niezabezpieczonych sieci i sieci, które mogą podlegać manipulacji. Niezabezpieczone sieci, takie jak publiczne punkty dostępu Wi-Fi , umożliwiają każdemu w tej samej sieci lokalnej wykrywanie pakietów i wykrywanie poufnych informacji, które nie są chronione przez protokół HTTPS. Ponadto zaobserwowano , że niektóre bezpłatne i płatne sieci WLAN manipulują stronami internetowymi poprzez wstrzykiwanie pakietów w celu wyświetlania własnych reklam w innych witrynach. Praktyka ta może być złośliwie wykorzystywana na wiele sposobów, na przykład poprzez wstrzykiwanie złośliwego oprogramowania na strony internetowe i kradzież prywatnych informacji użytkowników.

HTTPS jest również ważny dla połączeń przez sieć Tor , ponieważ złośliwe węzły Tora mogą w inny sposób uszkodzić lub zmienić przesyłaną przez nie zawartość w niezabezpieczony sposób i wstrzyknąć złośliwe oprogramowanie do połączenia. To jeden z powodów, dla których Electronic Frontier Foundation i Projekt Tor rozpoczęły rozwój HTTPS Everywhere , który jest zawarty w przeglądarce Tor.

W miarę pojawiania się coraz większej ilości informacji o globalnej masowej inwigilacji i przestępcach wykradających dane osobowe, korzystanie z zabezpieczeń HTTPS na wszystkich stronach internetowych staje się coraz ważniejsze, niezależnie od rodzaju używanego połączenia internetowego. Mimo że metadane dotyczące poszczególnych stron odwiedzanych przez użytkownika mogą nie być uważane za poufne, ale zagregowane mogą wiele ujawnić o użytkowniku i naruszyć jego prywatność.

Wdrożenie protokołu HTTPS umożliwia również korzystanie z protokołu HTTP/2 (lub jego poprzednika, obecnie przestarzałego protokołu SPDY ), który jest nową generacją protokołu HTTP zaprojektowaną w celu zmniejszenia czasu ładowania strony, rozmiaru i opóźnień.

Zaleca się korzystanie z protokołu HTTP Strict Transport Security (HSTS) z protokołem HTTPS w celu ochrony użytkowników przed atakami typu „man-in-the-middle”, w szczególności z usuwaniem SSL .

HTTPS nie należy mylić z rzadko używanym bezpiecznym HTTP (S-HTTP) określonym w RFC 2660.

Wykorzystanie na stronach internetowych

W kwietniu 2018 r. 33,2% najpopularniejszych witryn Alexa korzystało domyślnie z protokołu HTTPS, 57,1% z 137 971 najpopularniejszych witryn internetowych ma bezpieczną implementację protokołu HTTPS, a 70% wczytywania stron (mierzone przez telemetrię Firefox) korzysta z protokołu HTTPS.

Integracja z przeglądarką

Większość przeglądarek wyświetla ostrzeżenie, jeśli otrzymają nieprawidłowy certyfikat. Starsze przeglądarki, łącząc się z witryną z nieprawidłowym certyfikatem, wyświetlały użytkownikowi okno dialogowe z pytaniem, czy chce kontynuować. Nowsze przeglądarki wyświetlają ostrzeżenie w całym oknie. W nowszych przeglądarkach informacje dotyczące bezpieczeństwa witryny są również w widoczny sposób wyświetlane na pasku adresu . Rozszerzone certyfikaty walidacji pokazują osobę prawną w informacjach o certyfikacie. Większość przeglądarek wyświetla również ostrzeżenie podczas odwiedzania witryny, która zawiera mieszankę zaszyfrowanej i niezaszyfrowanej treści. Ponadto wiele filtrów internetowych zwraca ostrzeżenie dotyczące bezpieczeństwa podczas odwiedzania zabronionych witryn internetowych.

Electronic Frontier Foundation , opiniowanie, że „W idealnym świecie, każdy wniosek może ona być domyślnie HTTPS”, dostarczył dodatek nazywa HTTPS Everywhere dla Firefoksa , Google Chrome , chromu i Androida , która umożliwia HTTPS domyślnie dla setki często używanych stron internetowych.

Bezpieczeństwo

Bezpieczeństwo protokołu HTTPS jest związane z podstawowym protokołem TLS, który zazwyczaj używa długoterminowych kluczy publicznych i prywatnych do generowania krótkoterminowego klucza sesji , który jest następnie używany do szyfrowania przepływu danych między klientem a serwerem. Certyfikaty X.509 służą do uwierzytelniania serwera (a czasami także klienta). W konsekwencji urzędy certyfikacji i certyfikaty klucza publicznego są niezbędne do weryfikacji relacji między certyfikatem a jego właścicielem, a także do generowania, podpisywania i administrowania ważnością certyfikatów. Chociaż może to być bardziej korzystne niż weryfikacja tożsamości za pomocą sieci zaufania , ujawnienia z masowego nadzoru z 2013 r. zwróciły uwagę na organy certyfikujące jako potencjalny słaby punkt umożliwiający ataki typu man-in-the-middle . Ważną właściwością w tym kontekście jest tajność przekazywania , która zapewnia, że ​​zaszyfrowana komunikacja nagrana w przeszłości nie może zostać odzyskana i odszyfrowana w przypadku złamania długoterminowych tajnych kluczy lub haseł w przyszłości. Nie wszystkie serwery internetowe zapewniają tajność przekazywania.

Aby protokół HTTPS był skuteczny, witryna musi być w całości hostowana za pośrednictwem protokołu HTTPS. Jeśli część zawartości witryny jest ładowana przez HTTP (na przykład skrypty lub obrazy) lub jeśli tylko określona strona zawierająca poufne informacje, takie jak strona logowania, jest ładowana przez HTTPS, podczas gdy ładowana jest reszta witryny w przypadku zwykłego protokołu HTTP użytkownik będzie narażony na ataki i inwigilację. Ponadto pliki cookie w witrynie obsługiwanej przez HTTPS muszą mieć włączony atrybut secure . W witrynie, która zawiera poufne informacje, użytkownik i sesja zostaną ujawnieni za każdym razem, gdy witryna zostanie otwarta za pomocą protokołu HTTP zamiast HTTPS.

Techniczny

Różnica w stosunku do HTTP

Adresy URL HTTPS zaczynają się od „https://” i domyślnie używają portu 443, podczas gdy adresy URL HTTP zaczynają się od „http://” i domyślnie używają portu 80.

Protokół HTTP nie jest szyfrowany i dlatego jest podatny na ataki typu man-in-the-middle i podsłuchiwanie , które mogą umożliwić atakującym uzyskanie dostępu do kont witryn internetowych i poufnych informacji oraz modyfikowanie stron internetowych w celu wstrzykiwania złośliwego oprogramowania lub reklam. Protokół HTTPS został zaprojektowany tak, aby wytrzymać takie ataki i jest uważany za bezpieczny przed nimi (z wyjątkiem implementacji HTTPS, które używają przestarzałych wersji protokołu SSL).

Warstwy sieciowe

HTTP działa w najwyższej warstwie modelu TCP/IPwarstwie aplikacji ; podobnie jak protokół bezpieczeństwa TLS (działający jako niższa podwarstwa tej samej warstwy), który szyfruje wiadomość HTTP przed transmisją i odszyfrowuje wiadomość po przybyciu. Ściśle mówiąc, HTTPS nie jest oddzielnym protokołem, ale odnosi się do używania zwykłego HTTP w zaszyfrowanym połączeniu SSL/TLS.

HTTPS szyfruje całą zawartość wiadomości, w tym nagłówki HTTP i dane żądania/odpowiedzi. Z wyjątkiem możliwego ataku kryptograficznego CCA opisanego w poniższej sekcji ograniczeń , osoba atakująca powinna co najwyżej być w stanie odkryć, że połączenie ma miejsce między dwiema stronami, wraz z ich nazwami domen i adresami IP.

Konfiguracja serwera

Aby przygotować serwer WWW do akceptowania połączeń HTTPS, administrator musi utworzyć certyfikat klucza publicznego dla serwera WWW. Ten certyfikat musi być podpisany przez zaufany urząd certyfikacji, aby przeglądarka internetowa zaakceptowała go bez ostrzeżenia. Urząd zaświadcza, że ​​posiadacz certyfikatu jest operatorem serwera WWW, który go przedstawia. Przeglądarki internetowe są zazwyczaj dystrybuowane z listą certyfikatów podpisujących głównych urzędów certyfikacji, dzięki czemu mogą one weryfikować podpisane przez nie certyfikaty.

Pozyskiwanie certyfikatów

Istnieje wiele komercyjnych urzędów certyfikacji oferujących płatne certyfikaty SSL/TLS różnych typów, w tym Extended Validation Certificates .

Let's Encrypt , uruchomiony w kwietniu 2016 r., zapewnia bezpłatną i zautomatyzowaną usługę, która dostarcza do witryn internetowych podstawowe certyfikaty SSL/TLS. Według Electronic Frontier Foundation , Let's Encrypt sprawi, że przejście z HTTP na HTTPS będzie „tak proste, jak wydanie jednego polecenia lub kliknięcie jednego przycisku”. Większość hostów internetowych i dostawców usług w chmurze korzysta teraz z Let's Encrypt, zapewniając swoim klientom bezpłatne certyfikaty.

Użyj jako kontroli dostępu

System może być również używany do uwierzytelniania klienta w celu ograniczenia dostępu do serwera WWW do autoryzowanych użytkowników. W tym celu administrator witryny zazwyczaj tworzy dla każdego użytkownika certyfikat, który użytkownik ładuje do swojej przeglądarki. Zwykle certyfikat zawiera nazwę i adres e-mail autoryzowanego użytkownika i jest automatycznie sprawdzany przez serwer przy każdym połączeniu w celu zweryfikowania tożsamości użytkownika, potencjalnie nawet bez konieczności podawania hasła.

W przypadku złamania tajnego (prywatnego) klucza

Ważną właściwością w tym kontekście jest doskonała tajemnica przekazywania (PFS). Posiadanie jednego z długoterminowych asymetrycznych kluczy tajnych używanych do ustanowienia sesji HTTPS nie powinno ułatwiać uzyskania klucza sesji krótkoterminowej w celu odszyfrowania konwersacji, nawet w późniejszym czasie. Wymiana kluczy Diffiego-Hellmana (DHE) i wymiana kluczy eliptycznych Diffiego-Hellmana (ECDHE) są w 2013 roku jedynymi znanymi schematami, które mają tę właściwość. W 2013 roku tylko 30% sesji Firefox, Opera i Chromium Browser korzystało z niego, a prawie 0% sesji Apple Safari i Microsoft Internet Explorer . Opublikowany w sierpniu 2018 r. TLS 1.3 zrezygnował z obsługi szyfrów bez utajnienia przekazywania. Według stanu na luty 2020 r. 96,6% ankietowanych serwerów internetowych obsługuje jakąś formę utajniania przekazywania, a 52,1% będzie korzystać z utajniania przekazywania w większości przeglądarek.

Certyfikat może zostać odwołany przed wygaśnięciem, na przykład z powodu naruszenia tajności klucza prywatnego. Nowsze wersje popularnych przeglądarek, takich jak Firefox , Opera i Internet Explorer w systemie Windows Vista, implementują protokół OCSP ( Online Certificate Status Protocol ), aby sprawdzić, czy tak nie jest. Przeglądarka wysyła numer seryjny certyfikatu z urzędu certyfikacji lub jego delegata poprzez OCSP (Online Certificate Status Protocol) i reaguje władzy, mówiąc przeglądarkę czy certyfikat jest nadal ważny lub utraci CA może również wydać CRL , aby powiedzieć ludziom, że te certyfikaty są cofane.

Ograniczenia

Szyfrowanie SSL (Secure Sockets Layer) i TLS (Transport Layer Security) można skonfigurować w dwóch trybach: prostym i wzajemnym . W trybie prostym uwierzytelnianie jest wykonywane tylko przez serwer. Wersja wzajemna wymaga od użytkownika zainstalowania osobistego certyfikatu klienta w przeglądarce internetowej w celu uwierzytelnienia użytkownika. W obu przypadkach poziom ochrony zależy od poprawności implementacji oprogramowania i stosowanych algorytmów kryptograficznych .

SSL/TLS nie uniemożliwia indeksowania witryny przez robota indeksującego , a w niektórych przypadkach identyfikator URI zaszyfrowanego zasobu można wywnioskować, znając tylko rozmiar przechwyconego żądania/odpowiedzi. Dzięki temu atakujący ma dostęp do zwykłego tekstu (publicznie dostępnej zawartości statycznej) i zaszyfrowanego tekstu (zaszyfrowanej wersji zawartości statycznej), umożliwiając atak kryptograficzny .

Ponieważ TLS działa na poziomie protokołu niższym niż HTTP i nie ma wiedzy o protokołach wyższego poziomu, serwery TLS mogą ściśle przedstawić tylko jeden certyfikat dla określonej kombinacji adresu i portu. W przeszłości oznaczało to, że nie było możliwe korzystanie z wirtualnego hostingu opartego na nazwach z HTTPS. Istnieje rozwiązanie o nazwie Server Name Indication (SNI), które wysyła nazwę hosta do serwera przed zaszyfrowaniem połączenia, chociaż wiele starych przeglądarek nie obsługuje tego rozszerzenia. Obsługa SNI jest dostępna od Firefox 2, Opera 8, Apple Safari 2.1, Google Chrome 6 i Internet Explorer 7 w systemie Windows Vista .

Z architektonicznego punktu widzenia:

  • Połączenie SSL/TLS jest zarządzane przez pierwszą maszynę frontową, która inicjuje połączenie TLS. Jeśli z jakichkolwiek powodów (routing, optymalizacja ruchu itp.) ta maszyna frontowa nie jest serwerem aplikacji i musi odszyfrować dane, należy znaleźć rozwiązania w celu propagowania informacji uwierzytelniających użytkownika lub certyfikatu do serwera aplikacji, który musi wiedzieć, kto będzie połączony.
  • W przypadku protokołu SSL/TLS z uwierzytelnianiem wzajemnym sesją SSL/TLS zarządza pierwszy serwer, który inicjuje połączenie. W sytuacjach, w których szyfrowanie musi być propagowane na połączonych serwerach, zarządzanie limitem czasu sesji staje się niezwykle trudne do wdrożenia.
  • Bezpieczeństwo jest maksymalne przy wzajemnym SSL/TLS, ale po stronie klienta nie ma możliwości prawidłowego zakończenia połączenia SSL/TLS i rozłączenia użytkownika poza oczekiwaniem na wygaśnięcie sesji serwera lub zamknięciem wszystkich powiązanych aplikacji klienckich.

Na konferencji Blackhat w 2009 r . zaprezentowano wyrafinowany rodzaj ataku typu man-in-the-middle, zwany strippingiem SSL . Ten rodzaj ataku obala zabezpieczenia zapewniane przez HTTPS, zmieniając odsyłacz w odsyłacz, wykorzystując fakt, że niewielu internautów faktycznie wpisuje „https” w interfejsie przeglądarki: trafiają na bezpieczną stronę po kliknięciu odsyłacza, a w ten sposób są oszukiwani, myśląc, że używają HTTPS, podczas gdy w rzeczywistości używają HTTP. Atakujący następnie komunikuje się wyraźnie z klientem. To skłoniło do opracowania środka zaradczego w HTTP o nazwie HTTP Strict Transport Security . https:http:

Wykazano, że protokół HTTPS jest podatny na szereg ataków związanych z analizą ruchu . Ataki analizy ruchu są rodzajem ataków z kanałem bocznym, które opierają się na zmianach w czasie i rozmiarze ruchu w celu wywnioskowania właściwości samego zaszyfrowanego ruchu. Analiza ruchu jest możliwa, ponieważ szyfrowanie SSL/TLS zmienia zawartość ruchu, ale ma minimalny wpływ na wielkość i czas ruchu. W maju 2010 r. w artykule badawczym opracowanym przez naukowców z Microsoft Research i Indiana University odkryto, że szczegółowe wrażliwe dane użytkownika można wywnioskować z kanałów bocznych, takich jak rozmiary pakietów. Naukowcy odkryli, że pomimo ochrony HTTPS w kilku głośnych, najnowocześniejszych aplikacjach internetowych w opiece zdrowotnej, podatkach, inwestycjach i wyszukiwarkach internetowych, podsłuchujący może wywnioskować choroby/leki/operacje użytkownika, jego/ jej dochód rodzinny i tajemnice inwestycyjne. Chociaż praca ta wykazała podatność protokołu HTTPS na analizę ruchu, podejście przedstawione przez autorów wymagało ręcznej analizy i koncentrowało się w szczególności na aplikacjach internetowych chronionych przez HTTPS.

Fakt, że większość nowoczesnych witryn internetowych, w tym Google, Yahoo! i Amazon, korzysta z protokołu HTTPS, powoduje problemy dla wielu użytkowników próbujących uzyskać dostęp do publicznych hot spotów Wi-Fi, ponieważ strona logowania do hot spotu Wi-Fi nie ładuje się, gdy użytkownik próbuje otwórz zasób HTTPS. Kilka stron internetowych, takich jak Neverssl.com i nonhttps.com gwarantuje, że zawsze będą dostępne przez HTTP.

Historia

Firma Netscape Communications stworzyła protokół HTTPS w 1994 roku dla swojej przeglądarki internetowej Netscape Navigator . Pierwotnie HTTPS był używany z protokołem SSL . Wraz z ewolucją protokołu SSL w Transport Layer Security (TLS), protokół HTTPS został formalnie określony przez RFC 2818 w maju 2000 r. Google ogłosił w lutym 2018 r., że jego przeglądarka Chrome będzie oznaczać witryny HTTP jako „niezabezpieczone” po lipcu 2018 r. Posunięcie to miało zachęcić witrynę właścicieli do wdrożenia protokołu HTTPS w celu zwiększenia bezpieczeństwa sieci WWW .

Zobacz też

Bibliografia

Zewnętrzne linki