Порядок выполнения работы

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