Курс лекций «Проблемы безопасности в информационных технологиях»



жүктеу 4.51 Mb.
бет24/44
Дата13.09.2017
өлшемі4.51 Mb.
түріКурс лекций
1   ...   20   21   22   23   24   25   26   27   ...   44

Протокол TLS


TLS (Transport Layer Security — безопасность транспортного уровня), как и его предшественник SSL — криптографические протоколы, обеспечивающие защищённую передачу данных между узлами в сети TCP/IP. TLS и SSL используют асимметричную криптографию для обмена ключами, симметричное шифрование для конфиденциальности и коды аутентичности сообщений для сохранения целостности сообщений.

TLS-протокол основан на спецификации протокола SSL версии 3.0, разработанной компанией Netscape Communications. Сейчас развитием стандарта TLS занимается IETF. Последнее на сегодня обновление протокола было в RFC5246.

Т.к. TLS основан на SSL, то основные характеристики, параметры и алгоритмы этих протоколов весьма схожи. В некоторых источниках их не различают, описывая некий обобщённый TLS/SSL протокол (при этом имеются в виду версии SSL v3.0 и новее, и TLS v1.0 и новее). TLS, также как и SSL, даёт возможность клиент-серверным приложениям осуществлять связь в сети таким образом, чтобы предотвратить прослушивание сеанса и несанкционированный доступ.

Так как множество протоколов связи могут быть использованы как с, так и без TLS (или SSL), при установке соединения необходимо явно указать серверу, хочет ли клиент устанавливать TLS. Это может быть достигнуто либо с помощью использования определённого номера порта, по которому соединение всегда устанавливается (подразумевается) с использованием TLS (implicit) (как, например, порт 443 для HTTPS, 993 для IMAPS, 990 для FTP). Либо с использованием произвольного порта и специальной команды серверу со стороны клиента на переключение соединения на TLS/SSL с использованием специальных механизмов протокола (explicit) – STARTTLS.



Рис.58 Explicit и implicit соединение для FTPS
Как только клиент и сервер договорились об использовании TLS, им необходимо установить защищенное соединение. Это делается с помощью процедуры подтверждения связи (Secure Socket Layers).

Поскольку, как отмечено выше, TLS представляет некоторую модификацию SSL, дальше будет представлен список различий между этими двумя протоколами, чтобы не повторять одно и то же описание протокола.




  • TLS не поддерживает алгоритм Fortezza для смены ключей или для шифрования/дешифрования.

  • Генерация криптографической секретности в TLS более сложная, чем в SSL. TLS сначала определяет две функции: функцию расширения данных и псевдослучайную функцию.

  • TLS поддерживает все аварийные сигналы, определенные в SSL, за исключением NoCertificate. TLS также добавляет к списку SSL некоторые новые аварийные сигналы.

  • TLS вносит некоторые изменения в протокол установления соединения. Были специально изменены детали сообщения CertificateVerify и сообщения «finished». Было также изменено вычисление хеша для сообщения «finished». TLS использует PRF (pseudo-random function), чтобы вычислить два хеша, применяемых для сообщения «finished».

  • Отличие в протоколе передачи записей – используется HMAC, чтобы подписать сообщение. TLS применяет MAC для того чтобы создать HMAC. TLS также добавляет версию протокола (названную сжатой версией) к тексту, который будет подписан.

Современное состояние протоколов TLS с точки зрения безопасности: некоторое время назад было опубликовано сообщение, что исследователи обнаружили серьёзную слабость практически во всех сайтах, защищённых SSL протоколом, которая позволяет злоумышленнику молча расшифровать данные, которые проходят между веб-сервером и браузером пользователя.

Уязвимость обнаружена в версии 1.0 и ранних версиях TLS. Версии TLS 1.1 и 1.2 не восприимчивы к уязвимости, однако они почти не используются, что делает такие сайты как PayPal, GMail и множество других уязвимыми, если злоумышленник имеет возможность контролировать связь между пользователем и конечным сайтом. Любопытно распределение по версиям протоколов, приведённое в статье (данные на сентябрь 2011 года):


Рис.59 Распределение версий протоколов SSL и TLS

Протокол SSH


