У зв’язку з масовим переходом сайтів на HTTPS перед розробниками і адміністраторами сайтів постала низка нових проблем. Однією з них є редирект з HTTP на HTTPS і необхідність правильно обробляти переадресацію на канонічний адреса сайту, щоб уникнути дублювання контенту.

HTTPS і редиректи

Розглянемо приклад. Припустимо, що у нас є сайт dnsimple.com. Його канонічний URL-адреса — https://dnsimple.com. Тим не менш, існує чотири різні способи, з допомогою яких можна підключитися до сайту, і треба забезпечити, щоб при будь-якому з них користувач перенаправлявся на https://dnsimple.com:

Вихідний спосіб Тип
http://dnsimple.com HTTP + no-www
https://dnsimple.com HTTPS + no-www
http://www.dnsimple.com HTTP + www
https://www.dnsimple.com HTTPS + www

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

Далі ми розглянемо, в якому порядку встановлюється з’єднання по протоколу HTTPS, як відбувається обробка HTTP-запитів та налаштування редиректів з підтримкою HTTPS.

Потік запиту HTTPS

На наведеному вище зображенні показана схема проходження запитів / відповідей HTTPS. Для простоти ми розбили всі дії на три фази:

  • На першому етапі клієнт і сервер домовляються про деталі шифрування, таких як протокол шифрування і набір шифрів. Також відбувається обмін інформацією, необхідною для перемикання на захищене з’єднання: відкриті ключі, відомості про сертифікат і т. д. Ця фаза називається «SSL / TLS рукостискання»;
  • На другому етапі клієнт готує HTTP-запит, шифрує його і відправляє на сервер для обробки. Сервер приймає зашифрований HTTP-запит, розшифровує його, обробляє і видає HTTP response (відповідь);
  • На третьому етапі, сервер шифрує відповідь і відправляє його клієнту для обробки. Клієнт отримує зашифрований HTTP response, дешифрує і обробляє його (наприклад, браузер починає завантажувати та відображати елементи).
  • Ця схема потоку перенаправлення з HTTP на HTTPS застосовна до будь-якого запиту, незалежно від вмісту відповіді HTTP.

    Вище я написав запит HTTP і відповідь HTTP для певних цілей (зверніть увагу, що я використовував HTTP, а не HTTPS). З точки зору вмісту і структури важливо розуміти, що HTTPS-запит — це запит HTTP, але передається через захищене з’єднання (TLS / SSL).

    HTTPS-узгодження і редиректи

    Одна з найпоширеніших помилок при налаштуванні HTTPS-редиректів — це припущення, що вам не потрібен сертифікат SSL при переадресації клієнта з одного домену на інший.

    Якщо подивитися на потік запитів, то видно, що обмін сертифікатами SSL і узгодження шифрування виконуються на першому етапі. Зверніть увагу, що на цьому етапі сервер нічого не знає, яка потрібна сторінка клієнта: клієнт і сервер вирішують, як взаємодіяти один з одним.

    Після завершення першого етапу, коли клієнт і сервер знайшли спільну мову (протокол шифрування), вони можуть почати взаємодіяти один з одним, використовуючи зашифроване з’єднання. В цей момент клієнт відправляє HTTP-запит на сервер, сервер відправляє HTTP-відповідь, що містить редирект.

    Не забувайте, що редирект — це HTTP-відповідь з кодом 301 (іноді 302 чи 307):

    HTTP/1.1 301 Moved Permanently
    Server: nginx
    Date: Mon, 01 Aug 2016 14:41:25 GMT
    Location: https://dnsimple.com/

    Перед тим, як зробити редирект з HTTPS на HTTP, пам’ятайте, що, якщо потрібно створити редирект для всього домену, то необхідний дійсний сертифікат SSL для перенаправляемого домену. Для узгодження шифрування вимагається сертифікат SSL, і відбувається воно до того, як запит був оброблений, а відповідь про редірект повернуто клієнту.

    Якби все відбувалося інакше, то редирект б оброблявся перед перевіркою сертифіката SSL. Тоді клієнт і сервер були б змушені спілкуватися за допомогою звичайного HTTP-з’єднання, яке не шифрується.

    Якщо потрібно перенаправити клієнта з будь-якої сторінки домену https://www.example.com на іншу, необхідний встановлений на сервері дійсний сертифікат SSL, який поширюється на весь домен www.example.com.

    Наприклад, щоб перенаправити клієнта з https://www.example.com на https://example.comнеобхідно мати сертифікат, який поширюється на обидва або два окремих сертифіката (для кожного хоста відповідно).

    Стратегії HTTPS-редиректів

    Ми розглянули, як обробляється редирект з HTTP на HTTPS через htaccess після SSL / TLS узгодження. А також з’ясували, що для перенаправлення клієнтів з сайту або сторінки на HTTPS потрібен дійсний сертифікат SSL, який охоплює обидва домена. Далі я розповім про загальні стратегії налаштування HTTPS-редиректів.

    Існує два типи налаштування редиректів з HTTPS:

  • Редірект на рівні сервера;
  • Редірект на рівні додатків.
  • Термін сервер позначає будь-сервер, який знаходиться перед веб-додатком і обробляє вхідний HTTP-запит. Наприклад, front-end сервер, сервер балансування навантаження або одиничного програми.

    Термін позначає додаток веб-додаток, яке може бути настільки ж простим, як PHP-скрипт, або більш складним, таким як серверне Unicorn-додаток інтерпретації Ruby on Rails.

    Виконання HTTPS-редиректів на рівні сервера

    Виконання HTTPS-редиректів на рівні сервера є більш кращим. У цьому випадку, сервер, на якому встановлений сертифікат SSL, приймає зашифрований HTTP-запит і повертає зашифрований HTTP-відповідь про редірект у відповідності з параметрами конфігурації без з’єднання з сервером додатка або виконання коду програми.

    Редиректи з використанням HTTPS

    Такий підхід є більш швидким, так що сервер може обробляти редирект без взаємодії з додатком. У той же час конфігурація серверів менш гнучка в порівнянні з тим, що можна зробити за допомогою повноцінного мови програмування.
    htaccess редирект HTTP на HTTPS на рівні сервера використовується для масового перенаправлення. Наприклад, редіректу з WWW на не-WWW версію домену з HTTPS (або навпаки).

    Наступний фрагмент коду є прикладом конфігурації Nginx, в якому задається редирект з http://example.com, http://www.example.com і https://www.example.com на https://example.com:

    server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
    }
    server {
    listen ssl 443;
    server_name example.com www.example.com;
    # ssl configuration
    ssl on;
    ssl_certificate /path/to/certificate.crt;
    ssl_certificate_key /path/to/private.key;
    if ($http_host = www.example.com) {
    return 301 https://example.com$request_uri;
    }
    }

    Реалізація редіректу на рівні сервера більш краща, але вона не завжди здійсненна, оскільки ви можете не мати доступу до конфігурації сервера. Це стосується віртуального хостингу або таких платформ, як Heroku, Microsoft або Google Platform.

    Виконання HTTPS-редіректу на рівні додатків

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

    Редиректи з використанням HTTPS

    Такий підхід трохи повільніше, тому що сервер повинен прийняти запит, обробити код програми (або взаємодіяти з сервером додатків) і повернути відповідь.

    Те, як виконується редирект на рівні додатків, залежить від використовуваної мови програмування і стека. Ось кілька прикладів.

    Пакет Goland і net/http

    Можна використовувати http.Redirect.

    Ruby on Rails

    Можна редірект на рівні маршрутизатора, використовувати проміжне програмне забезпечення Rack або метод redirect_to всередині контролера:

    constraints(host: /www.example.com/) do
    get ‘*’, to: redirect(‘https://example.com’)
    end

    PHP

    Використовуйте функцію header, щоб відправити HTTP-заголовок перенаправлення:

    У деяких випадках це єдино можливий підхід. Наприклад, якщо потрібно перенаправити клієнтів з WWW на не-WWW версію домену, з HTTPS на Heroku або Azure (або навпаки), то доведеться вказати обидва домену в одному додатку, встановити сертифікат і через умови обробляти редирект на рівні додатків.

    Альтернативні способи виконання HTTPS-редіректу

    Існує декілька альтернативних способів перенаправлення з HTTP на HTTPS.

    У деяких ситуаціях відсутній доступ до конфігурації сервера, а платформа, на якій розміщений сайт не дозволяє використовувати мову програмування. В якості типового прикладу можна навести Amazon S3 для розміщення статичних сайтів. В цьому випадку потрібно з’ясувати, чи надає платформа параметри HTTPS-редиректів, які можна налаштувати.

    Інший варіант полягає у використанні автономного, незалежного програми для редиректів. Наприклад, якщо потрібно перенаправити клієнтів https://alpha.com на https://beta.com. Тоді для домену alpha.com в якості DNS можна вказати інший сервіс або сервер, на якому розміщено beta.com. А також редірект на рівні сервера або встановити додаток, яке буде виступати в якості редиректора. При цьому також необхідний дійсний сертифікат alpha.com, який встановлено там, де необхідно здійснити редирект.

    Висновок

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

    Для створення HTTPS-редиректів потрібні додаткові дії, щоб перенаправляемый сервер був в змозі обробити вхідні HTTPS-запитів і надіслати правильну відповідь про редірект.

    Існує багато способів обробки URL-редиректів, і, сподіваюся, ця стаття допомогла вам знайти підходящий варіант, як зробити редирект з HTTPS на HTTP.

    Переклад статті «Redirects with HTTPS» був підготовлений дружною командою проекту Сайтостроение від А до Я.