1. Установить браузеры, указанные в индивидуальном варианте задания
2. Запустите программу-анализатор сетевого трафика Wireshark
3. Запустите браузер № 1 и браузер №2
4. Выбрать по 2 сервера HTTP, HTTPS, SOCKS прокси
5. Запустите прослушивание сетевого интерфейса
Все настройки указываются в браузере № 1
Все переходы на сайты осуществляются с использованием обоих браузеров
6. Перейдите на сайт http://www.mtuci.ru
7. Перейти на сайт №1, указанный в индивидуальном задании
8. Перейдите на сайт https://www.google.com
9. Перейти на сайт №2, указанный в индивидуальном задании
10. Сохраните трассировку в файл
11. Остановите захват трафика
12. В настройках браузера установите HTTP прокси
13. Повторить шаги 5-11
14. В настройках браузера добавить в исключение http://www.mtuci.ru и https://www.google.com
15. Повторить шаги 5-11
16. Вернуть настройки в значения по умолчанию
17. В настройках браузера установите HTTPS прокси
18. Повторить шаги 5-11
19. В настройках браузера добавить в исключение http://www.mtuci.ru и https://www.google.com
20. Повторить шаги 5-11
21. Вернуть настройки в значения по умолчанию
|
|
22. В настройках браузера установите SOCKS прокси
23. Повторить шаги 5-11
24. В настройках браузера добавить в исключение http://www.mtuci.ru и https://www.google.com
25. Повторить шаги 5-11
26. Вернуть настройки в значения по умолчанию
27. Установите HTTP прокси в операционной системе
28. Повторить шаги 5-27
29. Установите HTTPS прокси в операционной системе
30. Повторить шаги 5-27
31. Установите SOCKS прокси в операционной системе
32. Повторить шаги 5-27
Индивидуальные варианты заданий
№ | Браузер №1 | Браузер №2 | Сайт 1 | Сайт 2 |
1 | Firefox | Edge | http://sportmaster.ru | https://yandex.ru |
2 | Firefox | Yandex | http://4pda.ru | https://avito.ru |
3 | Firefox | Chrome | http://ria.ru | https://vk.com |
4 | Firefox | Internet Explorer | http://rambler.ru | https://tvitter.com |
5 | Firefox | Edge | http://mvideo.ru | https://mail.ru |
6 | Firefox | Yandex | http://intuit.ru | https://wikipedia.ru |
7 | Firefox | Chrome | http://ozon.ru | https://yahoo.com |
Содержание отчёта
В отчет по работе должны войти следующие разделы:
· Титульный лист с названием работы;
· Задание;
· Цель работы и краткие теоретические сведения по тематике работы;
· Снимки экранов, полученных в результате выполнения этапов настройки и применения операционных систем и браузеров для работы с прокси-сервером;
· Заключение, содержащее выводы всем процедурам настройки и использования подключения к прокси-серверу.
Контрольные вопросы
1. Что такое прокси сервер?
2. В чем отличие HTTP, HTTPS, SOCKS прокси?
3. Для чего используется proxy?
4. Как классифицируются proxy-серверы?
5. Охарактеризуйте HTTP proxy?
6. Охарактеризуйте Socks proxy
7. Что такое анонимайзеры?
8. Охарактеризуйте FTP proxy?
9. Назовите уровни анонимности proxy-серверов.
10. Нужно ли перезагружать Windows или программы, настроив proxy?
|
|
Практикум №5
Изучение принципов работы протоколов SSL/TLS. Генерация SSL/TLS сертификатов
Цель работы
Изучение базовых принципов безопасного обмена информацией с использованием протокола SSL/TLS, получение сертификатов для последующего использования.
Краткие теоретические сведения.
Протокол SSL
Протокол SSL, также известный под утвержденным Инженерной группой IETF названием TLS – защищенный протокол, обеспечивающий аутентификацию и защиту от «прослушивания» (нарушение конфиденциальности) и искажения данных (нарушения целостности). Для аутентификации служат сертификаты Х.509 и проверки на основе связанных с ними закрытых ключей. Конфиденциальность обеспечивает шифрование данных, целостность – хэш-функции и коды аутентичности сообщения (Message Authenticity Code, MAC). SSL/TLS противостоит таким угрозам, как:
· Подмена идентификатора клиента или сервера (с помощью аутентификации);
· Раскрытие информации (с помощью шифрования канала связи);
· Искажение данных (с помощью кодов целостности сообщений).
Принцип работы SSL/TLS заключается в следующем. При установке SSL/TLS - соединения выполняется ряд операций, показанных на рисунке 1. Предполагается, что Web-сервер не требует сертификатной аутентификации клиента. Чтобы SSL/TLS действовал, Web-сервер должен иметь сертификат и личный ключ. Владелец сертификата должен подтвердить владение личным ключом, связанным с сертификатом. Иначе говоря, для аутентификации применяется пара: сертификат - личный ключ. Эта пара позволяют клиенту проверить, что этот сервер действительно тот, за кого себя выдает. Этот этап очень важен, так как перед тем как начать передачу нужно убедиться в подлинности сервера. Достигнув доверия, стороны выбирают ключ для симметричного шифрования данных в течение сеанса.
Рисунок 1 – Принцип работы SSL/TLS
Протокол SSL, разработанный компанией Netscape, стал стандартом де-факто, так как применялся в обозревателях и Web-серверах как Microsoft, так и Netscape. Из-за широкого распространения электронной коммерции в конце 90-х годов возникла потребность в защищенной передаче информации о пользователях и их кредитных карточках. Именно электронная коммерция стала катализатором популярности SSL.
Существуют две основные версии SSL 2 и 3. Предпочтительнее использовать SSL версии 3, так как в ней исправлены многие недостатки предыдущих версий протокола. В 1996 г. IETF решила стандартизировать протокол SSL и при этом изменила его название на Transport Layer Security. Текущей версии TLS присвоен номер 1. Однако внутренний номер версии TLS – 1.2, так как этот протокол расширяет SSL. Так что TLS — это SSL 3.1. В данный момент TLS имеет статус стандарта IETF (спецификация RFC 2246).
Стандарт X.509
X.509 является стандартом ITU-T для инфраструктуры открытых ключей (PKI) и управления привилегиями (PMI). X.509 определяет форматы данных и процедуры распределения открытых ключей с помощью сертификатов с цифровыми подписями. Эти сертификаты предоставляются удостоверяющими центрами. В документе RFC 1422 описаны основы для PKI на базе стандарта X.509. В RFC 5280 определены сертификат X.509 версии 3 и список отзыва сертификатов (CRL) версии 2. В криптографии PKCS#12 – один из стандартов семейства Public-Key Cryptography Standards (PKCS), опубликованных RSA Laboratories. Он определяет формат файла, используемый для хранения и/или транспортировки закрытого ключа (Private key), цепочки доверия от сертификата пользователя до корневого сертификата удостоверяющего центра и списка отзыва сертификатов (CRL). Защита файла осуществляется одним из двух способов: безопасным, с использованием доверенной ключевой пары (открытый/закрытый ключи, подходящие для цифровой подписи и шифрования) или менее безопасным, с использованием симметричного ключа, основанного на пароле. Второй подходит для случаев, когда использование доверенных пар открытый/закрытый ключей не доступно.
|
|
Формат PKCS#12
Формат PKCS#12 – это формат, предназначенный для хранения ключевой пары (закрытый ключ и сертификат), который распознается и используется многими браузерами и почтовыми агентами. В файлах PKCS#12 хранятся одновременно и закрытый ключ, и сертификат (разумеется в зашифрованном виде). Применяется следующая терминология:
· Цифровой сертификат – выпущенный удостоверяющим центром электронный или печатный документ, подтверждающий принадлежность владельцу открытого ключа или каких-либо атрибутов.
· Центр регистрации политики в Интернет-сети (Internet Policy Registration Authority – IPRA). Этот центр, функционирующий под эгидой Интернет-сообщества, выступает в роли корневого УЦ первого уровня в иерархической структуре сертификации PEM-системы. Он выпускает СЕРТ только для УЦ следующего уровня (УЦ, формирующие политики сертификации). Все МС начинаются с IPRA-центра.
· УЦ, формирующие политики сертификации (Policy Certification Authorities — PCA). PCA-центры располагаются на втором уровне иерархии, а каждый PCA-центр сертифицируется IPRA-центром. PCA-центр разрабатывает и опубликовывает положения своей политики, связанной с сертификацией пользователей или подчинённых УЦ. Специализированные PCA-центры предназначены для удовлетворения различных запросов пользователей. Например, один PCA-центр (организационный PCA-центр) может обеспечивать потребности коммерческих организаций в услугах общей электронной почты, а другой PCA-центр (высоко надёжный PCA-центр) может иметь более жёсткую политику, предназначенную для юридически обязательных требований по использованию ЭЦП.
· УЦ (Удостоверяющий центр Certification Authorities — CA). УЦ образуют третий уровень иерархии и могут располагаться на более низких уровнях. УЦ третьего уровня сертифицируются PCA-центрами. УЦ представляют, например, соответствующие организации, подразделения таких организаций, например, департаменты, группы, отделы) или соответствующие географические области.
|
|
· Центр регистрации (RA). Центр регистрации [Registration Authority (RA)] является необязательным компонентом инфраструктуры открытых ключей. В некоторых случаях роль RA выполняет CA. Там, где используется отдельный RA, он является доверенным конечным объектом, который сертифицирован CA и действует как подчиненный сервер CA. CA может делегировать некоторые из своих функций управления RA. К примеру, RA может выполнять персональные задачи аутентификации, сообщать об аннулированных сертификатах, генерировать ключи или архивировать пары ключей.
· Корневой сертификат SSL – одна из частей схемы PKI (инфраструктуры публичных ключей), которая идентифицирует корневой центр сертификации.
· Цепочка сертификатов – включает сертификат владельца открытого ключа (конечного субъекта), подписанный одним УЦ, и один или несколько (либо ни одного) сертификатов УЦ, подписанных другими УЦ.
OpenSSL
OpenSSL – криптографический пакет с открытым исходным кодом для работы с SSL/TLS. Позволяет создавать ключи RSA, DH, DSA и сертификаты X.509, подписывать их, формировать CSR и CRT. Также имеется возможность шифрования данных и тестирования SSL/TLS соединений. Доступна для большинства UNIX-подобных операционных систем (включая Solaris/OpenSolaris, Linux, Mac OS X, QNX4, QNX6 и четырех операционных систем BSD с открытым исходным кодом), а также для OpenVMS и Microsoft Windows. OpenSSL основана на SSLeay, написанной Эриком Янгом (Eric A. Young) и Тимом Хадсоном (Tim Hudson), которые неофициально закончили работать над ней в декабре 1998 года, когда они начали работать в проекте RSA Security. Официальный сайт: https://www.openssl.org/
При помощи OpenSSL можно создать собственный самоподписанный доверенный сертификат. Собственный доверенный сертификат (Certificate Authority или CA) необходим для подписи клиентских сертификатов и для их проверки при авторизации клиента веб-сервером. Пример такого сертификата:
openssl req -new -newkey rsa:4096-keyout ca.key -x509 -days 500-subj/C=RU/ST=Moscow/L=Moscow/O=Companyname/OU=User/CN=etc/emailAddress=support@site.com -out ca.crt
Описание аргументов:
· req - Запрос на создание нового сертификата.
· new - Создание запроса на сертификат (Certificate Signing Request – далее CSR).
· newkey rsa:4096. Автоматически будет создан новый закрытый RSA ключ длиной 4096 бит. Длину ключа можно настроить по своему усмотрению.
· keyout ca.key. Закрытый ключ сохранить в файл ca.key.
· x509. Вместо создания CSR (см. опцию -new) создать самоподписанный сертификат.
· days 500. Срок действия сертификата 500 дней. Размер периода действия можно настроить по своему усмотрению. Не рекомендуется вводить маленькие значения, так как этим сертификатом необходимо будет подписывать клиентские сертификаты.
· subj/C=RU/ST=Moscow/L=Moscow/O=Companyname/OU=User/CN=etc/email Address= support@site.com
Данные сертификата, пары параметр=значение, перечисляются через ‘/’. Символы в значении параметра могут быть «подсечены» с помощью обратного слэша «\», например «O=My\ Inc».
Также можно взять значение аргумента в кавычки, например, -subj «/xx/xx/xx». (В качестве данных сертификата в данной лабораторной работе вводите данные заданные преподавателем).
Создание сертификата сервера и запроса на него осуществляется следующим образом:
openssl genrsa -des3 -out server.key 4096
openssl req -new -key server.key -out server.csr
Подпись сертификата с подписью:
openssl x509 -req -days 365-in server.csr -CA ca.crt -CAkey ca.key -set_serial 01-out server.crt