Чи погано перенаправляти http на https?

Щойно я встановив на своєму сервері сертифікат SSL.

Потім він встановив переспрямування для всього трафіку в моєму домені на Порт 80, щоб перенаправити його на Порт 443.

Іншими словами, весь мій http://example.comтрафік зараз перенаправлений на відповідну https://example.comверсію сторінки.

Переспрямування виконується у моєму файлі віртуальних хостів Apache з чимось подібним ...

RewriteEngine on
ReWriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L] 

Моє запитання: чи є недоліки використання SSL?

Оскільки це не перенаправлення 301, чи я втрачу сік посилання / рейтинг у пошукових системах, перейшовши на https?

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

ОНОВЛЕННЕ ПИТАННЯ

Як не дивно, Bing створює цей знімок екрана з мого сайту тепер, коли він використовує HTTPS скрізь ...

[R]Прапор сам по собі є 302перенаправленням ( Moved Temporarily). Якщо ви дійсно хочете, щоб люди, які використовують версію HTTPS вашого веб-сайту (підказка: ви це робите), вам слід використовувати [R=301]для постійного переадресації:

RewriteEngine on
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R=301,L] 

301Зберігає всі ваші Google-фу і кровні ваги PageRank недоторканим . Переконайтесь, що mod_rewriteввімкнено:

a2enmod rewrite

Щоб відповісти на ваше точне запитання:

Чи погано перенаправляти http на https?

Ніяк ні. Це дуже добре.

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

1. Перевірте весь сайт на наявність внутрішніх посилань і переконайтеся, що вони використовують HTTPS, якщо ви вказали своє власне доменне ім’я у посиланнях, щоб не викликати ваші власні переадресації.
2. Оновіть свою програму <meta property="og:url"за допомогою https-версії вашого домену.
3. Якщо ви <base href=знову використовуєте оновлення для використання HTTPS.
4. Якщо можливо, встановіть протокол SPDY
5. Обов'язково використовуйте спрайти зображень CSS, де це можливо, щоб зменшити кількість запитів.
6. Оновіть ваші мапи сайту, щоб вказати статус https, тому павуки з часом дізнаються про цю зміну.
7. Змініть налаштування пошукової системи, як-от Інструменти Google для веб-майстрів, щоб віддати перевагу HTTPS
8. Де можливо, завантажте будь-які статичні носії на HTTPS-сервери CDN.

Якщо зазначене вище буде вирішено, я сумніваюся, у вас буде багато питань.

Я встановив https, то вам слід користуватися ним скрізь на сайті. Ви уникнете ризику виникнення змішаних проблем із вмістом, і якщо у вас є необхідні інструменти, чому б не зробити весь сайт захищеним?

Щодо перенаправлення з http на https, відповідь не така проста.

Перенаправлення значно полегшить ваших користувачів, вони просто вводять на whateversite.com і перенаправляються на https.

Але. Що робити, якщо користувач іноді перебуває в незахищеній мережі (або близький до Трої Хант та його Ананаса )? Тоді користувач запитає http://whateversite.com за старою звичкою. Це http. Це може бути поставлено під загрозу. Переспрямування може вказувати на https://whateversite.com.some.infrastructure.long.strange.url.hacker.org . Звичайному користувачеві це буде виглядати цілком законно. Але трафік можна перехопити.

Тож у нас є дві конкуруючі вимоги: бути зручним для користувачів та бути захищеним. На щастя, існує засіб, який називається заголовком HSTS . За допомогою нього можна включити переадресацію. Браузер перейде на захищений сайт, але завдяки заголовку HSTS також запам'ятайте його. Коли користувач набере в whateversite.com, що сидить у тій незахищеній мережі, браузер одразу перейде на https, не перестрибуючи переспрямування через http. Якщо ви не маєте справу з дуже чутливими даними, я думаю, що це справедливий компроміс між безпекою та зручністю використання більшості сайтів. (Коли я нещодавно створив програму, яка обробляє медичну документацію, я перейшов усі https без перенаправлення). На жаль, Internet Explorer не підтримує HSTS ( джерело)), тож якщо ваша цільова аудиторія в основному використовує IE і дані чутливі, ви можете вимкнути переадресацію.

Тож якщо ви не орієнтуєтесь на користувачів IE, продовжуйте використовувати переспрямування, але ввімкніть також заголовок HSTS.

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

<VirtualHost 10.2.3.40:80>
  ServerAdmin me@example.com
  ServerName secure.example.com
  RedirectMatch 301 (.*) https://secure.example.com$1
</VirtualHost>

# Insert 10.2.3.40:443 virtual host here :)

Код 301стану вказує на постійне переспрямування, вказуючи спроможним клієнтам використовувати захищену URL-адресу для майбутніх з'єднань (наприклад, оновити закладку).

Якщо ви будете обслуговувати сайт лише через TLS / SSL, я рекомендую додаткову директиву, щоб увімкнути жорстку безпеку транспорту HTTP (HSTS) у вашому захищеному віртуальному хості:

<IfModule mod_headers.c>
  Header set Strict-Transport-Security "max-age=1234; includeSubdomains"
</IfModule>

Цей заголовок вказує здібним клієнтам (я вважаю, що сьогодні більшість із них), що вони повинні використовувати HTTPS лише з наданим доменом ( secure.example.comу цьому випадку) протягом наступних 1234секунд. Розділ ; includeSubdomainsє необов'язковим і вказує, що директива застосовується не лише до поточного домену, а до будь-якого під ним (наприклад alpha.secure.example.com). Зверніть увагу , що заголовок HSTS буде тільки прийнятий браузерами , коли подається через / TLS з'єднання SSL!