SSH (Secure SHell — «безопасная оболочка») — сетевой протокол прикладного уровня, позволяющий производить удалённое управление операционной системой, а также туннелирование TCP-соединений (например, для передачи файлов). Схож по функциональности с протоколами Telnet и rlogin, но, в отличие от них, шифрует весь трафик, включая и передаваемые пароли. SSH допускает выбор различных алгоритмов шифрования. SSH-клиенты и SSH-серверы доступны для большинства современных операционных систем.

SSH позволяет безопасно передавать в незащищённой среде практически любой другой сетевой протокол (TCP-соединение). Таким образом, можно не только удалённо работать на компьютере через командную оболочку, но и передавать по шифрованному каналу звуковой поток, сеанс удалённого доступа, видео и т.п. Также SSH может сжимать передаваемые данные для последующего их шифрования, что удобно, например, для удалённого запуска клиентов X Window System.

Протокол SSH позволяет, в принципе, защитить любое TCP-соединение. Но для обеспечения безопасного доступа к WWW традиционно используются TLS/SSL. Вот несколько причин, почему HTTPS работает поверх TLS/SSL, а не SSH: во-первых, с самого начала TLS и SSL разрабатывались именно для защиты web (HTTP) сессий, тогда как SSH исходно задумывался как альтернатива небезопасным Telnet, rlogin и FTP. SSL не выполняет ничего, кроме «рукопожатия» и установки зашифрованного туннеля, а в SSH имеется возможность консольной авторизации, защищённой передачи файлов и поддержка сложной схемы аутентификации (включая пароли, публичные ключи, Kerberos и другие технологии). С другой стороны, SSL/TLS базируется на сертификатах X.509v3 и PKI, что делает распространение и управление открытыми ключами намного проще для конечного пользователя. Эти и другие причины делают SSL/TLS более удобным для защиты WWW доступа и подобных форм соединений, включая SMTP, LDAP, IMAP и других – тогда как SSH более удобен для удалённого управления системой.

Первая версия протокола, SSH-1, была разработана в 1995 году исследователем Тату Улёненом из Технологического университета Хельсинки (Финляндия). SSH-1 был написан для обеспечения большей конфиденциальности, чем протоколы rlogin, telnet и rsh2. В 1996 году была разработана более безопасная версия протокола, SSH-2, несовместимая с SSH-1. В настоящее время под термином «SSH» обычно подразумевается именно SSH-2, т.к. первая версия протокола, ввиду существенных недостатков и изъянов в безопасности, сейчас практически не применяется.

В некоторых странах (Франция, Россия, Ирак, Пакистан) до сих пор требуется специальное разрешение в соответствующих структурах для использования определённых методов шифрования, включая методы, присутствующие в протоколе SSH.

Распространены две реализации SSH: проприетарная коммерческая и бесплатная свободная. Свободная реализация называется OpenSSH. По некоторым оценкам к 2006 году 80% компьютеров сети Интернет использовало именно OpenSSH. Проприетарная реализация разрабатывается организацией SSH Communications Security, которая является стопроцентным подразделением корпорации Tectia, эта реализация бесплатна для некоммерческого использования. Обе реализации содержат практически одинаковый набор команд и взаимозаменяемы по основным параметрам.

Протокол SSH-2, в отличие от протокола telnet, устойчив к атакам прослушивания трафика («снифинг»), но уязвим по отношению к атакам «человек посередине». Протокол SSH-2 также устойчив к атакам путем присоединения посредине (session hijacking), так как невозможно включиться в уже установленную сессию или перехватить её.

Для предотвращения атак «человек посередине» при подключении к хосту, ключ которого ещё не известен клиенту, клиентское ПО показывает пользователю «слепок ключа» (т.н. key fingerprint). Рекомендуется тщательно проверять показываемый клиентским ПО «слепок ключа» со слепком ключа сервера, желательно полученным по надёжным каналам связи или лично3.

SSH реализует клиент-серверную модель работы. Сервер прослушивает соединения от клиентских машин и при установлении связи производит аутентификацию, после чего начинает обслуживание клиента. Клиент используется для входа на удалённую машину и выполнения команд.

Для соединения сервер и клиент должны создать пары ключей — открытых и закрытых — и обменяться открытыми ключами. Может использоваться (и часто используется) парольная аутентификация.

