Azərbaycanca AzərbaycancaБеларускі БеларускіDansk DanskDeutsch DeutschEspañola EspañolaFrançais FrançaisIndonesia IndonesiaItaliana Italiana日本語 日本語Қазақ ҚазақLietuvos LietuvosNederlands NederlandsPortuguês PortuguêsРусский Русскийසිංහල සිංහලแบบไทย แบบไทยTürkçe TürkçeУкраїнська Українська中國人 中國人United State United StateAfrikaans Afrikaans
Підтримка
www.wikidata.uk-ua.nina.az

HTTPS абр від англ HyperText Transfer Protocol Secure інші назви HTTP over TLS HTTP over SSL і HTTP Secure схема URI що

Https

Https

HTTPS (абр. від англ. HyperText Transfer Protocol Secure; інші назви: HTTP over TLS, HTTP over SSL, і HTTP Secure) — схема URI, що синтаксично ідентична http: схемі, яка зазвичай використовується для доступу до ресурсів Інтернет. Використання https: URL вказує, що протокол HTTP має використовуватися, але з іншим портом за замовчуванням (443) і додатковим шаром шифрування/автентифікації між HTTP і TCP. Ця схема була винайдена у компанії Netscape Communications Corporation для забезпечення автентифікації та шифрування комунікацій і широко використовується в Інтернеті у програмному забезпеченні, в якому важлива безпека комунікацій, наприклад, у платіжних системах та корпоративних логінах.

Принцип роботи

Оскільки HTTPS це фактично HTTP, який передається через SSL або TLS, то майже всі його основні елементи шифруються: URL-запити, включаючи шлях та назву ресурсу (сторінки), параметри запиту, заголовки та кукі, які часто містять ідентифікаційні дані про користувача. Не шифруються: назва або адреса хоста (вебсайту) та порт, оскільки вони використовуються транспортним протоколом TCP/IP для встановлення з'єднання.

Шифрування гарантує помірний захист від підслуховування та від нападу «людина посередині» (man-in-the-middle), за умови це коректних налаштувань та підпису сертифікату авторизованим центром сертифікації.

TCP портом за замовчуванням для HTTPS є 443, для HTTP — 80.

Щоб підготувати вебсервер для прийняття https транзакцій адміністратор повинен створити сертифікат з відкритим ключем для вебсервера. Ці сертифікати можуть бути створені на UNIX сервері такими програмами, як наприклад OpenSSL. Цей сертифікат повинен бути підписаний уповноваженим на видачу сертифікатів (certificate authority), який засвідчує, що отримувач сертифікату — саме той, про кого йдеться у сертифікаті.

Браузери розповсюджуються з сертифікатами центрів сертифікації верхнього рівня, що дозволяє браузерові перевіряти сертифікати, які були підписані цими центрами.

Довіряти HTTPS з'єднанню можна тоді і тільки тоді, коли всі наступні твердження коректні:

  • Користувач довіряє тому, що у браузері правильно забезпечено підтримку HTTPS із коректними попередньо встановленими сертифікатами уповноважених на видачу сертифікатів.
  • Користувач довіряє тому, що уповноважені на видачу сертифікатів засвідчують тільки відповідні (справжні) вебсайти.
  • Вебсайт надає дійсний сертифікат, тобто підписаний довіреним центром сертифікації.
  • Сертифікат конкретно розпізнає вебсайт (тобто коли браузер відвідує сторінку "https://example.com [ 29 жовтня 2020 у Wayback Machine.]", отриманий сертифікат правильний для "example.com", а не для інших доменних імен).
  • Користувач довіряє тому, що криптографічний рівень (шифрування за допомогою SSL/TLS) достатньо надійний, щоб захиститися від дешифрування.

Протокол HTTPS особливо важливий у незахищених мережах (таких як публічні Wi-Fi точки доступу), оскільки будь-хто в локальних мережах може аналізувати трафік та перехоплювати чи змінювати інформацію, не захищену HTTPS. Це означає, що гіпотетичний зловмисник може потенційно красти приватні дані користувача, отримувати доступ до облікового запису, вставляти шкідливий програмний код чи посилання на програмне забезпечення у сторінки, що надсилаються користувачеві у відповідь на його запити, тощо.

