Якщо у вас безпечний веб-сервер, користувачі, що хвилюються за безпеку своїх даних, можуть бути впевнені, що запити зашифровані, тому їх дані в безпеці. Кращим шляхом для цього є використання Apache 2, лідируючого веб-сервера під Linux і Secure Sockets Layer, протокол безпечної передачі даних. Transport Layer Security (TLS) є розвитком SSL, але вони працюють практично однаково. Я буду посилатися тільки на SSL.
SSL - протокол для безпечної передачі зашифрованих даних між веб-браузером і веб-сервером. У більшості випадків, аутентифікацію проходить сервер, що дозволяє клієнту бути впевненим в тому, що сервер є необхідним йому, а не навпаки. Як би там не було, коли з'єднання встановлюється, обидві сторони знаходяться в безпеці, так як тільки клієнт і сервер мають доступ до ключа. Це працює в перебігу багатьох запитів, сервер не цікавить, ким є клієнт так довго, скільки він залишається тим же клієнтом протягом запиту. Якщо вас хвилює аутентифікація клієнта, є можливість використовувати клієнтські SSL сертифікати (або htaccess, Kerberos або інші, близькі до них методи), але це не буде розглядатися в цій статті.
Будучи на стороні клієнта, вас хвилює, тому людині (серверу) ви посилаєте будь-які особисті дані, які хочете зашифрувати. Тому сервер, а не клієнт, аутентифицирующей. Вас також непокоїть участь третьої сторони в доступі до ваших даних у тому вигляді, якому ви їх посилаєте. SSL надає обидва ці види безпеки.
Протокол SSL працює наступним чином:
1. Клієнт підключається до веб-сервера і дає список доступних кодів.
2. Сервер бере найбільш стійкий код, який підтримує і він, і клієнт, і посилає сертифікат зі своїм ім'ям і ключ кодування, підписаний довіреною Засвідчуючим Центром (Certificate Authority, далі - CA), таким як Verisign.
3. Клієнт перевіряє сертифікат за допомогою CA. На практиці, зберігають набір CA локально, тому це може бути зроблено без контакту в реальному часі з CA, і тому більш швидко.
4. Клієнт посилає назад випадкове число, зашифроване за допомогою публічного ключа сервера. Тільки клієнт знає це число, і тільки сервер може його розшифрувати (використовуючи особистий ключ); ось де реалізується безпеку від участі третьої сторони.
5. Сервер і клієнт використовують випадкове число для генерування вмісту ключа, який використовується на протязі передачі даних.
Ми хочемо зробити це на стороні клієнта настільки прозорим, наскільки це можливо, щоб зробити передачу даних настільки легкою, наскільки можливо.
Перший крок - створення сертифіката. Ви можете створити сертифікат з паролем або без нього. Головною незручністю використання пароля є той факт, що він повинен бути введений кожен раз при старті сервера. Тому він не може запускатися без нагляду або автоматично при завантаженні, наприклад, після виключення електрики. Залежно від ваших установок, це може бути значущим фактом для вас, чи ні.
Теоретично, перевагою використання пароля являтся підвищення захисту. Хоча, на практиці паролі не дає такої великої захисту. Якщо хтось зможе прочитати або скопіювати приватний ключ, значить, у нього вже є доступ до системи і можливість отримати пароль, наприклад, використовуючи таку програму, як кейлоггер. Пароль захистить від скрипт-кідді, але не від серйозного зломщика. Можливо, для більшості людей немає сенсу його використовувати.
Для тестових цілей, або для невеликої локальної мережі, ви можете створити сертифікат, підписаний вами. Ви можете зробити це, виконавши команду:
Проблема з використанням сертифіката, підписаного самостійно для сервера, що працює в реальному часі, полягає в тому, що будь-який браузер, що працює з сайтом, не визнаватиме сертифікат правильним. Це означає, що користувача будуть запитувати про підтвердження сертифіката. Очевидно, що в більшості випадків це не є оптимальним рішенням. Хоча, це нормально для цілей тесту, а для невеликих локальних мереж було б найгіршим варіантом платити за сертифікат від CA.
Не дивлячись на це, безумовно, краще використовувати сертифікат, підписаний довіреною Засвідчуючим Центром, таким як Verisign (який має максимальне охоплення ринку), або меншою організацією. Більшість браузерів вже мають набір попередньо сертифікатів, засвідчених CA, які верифікують сертифікат вашого веб-сервера при підключенні клієнта. Це зменшує кількість труднощів для кінцевого користувача і засвідчує законність вашого сайту.
Щоб отримати сертифікат, підписаний CA, перш за все ви повинні створити криптографічний пару і запит сертифіката:
Ключ сервера (файл server.key, який, знову ж таки, повинен бути доступний для читання тільки для root) залишається на вашому веб-сервері; запит (файл www.example.com.csr) відправляється в CA. Ви можете назвати файл запиту так, як вам заманеться, але назвавши його по своєму доменному імені, ви спростите завдання для CA.
Наступною стадією буде послати цей файл www.example.com.csr в CA, з вашої оплатою. Вони повинні повернути його досить швидко, якщо ви надали всю необхідну інформацію у вашому запиті. Обраний вами CA пояснить їх дії на своєму сайті. Вам може знадобитися поміняти формат файлу на PEM, але, в разі Verisign, цього робити не доведеться.
Коли ви отримаєте файл назад в PEM форматі, перейменуйте його в server.crt (це не є суворою необхідністю, але відповідає умовам Apache) і перевірте його:
Потім перевірте, що результат виконання цих двох команд однаковий, тобто що сертифікат відповідає приватному ключу:
Тепер встановіть ваш ключ (згенерований вище як server.key) і сертифікат (server.crt) в / etc / apache2 / ssl або якості вибраної каталог налаштувань, якщо він інший. Як зазначено вище, дуже важливо переконатися, що server.key доступний для читання тільки для root, в той час як сертифікат сервера може бути доступний для читання для world, але належати і бути доступним для запису тільки для root.
Компіляція Apache з SSL.
Отже, ваш сертифікат згенерований. Тепер вам треба налаштувати свій сервер для його використання.
Для переважної більшості людей, найкращим способом встановити і управляти Apache2 - модулі, отримані через менеджеру пакунків дистрибутива. Apache2 з Debian йде разом з модулем SSL, але він не включений за замовчуванням. Для його включення ви повинні виконати команду: a2enmod ssl і перезапустити веб-сервер.
Щоб зробити це, додайте рядок
в ваш /etc/apache2/apache2.conf (цей файл може також називатися httpd.conf). Ви повинні виправити її, позначивши відповідне розташування файлу mod_ssl.conf. А після перезапуску веб-сервер.
Якщо ви хочете скомпілювати Apache2 з вихідних кодів, в залежності від того, які установки ви до цього використовували, ви можете вже мати або не мати підтримку SSL. Перевірте це командою apache2 -l. Якщо перекомпіляція знадобиться, запустіть ./configure з усіма опціями, які ви використовували до цього, додавши до них --enable-ssl і --enable-setenvif (остання потрібна для сумісності з капризами Internet Explorer). Потім встановіть його як зазвичай, за допомогою make; make install і перевірте правильність прав доступу.
Налаштування Apache з SSL.
Наступним кроком буде настройка Apache2. Наступні інструкції приведуть до запуску сервера як безпечного (порт 443) і як звичайного веб-сервера (порт 80). Перш за все, вам треба налаштувати сервер на прийняття запитів на обидва порту. Або змініть /etc/apache2/ports.conf (в Debian, це входить в apache2.conf), або відредагуйте /etc/apache2/apache2.conf, включивши рядки:
Потім відредагуйте / etc / apache2 / sites-enabled / yoursite для використання налаштувань SSL. Поділ налаштувань звичайного і безпечного сервера за допомогою VirtualHost - найпростіший спосіб з міркувань умов експлуатації. Будь-які настройки поза секцій VirtualHost (наприклад, установка ServerAdmin) будуть застосовуватися для обох (і будь-яких інших) VirtualHost. Додайте наступний текст в файл конфігурації:
Кілька зауважень про цю конфігурацію:
- SSLEngine потрібно включити, позначаючи, що сервер використовує SSL.
- DocumentRoot встановлює кореневої каталог віртуального хоста. Це означає, що ви можете відокремлювати безпечне вміст від звичайного.
- SSLRequireSSL запитує використання SSL (на цьому віртуальному сервері), тобто, користувач не може підключитися до цього віртуального хосту за допомогою звичайного HTTP-запиту. Ось навіщо ми розділили безпечне і звичайне вміст.
- SSLProtocol відключає всі протоколи, відмінні від TLS v1.0 і SSL v3.0. Для сучасних браузерів все буде працювати добре.
- SSLCipherSuite встановлює використання тільки HIGH і MEDIUM шифрів. SHA1 вважається більш безпечним, ніж MD5, тому обраний він.
- SSLCertificateFile і SSLCertificateKeyFile вказують розташування файлів сертифіката і ключа.
- SSLVerifyClient повинна бути встановлена як 'none', якщо не використовується аутентифікація прикладу.
Щоб запускати звичайний сервер на 80 порту, додайте наступний текст в конфігураційний файл:
Після збереження відредагованого конфігураційного файлу, запустіть сервер. Якщо ви використовували пароль при генерації сертифіката, вам знадобиться ввести його при запиті.
Створіть базову сторінку index.html в кореневій директорії вашого сервера, якщо у вас ще немає вмісту там.
Якщо це працює не так, як очікувалося, перш за все, перевірте, що ваш сервер взагалі запущений за допомогою команди ps -a | grep apache. Якщо вона не поверне результату, спробуйте перезапустити сервер і перевірте повідомлення про помилку в консолі.
Також перевірте, що права доступу до файлів сертифіката і ключа налаштовані належним чином (див. Вище), також, як і права до тестового HTML-файлу і директорії, в якій він знаходиться.
Потім, перевірте логи. Ви повинні перевірити як логи сервера, так і логи SSL, які ви налаштували в конфігураційному файлі вище. Якщо ви не знайшли там нічого корисного, спробуйте поміняти значення LogLevel в файлі конфігурації Apache2 на 'debug', перезапустіть Apache2 і протестуйте знову. Це повинно дати більше даних в логах.
Якщо проблема в SSL-з'єднанні, зручним інструментом буде s_client, який є діагностичної утилітою для вирішення проблем в TLS / SSL-судинних. Звичайне його використання: / usr / bin / openssl s_client -connect localhost: 443. Також існує безліч інших опцій, які ви можете дізнатися з документації. Якщо ви отримали повідомлення про помилки, це повинно вам допомогти у визначенні проблеми.
Вітаю! Тепер у вас є робочий безпечний сервер, з сертифікатом, автоматично перевіряється більшістю сучасних браузерів.