По сравнению с SSL/TLS у SSH есть некоторая специфика в части обеспечения безопасности:


  • Рекомендуется запрещать удалённый root-доступ. Безопаснее будет входить в систему под обычной учётной записью, а уже в этой сессии выполнять su или sudo4.

  • Рекомендуется запрещать подключения с пустым паролем.

  • Рекомендуется выбирать нестандартный порт для SSH-сервера (вместо стандартного 22).

  • Настоятельно рекомендуется использовать длинные SSH-2 RSA-ключи (2048 бит и более). На сегодня системы шифрования на основе RSA считаются надёжными, если длина ключа не менее 1024 бит.

  • По возможности ограничивать список IP-адресов, с которых разрешён доступ (например, настройкой firewall’а).

  • Использовать ловушки, подделывающие (имитирующие) SSH-сервис (т.н. honeypots5).

Одним из очень важных и полезных «бонусов» SSH можно назвать его способность организовывать защищённые TCP-туннели. Незашифрованный трафик какого-либо протокола шифруется на одном конце SSH-соединения и расшифровывается на другом.

SSH — это протокол прикладного уровня. SSH-сервер обычно прослушивает соединения на 22-ом TCP-порту. Спецификация протокола SSH-2 содержится в RFC4251. Для аутентификации сервера в SSH используется протокол аутентификации сторон на основе алгоритмов электронно-цифровой подписи RSA или DSA. Для аутентификации клиента также может использоваться ЭЦП RSA или DSA, но допускается также аутентификация при помощи пароля (режим обратной совместимости с Telnet) и даже ip-адреса хоста (режим обратной совместимости с rlogin). Аутентификация по паролю наиболее распространена; она вполне безопасна, так как пароль передаётся по зашифрованному виртуальному каналу. Аутентификация по ip-адресу небезопасна, эту возможность рекомендовано отключать. Для создания общего секрета (сеансового ключа) используется алгоритм Диффи—Хеллмана (DH). Для шифрования передаваемых данных используется симметричное шифрование, алгоритмы AES, Blowfish или 3DES. Целостность передачи данных проверяется с помощью CRC32 в SSH1 или HMAC-SHA1/HMAC-MD5 в SSH2.

Для сжатия шифруемых данных может использоваться алгоритм LempelZiv (LZ77), который обеспечивает такой же уровень сжатия, как и архиватор ZIP. Сжатие SSH включается лишь по запросу клиента, и на практике используется не очень часто.

SSH состоит из трех компонентов:


  1. Протокол транспортного уровня (SSH-TRANS) обеспечивает аутентификацию сервера, конфиденциальность и целостность соединения. Также может дополнительно обеспечивать сжатие данных. Протокол транспортного уровня обычно выполняется поверх соединения TCP, но может использоваться и поверх любого другого надежного соединения.

  2. Протокол аутентификации пользователя (SSH-USERAUTH) аутентифицирует клиента для сервера. Он выполняется поверх протокола транспортного уровня.

  3. Протокол соединения (SSH-CONN), мультиплексирует несколько логических каналов в один зашифрованный туннель. Протокол выполняется поверх протокола аутентификации пользователя.

Клиент посылает запрос на сервис всякий раз, когда устанавливается безопасное соединение на транспортном уровне. Второй запрос сервиса посылается после выполнения аутентификации пользователя.
Протокол соединения создает каналы, которые могут использоваться для различных целей. Существуют стандартные методы установки безопасных сессий интерактивного shell и перенаправления («туннелирования») произвольных портов TCP/IP и соединений Х11.

Каждый сервер должен иметь ключ хоста. Серверы могут иметь несколько ключей хоста, используемых различными алгоритмами. Несколько серверов могут разделять один ключ хоста. Каждый сервер должен иметь, по крайней мере, один ключ для каждого обязательного алгоритма открытого ключа.

С помощью ключа сервера при обмене ключа можно проверить, действительно ли клиент общается с нужным сервером. Для того, чтобы это было возможно, клиент должен предварительно знать об открытом ключе сервера. Основная реализация на сегодня: локальная база у клиента (произвольного формата), связывающуя каждое имя сервера с соответствующим открытым ключом. Этот метод не требует централизованной административной инфраструктуры и трёхсторонней координации. В то же время, такую базу данных тяжело поддерживать при большом количестве клиентов и серверов, с которыми они должны взаимодействовать.