Організації можуть також мати власних уповноважених на видачу сертифікатів, особливо якщо вони відповідальні за конфігурацію браузерів, що мають доступ до їх власних сайтів (наприклад, сайти на внутрішній мережі компанії), оскільки вони можуть тривіально додати свій власний сертифікат до браузера.

Деякі сайти використовують самостійно підписані сертифікати. Їх використання забезпечує захист проти підслуховування, але є ризик нападу «людина-посередині». Для запобігання нападу необхідна перевірка сертифікату іншим методом (наприклад подзвонити власнику сертифіката задля перевірки контрольної суми сертифіката).

Система може також використовуватися для клієнтської автентифікації, щоб обмежити доступ до вебсервера тільки зареєстрованими користувачами. Для цього адміністратор сайту створює сертифікати для кожного користувача, які завантажуються в їхні браузер. Такі сертифікати зазвичай містять ім'я і електронну пошту зареєстрованого користувача, й автоматично перевіряються сервером при кожному повторному підключенні. Повторне введення паролю не потрібне.

Станом на початок 2017 р. HTTPS використовується на 10.13 % всіх українських доменів.

Обмеження

Рівень захисту залежить від коректності запровадження браузерного і серверного програмного забезпечення та підтримуваних криптографічних алгоритмів.

Серед користувачів кредитних карток в Інтернеті існує помилкова думка, що HTTPS повністю захищає номер їхньої картки від злодіїв. Фактично шифроване підключення до вебсервера тільки захищає номер кредитної картки при передаванні між комп'ютером користувача і сервером безпосередньо. Це не гарантує що сервер безпосередньо захищений — він навіть може бути зламаним.

Напади на вебсервери, які зберігають дані клієнта, здійснити простіше, ніж намагатись перехопити дані при передачі. Вважається, що комерційні сайти негайно пересилають операції, що поступають до шлюзу оплати і зберігають тільки операційний номер, але вони часто зберігають номери карток в базі даних. Звичайно сервер і база даних є ціллю для нападу.

Передача даних через захищені канали допомагає усунути деякі ризики: при використанні TLS, HSTS, фіксованих публічних ключів, веббраузер може бути впевнений, що він отримує дані з саме того сервера, до якого він звернувся. Проте, ці механізми автентифікують лише сервер, але не отримані дані. Зловмисник (або адміністратор вебсайту) з доступом до сервера може довільно змінювати дані. Механізм SRI дозволяє авторам вебсторінок гарантувати, що користувачі завантажуватимуть зі сторонніх вебсайтів тільки ті ресурси, які визначив автор сторінки.

Проте, застосування TLS не гарантує захисту від витоків інформації про з'єднання. Наприклад, зловмисник може дізнаватись сервери, до яких звертався браузер, щонайменше з чотирьох джерел: повідомлення з сертифікатом TLS, запит до DNS, IP-адреса сервера, та розширення TLS Server Name Indication (TLS SNI). Проти деяких з цих «сторонніх каналів» існують методи захисту. Зокрема, в протоколі TLS 1.3 серверний сертифікат передається у зашифрованому вигляді за замовчуванням, а для захисту від витоків через SNI було розроблене розширення протоколу «шифрованої індикації імені сервера» — Encrypted Server Name Indication (ESNI).

Слід також зазначити, що використання сайтом HTTPS не гарантує захисту від шахрайства. Так, наприклад, за даними 2017 року дедалі більше фішингових вебсайтів стали використовувати HTTPS з дійсними сертифікатами для введення користувачів в оману.