Щоб перевірити конфігурацію вашого сервера на сучасній кращій практиці, хорошим безкоштовним ресурсом є служба тестування SSL Server Qualys ; Я б мав на меті отримати принаймні A- (ви не можете отримати більше, ніж з Apache 2.2 через відсутність підтримки криптографії еліптичної кривої).

Оце Так ! перенаправлення HTTP на HTTPS - дуже гарна річ, і я не можу побачити недоліків для цього.

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

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

Чи погано перенаправляти http на https?

Ні, зовсім ні. Власне, це добре робити!

Про переадресації:

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

<VirtualHost *:80>
  ServerName domainname.com

  <IfModule mod_alias.c>
    Redirect permanent / https://domainname.com/
  </IfModule>
</VirtualHost>

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

Але не забудьте перевірити налаштування SSL, як налаштування SSLCiphers. Вимкніть такі речі, як криптовалюта RC4, протокол SSLv2 та SSLv3. Крім того, ви повинні дізнатися, чи підтримують криптовалютні системи вашої системи TLS1.2 (що саме ви хочете мати;))

Увімкніть SSL, це гарна річ.

Особисто я використовую SSL для захисту з'єднань в Інтернеті, однак я вважаю, що всі інші відповіді тут пропущені - це те, що не кожен пристрій і програмне забезпечення, здатне до HTTP-з'єднання, зможуть використовувати SSL, таким чином, я б розглядав можливість надання користувачам певного способу уникнути цього, якщо він не підтримується. Можливо також, що людям у деяких країнах, де технологія шифрування є незаконною, тоді заборонятимуть доступ до вашого сайту. Я б розглядав можливість додавання незашифрованої цільової сторінки із посиланням, щоб змусити незахищену версію сайту, але, якщо користувач спеціально не вибере такі дії, як ви сказали, та просто переслати їх до версії HTTPS.

Ось деякі з широких питань мазка:

• MITM / SSLSTRIP : Це величезна застереження. Якщо ви збираєтеся обслуговувати свій сайт через HTTPS, відключіть HTTP на сайті . В іншому випадку ви залишаєте своїх користувачів відкритими для різних атак посереднього типу, включаючи SSLSTRIP, які перехоплюватимуть запити та спокійно обслуговуватимуть їх через HTTP, вставляючи в потік власний скрипт зловмисного програмного забезпечення. Якщо користувач цього не помітить, він вважатиме, що їх сеанс захищений, коли його насправді немає.

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

• Якщо ваш сайт вимагає безпечного входу, то весь сеанс користувача повинен бути захищений. Не здійснюйте автентифікацію через HTTPS, а потім перенаправляйте користувача назад до HTTP. Якщо знову ж таки, ви залишаєте своїх користувачів уразливими до атак MITM. Стандартний підхід до аутентифікації в ці дні полягає в тому, щоб один раз пройти автентифікацію, потім передати маркер аутентифікації вперед і назад (у файлі cookie). Але якщо ви пройшли автентифікацію через HTTPS, то переспрямуєте на HTTP, тоді людина, що перебуває в середині, може перехопити цей файл cookie та використовувати сайт так, ніби вони є вашим аутентифікованим користувачем, минаючи вашу безпеку.

• Проблеми щодо "продуктивності" HTTPS для всіх практичних цілей обмежені рукостисканням, що бере участь у створенні нового з'єднання. Зробіть все можливе, щоб мінімізувати потребу в декількох HTTPS-з'єднаннях з URL-адреси, і ви будете милі вперед. І це відверто вірно, навіть якщо ви розміщуєте свій вміст через HTTP. Якщо ви прочитаєте на SPDY, ви зрозумієте, що все, що вона робить, орієнтоване на спробу подати весь вміст з однієї URL-адреси за допомогою одного з'єднання. Так, використання HTTPS впливає на кешування. Але скільки веб-сайтів є лише статичним, кешованим вмістом у ці дні? Ви, ймовірно, отримаєте більше ударів за свій долар, використовуючи кешування на веб-сервері, щоб мінімізувати зайві запити до бази даних, отримуючи незмінні дані знову і знову, і запобігаючи виконанню дорогих кодових шляхів частіше, ніж потрібно.

Це технічно не є відповіддю на ваш початковий запитання, але якщо ви використовуєте розширення Google Chrome HTTPSEverywhere (я впевнений, що подібні розширення є в інших браузерах), розширення автоматично перенаправляє сайти з HTTP на той самий сайт із HTTPS. Я використовую його деякий час, і у мене не було жодних проблем (крім, можливо, уповільнення, але я цього не перевіряв). HTTPSEвсюди можна змінити певними правилами на стороні сервера, але оскільки я в цій області не зробив багато, я не впевнений у точних деталях.

Повертаючись до свого актуального питання, якщо ви використовуєте щось на зразок HTTPSEverywhere, є ще менше стимулів використовувати лише HTTP, хоча я думаю, що важко встановити правильні правила, коли вони вам потрібні.

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

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

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

Дуже добре перенаправляти на https, але я читаю, це також залежить від того, як ви організуєте переадресацію.

Створення виділеного віртуального сервера для перенаправлення вхідних запитів http до вашого https-з'єднання, як це пропонується у відповіді на security.stackexchange.com, звучить дуже розумно і закриє деякі додаткові загрози безпеці. Конфігурація в Apache виглядатиме приблизно так:

# Virtual host for rerouting
<VirtualHost *:80>
    ServerName www.example.com
    Redirect permanent / https://www.example.com/
</VirtualHost>

# Virtual host for secure hosting on https
<VirtualHost *:443>
    ServerName www.example.com
    SSLEngine on
    Header set Strict-Transport-Security "max-age=8640000;includeSubdomains"

    ...site settings...

</VirtualHost>