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

Чи не використовувати SSL, чи є інший спосіб зробити моє з'єднання захищеним? Оскільки це стосується дорогого процесу використання SSL у веб-URL-адресі, я шукаю інший варіант замість цього.

чи є інший спосіб зробити моє з'єднання захищеним?

Google не просто скаржиться на "безпеку" (яка може включати в себе кілька різних тем), вона спеціально орієнтована на шифрування / HTTPS. За допомогою звичайного HTTP зв’язок між клієнтом та сервером не шифрується, що дозволяє кожному потенційно бачити та перехоплювати все, що подається. Зазвичай це запитується лише в тому випадку, якщо ви дозволяєте користувачам входити в систему (тобто, вводити ім’я користувача / пароль) або подавати платіжну інформацію через незашифроване з'єднання. Загальне подання "текстової" форми не обов'язково буде проблемою. Однак, як @Kevin зазначив у коментарях, Google / Chrome планують продовжити це в майбутньому :

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

Встановлення сервера SSL на вашому сайті (або використання проксі-сервера типу Cloudflare для обробки SLL) - єдиний спосіб шифрування трафіку на вашому сайті.

Однак це не обов'язково "дорогий процес" в наші дні. У Cloudflare є "безкоштовний" варіант, і Let's Encrypt - це безкоштовний орган сертифікації, який багато хостів підтримують за замовчуванням.

Я не рекомендую, але ви можете обійти це повідомлення, не використовуючи початкові текстові поля введення. Ви можете створити власні поля введення, використовуючи регулярні, divщо мають onkeypressподії. Або ви можете створити divелемент, для якого встановлено contenteditableатрибут true.

Таким чином, користувачі зможуть вводити інформацію на ваш сайт, не використовуючи inputелементи тегів.

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

Крім того, ви можете скористатися такою послугою, як cloudflare - їх безкоштовний план пропонує безкоштовний https.

Нарешті, деякі хости пропонують безкоштовні сервери https зараз, включаючи dreamhost . Тому перевірте, чи пропонує ваш поточний хост це опцію.

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

схоже, ніхто ще не згадував,

якщо ви володієте кожною машиною, яка підключається до вашого сайту

як корпоративне налаштування, ви можете створити власний авторизований сертифікат, встановити його відкритий сертифікат на всі машини (добре на всі браузери та магазини cert), які підключаються до вашого сайту. ця опція не передбачає монетизації сторонніх організацій; це той самий шифровий шифр, хоча ви не входите в публічну довіру, хоча (наприклад, ваші повноваження не визнані Chrome від Google, Mozilla Firefox тощо, як це робимо Let's Encrypts), але він буде розпізнаний машинами, налаштованими довіряти собі .

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

хоча для розширення nieve, якщо ви можете спробувати XCA

• Для Debian: https://packages.debian.org/stretch/xca
• офіційний сайт: http://xca.sourceforge.net/

XCS - це гідний спосіб видавати сертифікати для мініатюрних розгортань і включає довідкову документацію, яка розглядає всю програму.

У мене є пара ідей.

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

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

Ні.

Будь-який хак, який ви спробуєте (наприклад, як спроба зашифрувати javascript), навряд чи навіть буде близьким для захисту.

SSL не повинен "дорого", багато хостинг-провайдери пропонують його безкоштовно. І навіть такі речі, як cloudflare, пропонують безкоштовний SSL та зберігають поточний хостинг.

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