Примітки

  1. Network Working Group (May 2000). . The Internet Engineering Task Force. Архів оригіналу за 31 жовтня 2018. Процитовано 30 січня 2017.
  2. . Google Webmaster Central Blog. Google Inc. 6 серпня 2014. Архів оригіналу за 8 березня 2016. Процитовано 30 січня 2017. You can make your site secure with HTTPS (Hypertext Transfer Protocol Secure) [...]
  3. . Adobe Systems Incorporated. Архів оригіналу за 8 березня 2015. Процитовано 30 січня 2017.
  4. . Google Support. Google, Inc. Архів оригіналу за 15 грудня 2017. Процитовано 30 січня 2017.
  5. . Comodo CA Limited. Архів оригіналу за 12 лютого 2015. Процитовано 30 січня 2017. Hyper Text Transfer Protocol Secure (HTTPS) is the secure version of HTTP [...]
  6. . www.ukralio.com (укр.). Архів оригіналу за 17 лютого 2017. Процитовано 16 лютого 2017.
  7. . W3C Recommendation. 23 June 2016. Архів оригіналу за 15 липня 2017. Процитовано 6 грудня 2017.
  8. Eric Rescorla (2018-1018). . Mozilla Security Blog. Архів оригіналу за 24 березня 2020. Процитовано 22 жовтня 2018.
  9. Dennis Schirrmacher (07.12.2017). . Heise online. Архів оригіналу за 8 грудня 2017. Процитовано 8 грудня 2017.

Див. також

Посилання

  • RFC 2818: HTTP Over TLS [ 31 жовтня 2018 у Wayback Machine.]
  • RFC 5246: The Transport Layer Security Protocol 1.2 [ 24 грудня 2017 у Wayback Machine.]
image Це незавершена стаття з інформаційної безпеки.
Ви можете проєкту, виправивши або дописавши її.
image Це незавершена стаття про Інтернет.
Ви можете проєкту, виправивши або дописавши її.

Вікіпедія, Українська, Україна, книга, книги, бібліотека, стаття, читати, завантажити, безкоштовно, безкоштовно завантажити, mp3, відео, mp4, 3gp, jpg, jpeg, gif, png, малюнок, музика, пісня, фільм, книга, гра, ігри, мобільний, телефон, android, ios, apple, мобільний телефон, samsung, iphone, xiomi, xiaomi, redmi, honor, oppo, nokia, sonya, mi, ПК, web, Інтернет