В современных Unix-системах клиент OpenSSH хранит базу «имя сервера-открытый ключ» в «скрытом» каталоге ~/.ssh, в текстовом файле known_hosts. В самом популярном SSH-клиенте для Windows – Putty – база хранится в реестре, в ветке конкретного пользователя.

В реализации OpenSSH используются дополнительные меры безопасности, лежащие вне собственно протокола. Например, клиенту будет отказано в подключении к серверу, на котором каталог ~/.ssh имеет разрешения на доступ для пользователей, отличных от владельца (т.е., на месте ‘x’ в маске доступа 07xx обязаны быть только нули).

Вариант работы SSH с ключами, использующий технологию PKI (CA и т.д.), подобному тому, как это реализовано для TLS/SSL, на сегодня так и не стал массовым, и не очень распространён.

В протоколе существует опция, которая позволяет не проверять связывание имя сервера–открытый ключ при первом соединении клиента с сервером. Это обеспечивает возможность взаимодействия без предварительного знания ключа сервера. В этом случае соединение обеспечивает защиту от пассивного прослушивания, но оно будет уязвимо для активных атак типа «человек посередине». Реализации не должны допускать такие соединения по умолчанию, если допускается возможность активных атак.

Все реализации должны обеспечить опцию, не позволяющую принимать ключи сервера, которые невозможно проверить.

Протокол позволяет вести полные переговоры об алгоритмах и форматах шифрования, целостности, обмена ключей, сжатия и открытого ключа. Алгоритмы шифрования, целостности, открытого ключа и сжатия могут отличаться для каждого направления или каждого порта.

Проблемы политики безопасности решаются указанием параметров конфигурации (в конфигурационных файлах, опциями командной строки):




  • Должны быть определены наиболее предпочтительные алгоритмы шифрования, целостности и сжатия для каждого направления и каждого порта.

  • Должны быть определены используемые алгоритмы открытого ключа и метод обмена ключей для аутентификации сервера.

  • Должны быть определены методы аутентификации, которые использует сервер для каждого пользователя. Может быть определено требование множественной аутентификации для некоторых или для всех пользователей. Методы и алгоритмы аутентификации могут также зависеть от того, с какого адреса пользователь пытается подключиться.

  • Должны быть определены операции, которые пользователю разрешено выполнять, используя протокол соединения.

Минимальный размер пакета SSH равен 28 байт. Возрастание минимального размера по сравнению с заголовками TCP/IP незначительно для больших пакетов, но очень существенно для небольших, типичных, например, для интерактивных сессий telnet. Минимальный размер заголовка TCP/IP равен 32 байтам. Таким образом, реально заголовок пакета возрастает с 33 до 61 байта.

Некоторые проблемы могут быть связаны с максимальным размером пакета (его уменьшением). Для минимизации задержки на изменение экрана в интерактивных сессиях не должно использоваться большие пакеты. О максимальном размере пакета стороны договариваются отдельно для каждого канала.

В большинстве случаев протоколы SSH непосредственно не выводят текст на терминал пользователя. Тем не менее, существует несколько случаев, в которых данные должны быть выведены на терминал. В этом случае набор символов должен быть указан явно. В большинстве случаев используется кодировка ISO 10646 UTF-8. При этом определяется поле для тега языка.

Существует большая проблема с набором символов для интерактивных сессий. Простого решения не существует, так как различные приложения могут показывать данные в различных форматах. Клиентом также могут применяться различные типы эмуляции терминалов, и используемый набор символов зависит от эмуляции терминала. Таким образом, для непосредственного описания используемого набора символов для данных терминальной сессии единственного места не существует. Тем не менее, стандартный тип эмуляции терминала "vt100" передается клиенту и неявно определяет набор символов и кодировку. Приложения обычно используют тип терминала для определения набора символов, или набор символов определяется с использованием внешних параметров. Эмуляция терминала может также допускать конфигурирование набора символов по умолчанию. В любом случае набор символов для терминальной сессии первоначально локально определяется клиентом.

Протокол SSH ссылается на конкретные алгоритмы хеширования, шифрования, целостности, сжатия и обмена ключа по именам. Существуют некоторые стандартные алгоритмы, которые должны поддерживать все реализации. Существуют также алгоритмы, которые определены в протоколе, но являются дополнительными. Более того, возможно, что некоторые организации захотят использовать собственные алгоритмы.

