1. Введення в SSL
2. SSL, PCT, TLS і WTLS (але не SSH)
3. Установка Apache з підтримкою SSL / TLS
4. Налаштування SSL / TLS
5. перевіряємо установку
6. діагностика несправностей
7. Висновок до першої частини

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

Автор Artur Maj

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

Це перша стаття в циклі статей, присвячених налаштування Apache 2.0 з підтримкою SSL / TLS з метою досягнення максимальної безпеки і оптимальної продуктивності SSL-з'єднань. У першій частині цієї статті будуть описані ключові аспекти SSL / TLS, а потім показано - як налаштувати Apache 2.0 з підтримкою цих протоколів. У другій частині буде описано процес налаштування mod_ssl, далі - питання адрес з аутентифікацією веб-сервера. Крім того, у другій частині ми розберемося, як створити SSL-сертифікат веб-сервера. Третя і остання частина цієї серії розповість про аутентифікації клієнта, а також про деякі типові помилки настройки, які допускають системні адміністратори, що різко знижує рівень безпеки будь-якого SSL-з'єднання.

Введення в SSL

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

SSL - це багаторівневий протокол і складається з чотирьох під-протоколів:

• SSL Handshake Protocol
• SSL Change Cipher Spec Protocol
• SSL Alert Protocol
• SSL Record Layer

Місця вищевказаних протоколів, відповідно до моделі стека протоколів TCP / IP показані на рисунку 1.

Figure 1. Подпротоколи SSL в моделі TCP / IP

Як видно з діаграми, SSL знаходиться на рівні додатків моделі TCP / IP. Завдяки цьому, SSL може бути розгорнуто майже на будь-який ОС, що підтримує TCP / IP, без будь-якої правки ядра системи або TCP / IP стека. В результаті SSL має переваги перед іншими протоколами, такими як IPSec (IP Security Protocol), який вимагає підтримки модифікованого TCP / IP стека ядром системи. Крім того, SSL легко пропускають брандмауери, проксі і NAT (Network Address Translation - Перетворення Мережевих Адрес - прім.пер.) Без проблем.

Як працює SSL? На блок-схемі на рисунку 2 показаний спрощений покроковий процес установки SSL з'єднання між клієнтом (зазвичай веб-браузер) і сервером (найчастіше SSL веб-сервер).

Малюнок 2. Встановлення SSL з'єднань, крок за кроком.

Отже, процес установки з'єднання кожного нового SSL з'єднання починається з обміну параметрами шифрування, а потім (опціонально) відбувається аутентифікація серверів (через SSL Handshake Protocol). Якщо «рукостискання» вдалося, і обидві сторони погодилися на один і той же алгоритм шифрування і ключі шифрування, дані програми (зазвичай HTTP, але може бути і інший) можуть бути передані по зашифрованому каналу (використовується SSL Record Layer).

Якщо розглядати реальну ситуацію, то процес, описаний вище, виглядає набагато складніше. Щоб уникнути непотрібних «рукостискань» деякі параметри шифрування кешуються. При цьому можуть бути послані попереджувальні повідомлення. Також можуть бути змінені блоки шифру. Як би там не було, не залежно від тонкощів специфікації SSL, в загальному вигляді цей процес працює приблизно так, як показано на рисунку 2.

SSL, PCT, TLS і WTLS (але не SSH)

Хоча SSL - найвідоміший і популярний, але не єдиний протокол, який використовується для захисту веб транзакцій. Важливо знати, що з часу винаходу SSL v1.0 (релізу якого, до речі кажучи, не було) з'явилося, як мінімум, п'ять протоколів, які відіграли більш-менш важливу роль в захисті доступу до World Wide Web:

SSL v2.0

Рік випуску фірмою Netscape Communications в 1994. Основною метою цього протоколу було підвищити безпеку транзакцій через World Wide Web. На жаль, дуже швидко знайшлося кілька критичних вразливостей в безпеці цієї версії, що зробило його ненадійним для комерційного використання:

• Слабка конструкція MAC
• Можливість примусових партій для використання слабкого алгоритму шифрування
• Відсутність захисту «рукостискань»
• Можливість зловмисника здійснити атаки примусового завершення

PCT v1.0