HTTPS abr vid angl HyperText Transfer Protocol Secure inshi nazvi HTTP over TLS HTTP over SSL i HTTP Secure shema URI sho sintaksichno identichna http shemi yaka zazvichaj vikoristovuyetsya dlya dostupu do resursiv Internet Vikoristannya https URL vkazuye sho protokol HTTP maye vikoristovuvatisya ale z inshim portom za zamovchuvannyam 443 i dodatkovim sharom shifruvannya avtentifikaciyi mizh HTTP i TCP Cya shema bula vinajdena u kompaniyi Netscape Communications Corporation dlya zabezpechennya avtentifikaciyi ta shifruvannya komunikacij i shiroko vikoristovuyetsya v Interneti u programnomu zabezpechenni v yakomu vazhliva bezpeka komunikacij napriklad u platizhnih sistemah ta korporativnih loginah Princip robotiOskilki HTTPS ce faktichno HTTP yakij peredayetsya cherez SSL abo TLS to majzhe vsi jogo osnovni elementi shifruyutsya URL zapiti vklyuchayuchi shlyah ta nazvu resursu storinki parametri zapitu zagolovki ta kuki yaki chasto mistyat identifikacijni dani pro koristuvacha Ne shifruyutsya nazva abo adresa hosta vebsajtu ta port oskilki voni vikoristovuyutsya transportnim protokolom TCP IP dlya vstanovlennya z yednannya Shifruvannya garantuye pomirnij zahist vid pidsluhovuvannya ta vid napadu lyudina poseredini man in the middle za umovi ce korektnih nalashtuvan ta pidpisu sertifikatu avtorizovanim centrom sertifikaciyi TCP portom za zamovchuvannyam dlya HTTPS ye 443 dlya HTTP 80 Shob pidgotuvati vebserver dlya prijnyattya https tranzakcij administrator povinen stvoriti sertifikat z vidkritim klyuchem dlya vebservera Ci sertifikati mozhut buti stvoreni na UNIX serveri takimi programami yak napriklad OpenSSL Cej sertifikat povinen buti pidpisanij upovnovazhenim na vidachu sertifikativ certificate authority yakij zasvidchuye sho otrimuvach sertifikatu same toj pro kogo jdetsya u sertifikati Brauzeri rozpovsyudzhuyutsya z sertifikatami centriv sertifikaciyi verhnogo rivnya sho dozvolyaye brauzerovi pereviryati sertifikati yaki buli pidpisani cimi centrami Doviryati HTTPS z yednannyu mozhna todi i tilki todi koli vsi nastupni tverdzhennya korektni Koristuvach doviryaye tomu sho u brauzeri pravilno zabezpecheno pidtrimku HTTPS iz korektnimi poperedno vstanovlenimi sertifikatami upovnovazhenih na vidachu sertifikativ Koristuvach doviryaye tomu sho upovnovazheni na vidachu sertifikativ zasvidchuyut tilki vidpovidni spravzhni vebsajti Vebsajt nadaye dijsnij sertifikat tobto pidpisanij dovirenim centrom sertifikaciyi Sertifikat konkretno rozpiznaye vebsajt tobto koli brauzer vidviduye storinku https example com 29 zhovtnya 2020 u Wayback Machine otrimanij sertifikat pravilnij dlya example com a ne dlya inshih domennih imen Koristuvach doviryaye tomu sho kriptografichnij riven shifruvannya za dopomogoyu SSL TLS dostatno nadijnij shob zahistitisya vid deshifruvannya Protokol HTTPS osoblivo vazhlivij u nezahishenih merezhah takih yak publichni Wi Fi tochki dostupu oskilki bud hto v lokalnih merezhah mozhe analizuvati trafik ta perehoplyuvati chi zminyuvati informaciyu ne zahishenu HTTPS Ce oznachaye sho gipotetichnij zlovmisnik mozhe potencijno krasti privatni dani koristuvacha otrimuvati dostup do oblikovogo zapisu vstavlyati shkidlivij programnij kod chi posilannya na programne zabezpechennya u storinki sho nadsilayutsya koristuvachevi u vidpovid na jogo zapiti tosho Organizaciyi mozhut takozh mati vlasnih upovnovazhenih na vidachu sertifikativ osoblivo yaksho voni vidpovidalni za konfiguraciyu brauzeriv sho mayut dostup do yih vlasnih sajtiv napriklad sajti na vnutrishnij merezhi kompaniyi oskilki voni mozhut trivialno dodati svij vlasnij sertifikat do brauzera Deyaki sajti vikoristovuyut samostijno pidpisani sertifikati Yih vikoristannya zabezpechuye zahist proti pidsluhovuvannya ale ye rizik napadu lyudina poseredini Dlya zapobigannya napadu neobhidna perevirka sertifikatu inshim metodom napriklad podzvoniti vlasniku sertifikata zadlya perevirki kontrolnoyi sumi sertifikata Sistema mozhe takozh vikoristovuvatisya dlya kliyentskoyi avtentifikaciyi shob obmezhiti dostup do vebservera tilki zareyestrovanimi koristuvachami Dlya cogo administrator sajtu stvoryuye sertifikati dlya kozhnogo koristuvacha yaki zavantazhuyutsya v yihni brauzer Taki sertifikati zazvichaj mistyat im ya i elektronnu poshtu zareyestrovanogo koristuvacha j avtomatichno pereviryayutsya serverom pri kozhnomu povtornomu pidklyuchenni Povtorne vvedennya parolyu ne potribne Stanom na pochatok 2017 r HTTPS vikoristovuyetsya na 10 13 vsih ukrayinskih domeniv ObmezhennyaRiven zahistu zalezhit vid korektnosti zaprovadzhennya brauzernogo i servernogo programnogo zabezpechennya ta pidtrimuvanih kriptografichnih algoritmiv Sered koristuvachiv kreditnih kartok v Interneti isnuye pomilkova dumka sho HTTPS povnistyu zahishaye nomer yihnoyi kartki vid zlodiyiv Faktichno shifrovane pidklyuchennya do vebservera tilki zahishaye nomer kreditnoyi kartki pri peredavanni mizh komp yuterom koristuvacha i serverom bezposeredno Ce ne garantuye sho server bezposeredno zahishenij vin navit mozhe buti zlamanim Napadi na vebserveri yaki zberigayut dani kliyenta zdijsniti prostishe nizh namagatis perehopiti dani pri peredachi Vvazhayetsya sho komercijni sajti negajno peresilayut operaciyi sho postupayut do shlyuzu oplati i zberigayut tilki operacijnij nomer ale voni chasto zberigayut nomeri kartok v bazi danih Zvichajno server i baza danih ye cillyu dlya napadu Peredacha danih cherez zahisheni kanali dopomagaye usunuti deyaki riziki pri vikoristanni TLS HSTS fiksovanih publichnih klyuchiv vebbrauzer mozhe buti vpevnenij sho vin otrimuye dani z same togo servera do yakogo vin zvernuvsya Prote ci mehanizmi avtentifikuyut lishe server ale ne otrimani dani Zlovmisnik abo administrator vebsajtu z dostupom do servera mozhe dovilno zminyuvati dani Mehanizm SRI dozvolyaye avtoram vebstorinok garantuvati sho koristuvachi zavantazhuvatimut zi storonnih vebsajtiv tilki ti resursi yaki viznachiv avtor storinki Prote zastosuvannya TLS ne garantuye zahistu vid vitokiv informaciyi pro z yednannya Napriklad zlovmisnik mozhe diznavatis serveri do yakih zvertavsya brauzer shonajmenshe z chotiroh dzherel povidomlennya z sertifikatom TLS zapit do DNS IP adresa servera ta rozshirennya TLS Server Name Indication TLS SNI Proti deyakih z cih storonnih kanaliv isnuyut metodi zahistu Zokrema v protokoli TLS 1 3 servernij sertifikat peredayetsya u zashifrovanomu viglyadi za zamovchuvannyam a dlya zahistu vid vitokiv cherez SNI bulo rozroblene rozshirennya protokolu shifrovanoyi indikaciyi imeni servera Encrypted Server Name Indication ESNI Slid takozh zaznachiti sho vikoristannya sajtom HTTPS ne garantuye zahistu vid shahrajstva Tak napriklad za danimi 2017 roku dedali bilshe fishingovih vebsajtiv stali vikoristovuvati HTTPS z dijsnimi sertifikatami dlya vvedennya koristuvachiv v omanu PrimitkiNetwork Working Group May 2000 The Internet Engineering Task Force Arhiv originalu za 31 zhovtnya 2018 Procitovano 30 sichnya 2017 Google Webmaster Central Blog Google Inc 6 serpnya 2014 Arhiv originalu za 8 bereznya 2016 Procitovano 30 sichnya 2017 You can make your site secure with HTTPS Hypertext Transfer Protocol Secure Adobe Systems Incorporated Arhiv originalu za 8 bereznya 2015 Procitovano 30 sichnya 2017 Google Support Google Inc Arhiv originalu za 15 grudnya 2017 Procitovano 30 sichnya 2017 Comodo CA Limited Arhiv originalu za 12 lyutogo 2015 Procitovano 30 sichnya 2017 Hyper Text Transfer Protocol Secure HTTPS is the secure version of HTTP www ukralio com ukr Arhiv originalu za 17 lyutogo 2017 Procitovano 16 lyutogo 2017 W3C Recommendation 23 June 2016 Arhiv originalu za 15 lipnya 2017 Procitovano 6 grudnya 2017 Eric Rescorla 2018 1018 Mozilla Security Blog Arhiv originalu za 24 bereznya 2020 Procitovano 22 zhovtnya 2018 Dennis Schirrmacher 07 12 2017 Heise online Arhiv originalu za 8 grudnya 2017 Procitovano 8 grudnya 2017 Div takozhTransport Layer Security TLS Secure Sockets Layer SSL Infrastruktura vidkritih klyuchivPosilannyaRFC 2818 HTTP Over TLS 31 zhovtnya 2018 u Wayback Machine RFC 5246 The Transport Layer Security Protocol 1 2 24 grudnya 2017 u Wayback Machine Ce nezavershena stattya z informacijnoyi bezpeki Vi mozhete dopomogti proyektu vipravivshi abo dopisavshi yiyi Ce nezavershena stattya pro Internet Vi mozhete dopomogti proyektu vipravivshi abo dopisavshi yiyi

Дата публікації:
Топ