Имена, которые не содержат символ "@", зарезервированы для обозначений IANA. Примерами являются '3des-cbc', 'sha-1', 'hmac-sha1'. Имена данного формата не должны использоваться без регистрации в IANA. Зарегистрированные имена не должны содержать символов "@" или "." (точка).

Определения дополнительных алгоритмов можно использовать имена в формате name@domainname. Часть, следующая за символом @, должна представлять собой полностью определенное доменное Internet-имя лица или организации. Каждый домен управляет своим локальным пространством имен.

Единственным обязательным методом аутентификации является аутентификация с использованием открытого ключа. Все реализации должны поддерживать этот метод. Однако не все пользователи имеют открытые ключи, и большинство локальных политик, вероятно, не будут требовать в ближайшем будущем обязательной аутентификации с использованием открытого ключа.

При использовании данного метода посылается подпись, созданная закрытым ключом пользователя. Сервер должен убедиться, что открытый ключ данного пользователя является действительным, и проверить, что подпись правильна. Если оба этих условия выполняются, запрос аутентификации должен считаться выполненным; в противном случае он должен быть отвергнут. Заметим, что сервер может потребовать дополнительную аутентификацию после успешного завершения данной аутентификации.

При аутентификации по ключу, если закрытый ключ клиента зашифрован и для доступа к нему приходится вводить пароль (passphrase), существует технология, позволяющая вводить этот пароль однократно (по одному разу для каждого из используемых закрытых ключей), а не каждый раз при установлении каждой новой сессии. Эта технология реализуется ssh-agent-ом: при запуске агента необходимо указать passphrase для требуемого закрытого ключа. Агент загрузит его и будет хранить ключ в оперативной памяти (можно добавлять/удалять ключи и после запуска агента), предоставляя его по требованию без последующего ввода пароля.

Интересной возможностью ssh-agent является т.н. agent forwarding. Пользователь запускает на своей рабочей станции (ws) ssh-agent-а, потом, используя полученный от него ключ, подключается к серверу A (активировав опцию allow agent forwarding). После установления сессии с сервером A, пользователь инициирует с него, уже как клиента, новую ssh-сессию с сервером B – и механизм agent forwarding-а позволит открыть сессию A->B с использованием того же ключа, который обслуживается ssh-agent-ом на исходной рабочей станции пользователя. Запрос к ключу прозрачно «пробрасывается» с сервера A на ws. Этой технологией не сто́ит пользоваться, если вы не доверяете администратору «промежуточного» сервера A, т.к. при установленном соединении ws->A администратор сервера A может воспользоваться закрытым ключом пользователя (на станции ws) и установить соединения с другими серверами от его имени.

Примеры перенаправления портов (port forwarding), доступные в SSH, приведены ниже. Порты могут «пробрасываться» в двух направлениях: с локальной машины на удалённую и, наоборот, с удалённой – на локальную:
ssh -L 4430:srv.example.com:443 user@somehost
В этом примере организуется интерактивная сессия пользователя user на somehost, с одновременным установление туннеля с точкой «входа» localhost:4430 до «конечной» точки srv.example.com:443. Туннель будет зашифрован от localhost до somehost, в somehost он будет расшифрован и «проброшен» до srv.example.com:443.

Можно, используя факт, что имя (адрес) localhost (127.0.0.1) всегда локальны для машины, построить туннель, который не будет иметь нешифрованной части:


ssh -L 59990:localhost:5900 59991:rs.example.com:5900 user@srv.example.com
В этом примере устанавливается интерактивная сессия с srv.example.com, и устанавливается туннель с точкой «входа» localhost:59990 (клиентская машина) до «конечной» точки srv.example.com:5900 (т.к. localhost в 59990:localhost:5900 относится уже к srv.example.com, т.е. интерактивная сессия и туннель образованы между одной и той же парой машин). Одновременно в примере организован второй туннель, от localhost:59991 (клиентская машина) до rs.example.com:5900. От srv.example.com до rs.example.com:5900 канал будет не зашифрован.

Используя дополнительные технологии (nc, fifo) в некоторых ОС (например, FreeBSD), можно организовать транспортировку UDP через SSH-туннель.





Достарыңызбен бөлісу:
1   ...   20   21   22   23   24   25   26   27   ...   44


©kzref.org 2019
әкімшілігінің қараңыз

    Басты бет