Розроблено в 1995 році корпорацією Microsoft. У Privacy Communication Technology (PCT - Технологія Конфіденційною Зв'язки - прім.пер.) V1.0 були посилені деякі слабкі місця SSL v2.0, корпорація планувала замінити тим самим SSL. Однак, цей протокол так ніколи і не отримав популярності через появу SSL v3.0.

SSL v3.0

Рік випуску в 1996 році компанією Netscape Communications. В SSL v3.0 були вирішені більшість проблем SSL v2.0 і запозичене безліч можливостей нового для того часу протоколу PCT, внаслідок чого він швидко став найпопулярнішим протоколом для захисту з'єднань через WWW.

TLS v1.0 (також відомий як SSL v3.1)

Опублікований IETF (Internet Engineering Task Force - Проблемна Група Проектування Інтернет - прім.пер.) В 1999 році ( RFC 2246 ). Протокол базується на SSL v3.0 і PCT і узгоджений як з методами Netscape, так і з корпорацією Microsoft. Варто зауважити, що якщо TLS базується на SSL, він не 100% сумісний зі своїм попередником. IETF зробила деякі поправки в безпеці, наприклад використання HMAC замість MAC, використання іншого перерахунку основного шифру і ключового матеріалу, додані коди попередження, відсутня підтримка алгоритмів шифрування Fortezza і т.д. Зрештою безліч суперечливих змін призвели до того, що ці протоколи до ладу не могли взаємодіяти. На щастя, з'явився мод TLS з відкотом до SSL v3.0.

WTLS

«Мобільна і бездротова» версія протоколу TLS, яка використовує в якості носія UDP протокол. Він розроблений і оптимізований під нижню смугу частот і меншу пропускну здатність мобільних пристроїв з підтримкою WAP (Wireless Application Protocol - Протокол Бездротових Додатків - прім.пер.). WTLS був представлений з протоколом WAP 1.1 і був опублікований на форумі WAР. Однак, після релізу WAP 2.0, WTLS замінили профилированной версією TLS, яка виявилася набагато безпечніше - в основному через те, що в цій версії немає необхідності розшифровки і перешифровки трафіку на WAP шлюзі.

Чому протокол SSH (Secure Shell) не використовується для забезпечення безпечного доступу до World Wide Web? Ось кілька причин: по-перше, з самого початку TLS і SSL були розроблені для захисту веб (HTTP) сесій, тоді як SSH замислювався як альтернатива Telnet і FTP. SSL не виконує нічого, крім «рукостискання» і установки зашифрованого тунелю, а в SSH є можливість консольної авторизації, захищеної передачі файлів і підтримка складної схеми аутентифікації (включаючи паролі, публічні ключі, Kerberos і ін.). З іншого боку, SSL / TLS базований на сертифікатах X.509v3 і PKI, що робить поширення і управління аутентифікаційних мандатами набагато простіше. Отже, ці та інші причини роблять SSL / TLS зручнішим для захисту WWW доступу і подібних форм сполук, включаючи SMTP, LDAP і інші - тоді як SSH більше зручний для віддаленого управління системою.

У підсумку, незважаючи на існування кількох «безпечних» протоколів, тільки два слід використовувати для захисту веб-транзакцій (принаймні зараз): TLS v1.0 і SSL v3.0. Обидва протоколу будуть далі розглянуті в цих статтях як SSL / TLS. Через відомих слабкостей SSL v2.0, і знаменитої «WAP діри» у випадку з WTLS, використання таких протоколів слід уникати або максимально зменшувати.

Установка Apache з підтримкою SSL / TLS

Першим кроком в установці Apache з підтримкою SSL / TLS буде настройка і установка Apache 2 веб-сервера і створення користувача і групи з ім'ям "apache". Безпечний спосіб установки Apache 2.0 вже було розглянуто на Securing Apache 2.0: Step-by-Step . Єдина відмінність в тому, що потрібно включити mod_ssl і mod_setenvif, які потрібні для сумісності з деякими версіями MS Internet Explorer, як описано нижче (зміни виділені жирним):

./configure \ --prefix = / usr / local / apache2 \ --with-mpm = prefork \ --enable-ssl \ --disable-charset-lite \ --disable-include \ --disable-env \ - -enable-setenvif \ --disable-status \ --disable-autoindex \ --disable-asis \ --disable-cgi \ --disable-negotiation \ --disable-imap \ --disable-actions \ --disable -userdir \ --disable-alias \ --disable-so Після настройки ми можемо встановити Apache в кінцеву директорію: make su umask 022 make install chown -R root: sys / usr / local / apache2

Налаштування SSL / TLS

Перед запуском Apache в перший раз, нам потрібно підготувати деяку початкову конфігурацію і зразок веб-контенту. Як мінімум, ми повинні зробити наступне (під root):

1. Створення деякого веб-контенту, який буде обслуговуватися через TLS / SSL:

umask 022 mkdir / www echo "<html> <head> <title> Test </ title> </ head> <body> \ Test works. </ body> </ html>"> /www/index.html chown - R root: sys / www

1. Видалення конфігураційного файлу Apache, створеного за замовчуванням (зазвичай знаходиться в /usr/local/apache2/conf/httpd.conf) і заміна його новим, з використанням наступного контенту (оптимізовано для забезпечення безпеки і продуктивності).

# ================================================= # Basic settings # ============================================== === User apache Group apache ServerAdmin [email protected] ServerName www.seccure.lab UseCanonicalName Off ServerSignature Off HostnameLookups Off ServerTokens Prod ServerRoot "/ usr / local / apache2" DocumentRoot "/ www" PidFile / usr / local / apache2 /logs/httpd.pid ScoreBoardFile /usr/local/apache2/logs/httpd.scoreboard <IfModule mod_dir.c> DirectoryIndex index.html </ IfModule> # ================ ================================= # HTTP and performance settings # =========== ====================================== Timeout 300 KeepAlive On MaxKeepAliveRequests 100 KeepAliveTimeout 30 <IfModule prefork. c> MinSpareServers 5 MaxSpareServers 10 StartServers 5 MaxClients 150 MaxRequestsPerChild 0 </ IfModule> # ================================= ================ # Access control # ============================== =================== <Directory /> Options None AllowOverride None Order deny, allow Deny from all </ Directory> <Directory "/ www"> Order allow, deny Allow from all </ Directory> # ===================== ============================ # MIME encoding # ================== =============================== <IfModule mod_mime.c> TypesConfig /usr/local/apache2/conf/mime.types </ IfModule> DefaultType text / plain <IfModule mod_mime.c> AddEncoding x-compress .Z AddEncoding x-gzip .gz .tgz AddType application / x-compress .Z AddType application / x-gzip .gz .tgz AddType application / x -tar .tgz AddType application / x-x509-ca-cert .crt AddType application / x-pkcs7-crl .crl </ IfModule> # =================== ============================== # Logs # ================= ================================ LogLevel warn LogFormat "% h% l% u% t \"% r \ " %> s% b \ "% {Referer} i \" \ "% {User-Agent} i \" "combined LogFormat"% h% l% u% t \ "% r \"%> s% b "common LogFormat "% {Referer} i ->% U" referer LogFormat "% {User-agent} i" agent ErrorLog / usr / local / apache2 / logs / error_log CustomLog / usr / local / apache2 / logs / access_l og combined CustomLog logs / ssl_request_log \ "% t% h% {HTTPS} x% {SSL_PROTOCOL} x% {SSL_CIPHER} x \% {SSL_CIPHER_USEKEYSIZE} x% {SSL_CLIENT_VERIFY} x \"% r \ "% b" # == =============================================== # SSL / TLS settings # =============================================== == Listen 0.0.0.0:443 SSLEngine on SSLOptions + StrictRequire <Directory /> SSLRequireSSL </ Directory> SSLProtocol -all + TLSv1 + SSLv3 SSLCipherSuite HIGH: MEDIUM:! aNULL: + SHA1: + MD5: + HIGH: + MEDIUM SSLMutex file : / usr / local / apache2 / logs / ssl_mutex SSLRandomSeed startup file: / dev / urandom 1024 SSLRandomSeed connect file: / dev / urandom 1024 SSLSessionCache shm: / usr / local / apache2 / logs / ssl_cache_shm SSLSessionCacheTimeout 600 SSLPassPhraseDialog builtin SSLCertificateFile / usr / local / apache2 / conf / ssl.crt / server.crt SSLCertificateKeyFile /usr/local/apache2/conf/ssl.key/server.key SSLVerifyClient none SSLProxyEngine off <IfModule mime.c> AddType application / x-x509-ca-cert .crt AddType application / x-pkcs7-crl .crl </ IfModule> SetEnvIf User-Agent ". * MSIE. *" \ Nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0

Зауважте: читачі повинні змінити деякі значення цього конфігураційного файлу, таких як ім'я веб-сервера, e-mail адміністратора і т.д.

1. Підготуємо структури директорії для приватних ключів веб-сервера, сертифікатів та списків анульованих сертифікацій (CRLs - certification revocation lists)

umask 022 mkdir /usr/local/apache2/conf/ssl.key mkdir /usr/local/apache2/conf/ssl.crt mkdir /usr/local/apache2/conf/ssl.crl

1. Створюємо самоподпісанний серверний сертифікат (слід використовувати тільки для тестів - ваш справжній сертифікат повинен бути від достовірного СА - такого як Verisign):

openssl req \ -new \ -x509 \ -days 30 \ -keyout /usr/local/apache2/conf/ssl.key/server.key \ -out /usr/local/apache2/conf/ssl.crt/server.crt \ -subj '/ CN = Test-Only Certificate'

перевіряємо установку

Тепер можна запустити Apache з підтримкою SSL / TLS:

/ Usr / local / apache2 / bin / apachectl startssl Apache / 2.0.52 mod_ssl / 2.0.52 (Pass Phrase Dialog) Some of your private key files are encrypted for security reasons. In order to read them you have to provide us with the pass phrases. Server 127.0.0.1:443 (RSA) Enter pass phrase: ************* Ok: Pass Phrase Dialog successful.

Після запуску сервера ми можемо спробувати з'єднатися до нього, направивши веб-браузер на URL: https: // ім'я сервера (в нашому випадку, https: //www.seccure.lab)

Через деякий час ми повинні побачити попередження про те, що в ході перевірки аутентіфіфкаціі веб-сервера виникла проблема. На рисунку 3 показаний приклад такого повідомлення в MS Internet Explorer 6.0.

Малюнок 3. Зразкове повідомлення про сертифікат в IE 6.

Все працює правильно. Має бути прийнято це повідомлення через двох причин:

• Веб-браузер не знає Certificate Authority, який використовували при створенні даного сертифіката (і не може знати, адже ми використовуємо самоподпісанний сертифікат)
• Атрибут CN (Common Name - Загальна Ім'я) сертифіката не збігається з ім'ям веб-сайту - на даний момент «Test-Only Certificate» (Тільки для тестування), а повинен бути цілком визначене доменне ім'я веб сервера (наприклад www.seccure.lab)

Після натискання кнопки «Yes», ​​ми побачимо наступне веб вміст:

Малюнок 4. Приклад роботи SSL веб сторінки.

Внизу вікна браузера з'явився жовтий замок, що означає що SSL з'єднання було успішно встановлено. Значення "128-bit" говорить про те, що симетричний ключ, який використовується для шифрування дорівнює 128 біт, що досить таки непогано (принаймні зараз) для захисту трафіку від несанкціонованого доступу.

Виконавши подвійне клацання по значку замка, ми побачимо властивості сертифіката:

Малюнок 5. Детальніше про наш самоподпісанного сертифікаті.

діагностика несправностей

Якщо з якихось причин ми не можемо отримати доступ до веб-сайту, можна скористатися дуже корисною утилітою "s_client" від бібліотеки OpenSSL. Приклад використання цієї утиліти:

/ Usr / bin / openssl s_client -connect localhost: 443
CONNECTED (00000003)
depth = 0 / CN = Test-Only Certificate
verify error: num = 18: self signed certificate
verify return: 1
depth = 0 / CN = Test-Only Certificate
verify return: 1
---
Certificate chain
0 s: / CN = Test-Only Certificate
i: / CN = Test-Only Certificate
---
Server certificate
----- BEGIN CERTIFICATE -----
MIICLzCCAZigAwIBAgIBADANBgkqhkiG9w0BAQQFADAgMR4wHAYDVQQDExVUZXN0
LU9ubHkgQ2VydGlmaWNhdGUwHhcNMDQxMTIyMTg0ODUxWhcNMDQxMjIyMTg0ODUx
WjAgMR4wHAYDVQQDExVUZXN0LU9ubHkgQ2VydGlmaWNhdGUwgZ8wDQYJKoZIhvcN
AQEBBQADgY0AMIGJAoGBAMEttnihJ7JpksdToPi5ZVGcssUbHn / G + 4G43OiLhP0i
KvYuqNxBkSqqM1AanR0BFVEtVCSuq8KS9LLRdQLJ / B1UTMOGz1Pb14WGsVJS + 38D
LdLEFaCyfkjNKnUgeKMyzsdhZ52pF9febB + d8cLmvXFve28sTIxLCUK7l4rjT3Xl
AgMBAAGjeTB3MB0GA1UdDgQWBBQ50isUEV6uFPZ0L4RbRm41 + i1CpTBIBgNVHSME
QTA / gBQ50isUEV6uFPZ0L4RbRm41 + i1CpaEkpCIwIDEeMBwGA1UEAxMVVGVzdC1P
bmx5IENlcnRpZmljYXRlggEAMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEEBQAD
gYEAThyofbK3hg8AJXbAUD6w6 + mz6dwsBmcTWLvYtLQUh86B0zWnVxzSLDmwgdUB
NxfJ7yfo0PkqNnjHfvnb5W07GcfGgLx5 / U3iUROObYlwKlr6tQzMoysNQ / YtN3pp
52sGsqaOOWpYlAGOaM8j57Nv / eXogQnDRT0txXqoVEbunmM =
----- END CERTIFICATE -----
subject = / CN = Test-Only Certificate
issuer = / CN = Test-Only Certificate
---
No client certificate CA names sent
---
SSL handshake has read 1143 bytes and written 362 bytes
---
New, TLSv1 / SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is тисячу двадцять чотири bit
SSL-Session:
Protocol: SSLv3
Cipher: DHE-RSA-AES256-SHA
Session-ID: 56EA68A5750511917CC42A1B134A8F218C27C9C0241C35C53977A2A8BBB9986A
Session-ID-ctx:
Master-Key: 303B60D625B020280F5F346AB00F8A61A7C4BEA707DFA0ED8D2F52371F8C4F087FB6EFFC02CE3B48F912D2C8929DB5BE
Key-Arg: None
Start Time: 1101164382
Timeout: 300 (sec)
Verify return code: 18 (self signed certificate)
---
GET / HTTP / 1.0
HTTP / 1.1 200 OK
Date: Mon, 22 Nov 2004 22:59:56 GMT
Server: Apache
Last-Modified: Mon, 22 Nov 2004 17:24:56 GMT
ETag: "5c911-46-229c0a00"
Accept-Ranges: bytes
Content-Length: 70
Connection: close
Content-Type: text / html
<Html> <head> <title> Test </ title> </ head> <body> Test works. </ Body> </ html>
closed

Утиліта s_client має багато корисних опцій, наприклад включення / вимикання окремого протоколу (-ssl2, -ssl3, -tls1), вибір окремого алгоритму шифрування (-cipher), запуск режиму відладки (-debug), перегляд статистик і повідомлень SSL / TLS (- state, -msg), і деякі інші, які зможуть допомогти знайти причину неполадки.

Якщо s_client нічим не допоміг, слід змінити значення LogLevel (в httpd.conf) на "debug" і перезапустити Apache і перевірити його логи (/ usr / local / apache2 / logs /) для додаткової інформації.

Ще можна спробувати Ethereal або ssldump . Завдяки цим утилітам, ми можемо пасивно спостерігати SSL повідомлення «рукостискань» і намагатися знайти причину несправності. Ось скріншот використання Ethereal:

Figure 6. Перегляд SSL «рукостискання» в Ethereal.

Висновок до першої частини

Отже, ми маємо безпечний Apache 2 сервер в стані онлайн і приклад SSL-сертифіката, на чому і закінчується перша частина. В наступній частині ви познайомитеся з рекомендованими настройками безпеки і функцій для mod_ssl і процесом створення нормального сертифіката.