В вычислении , Internet Protocol Security ( IPsec ) представляет собой безопасный сетевой набор протоколов , который аутентифицирует и шифрует в пакет , направленные данные , чтобы обеспечить безопасный обмен данными между зашифрованными двумя компьютерами над Internet Protocol сетью. Он используется в виртуальных частных сетях (VPN).
IPsec включает протоколы для установления взаимной аутентификации между агентами в начале сеанса и согласования криптографических ключей для использования во время сеанса. IPsec может защищать потоки данных между парой хостов ( хост-хост ), между парой шлюзов безопасности ( сеть-сеть ) или между шлюзом безопасности и хостом ( сеть-хост ). [1] IPsec использует службы криптографической безопасности для защиты связи по сетям Интернет-протокола (IP). Он поддерживает аутентификацию однорангового узла на уровне сети, аутентификацию источника данных, целостность данных, конфиденциальность данных (шифрование) и защиту от воспроизведения.
Первоначальный пакет IPv4 был разработан с некоторыми мерами безопасности. Как часть усовершенствования IPv4, IPsec представляет собой модель OSI уровня 3 или схему сквозной безопасности интернет-уровня . Напротив, в то время как некоторые другие широко используемые системы безопасности в Интернете работают над уровнем 3, например, безопасность транспортного уровня (TLS), которая работает на транспортном уровне, и Secure Shell (SSH), которая работает на уровне приложений, IPsec может автоматически защищать приложения на уровень IP.
История
Начиная с начала 1970-х, Агентство перспективных исследовательских проектов спонсировало серию экспериментальных устройств шифрования ARPANET , сначала для собственного шифрования пакетов ARPANET, а затем для шифрования пакетов TCP / IP; некоторые из них были сертифицированы и выставлены на вооружение. С 1986 по 1991 год АНБ спонсировало разработку протоколов безопасности для Интернета в рамках своей программы Secure Data Network Systems (SDNS). [2] Это объединило различных поставщиков, включая Motorola, которая произвела устройство сетевого шифрования в 1988 году. Работа была открыто опубликована примерно с 1988 года NIST, и из них Security Protocol at Layer 3 (SP3) в конечном итоге трансформировался в стандартную сеть ISO. Протокол уровня безопасности (NLSP). [3]
С 1992 по 1995 годы различные группы проводили исследования в области шифрования на уровне IP.
- 1. В 1992 году Лаборатория военно-морских исследований США (NRL) начала проект Simple Internet Protocol Plus (SIPP) по исследованию и внедрению IP-шифрования.
- 2. В 1993 году в Колумбийском университете и в AT&T Bell Labs Джон Иоаннидис и другие исследовали экспериментальный программный протокол IP Encryption Protocol (swIPe) на SunOS .
- 3. В 1993 году Спонсор проекта интернет - услуг Уайтхаус, Вэй Сюй на Доверенные информационные системы (ТИС) дополнительно исследовал Программное обеспечение IP Протоколы безопасности и разработала аппаратную поддержку для тройного DES Data Encryption Standard , [4] , который был закодирован в BSD 4.1 и поддерживает архитектуры x86 и SUNOS. К декабрю 1994 года TIS выпустила свой продукт Gauntlet Firewall с открытым исходным кодом, спонсируемый DARPA, со встроенным аппаратным шифрованием 3DES на скоростях выше T1 . Это был первый случай использования IPSec VPN-соединений между восточным и западным побережьем Штатов, известный как первый коммерческий продукт IPSec VPN.
- 4. В рамках исследовательских усилий NRL, финансируемых DARPA , NRL разработала спецификации IETF для отслеживания стандартов (RFC 1825 - RFC 1827) для IPsec, которые были закодированы в ядре BSD 4.4 и поддерживали архитектуры процессоров x86 и SPARC. [5] Реализация IPsec в NRL была описана в их статье в протоколе конференции USENIX 1996 года. [6] Реализация IPsec с открытым исходным кодом NRL была сделана доступной в сети MIT и стала основой для большинства первоначальных коммерческих реализаций. [7]
Engineering Task Force Интернет (IETF) сформировала рабочую группу IP - безопасности в 1992 году [8] стандартизировать открыто указанные расширения безопасности для IP, называется IPsec . [9] В 1995 году рабочая группа организовала несколько семинаров с участием представителей пяти компаний (TIS, CISCO, FTP, Checkpoint и т. Д.). Во время семинаров по IPSec стандарты NRL и программное обеспечение Cisco и TIS стандартизируются в виде общедоступных ссылок, публикуемых как RFC-1825 - RFC-1827. [10]
Архитектура безопасности
IPsec - это открытый стандарт как часть пакета IPv4. IPsec использует следующие протоколы для выполнения различных функций: [11] [12]
- Заголовки аутентификации (AH) обеспечивают целостность данных без установления соединения и аутентификацию источника данных для дейтаграмм IP и обеспечивают защиту от атак повторного воспроизведения . [13] [14]
- Encapsulation Security Payloads (ESP) обеспечивает конфиденциальность , целостность данных без установления соединения, аутентификацию источника данных , службу защиты от повторного воспроизведения (форма частичной целостности последовательности) и ограниченную конфиденциальность потока трафика. [1]
- Протокол Internet Security Association and Key Management Protocol (ISAKMP) обеспечивает основу для аутентификации и обмена ключами [15] с фактическими аутентифицированными материалами для ключей , предоставляемыми либо путем ручной настройки с предварительными общими ключами , Internet Key Exchange (IKE и IKEv2), либо с помощью Kerberized Internet Negotiation ключей (KINK) или записей DNS IPSECKEY . [16] [17] [18] [19] Цель состоит в том, чтобы сгенерировать ассоциации безопасности (SA) с набором алгоритмов и параметров, необходимых для операций AH и / или ESP.
Заголовок аутентификации
Заголовок проверки подлинности безопасности ( AH ) был разработан в Лаборатории военно-морских исследований США в начале 1990-х годов и частично является производным от предыдущих стандартов IETF для проверки подлинности протокола SNMP версии 2. Заголовок проверки подлинности (AH) является член набора протоколов IPsec. AH обеспечивает целостность без установления соединения с помощью хэш-функции и секретного общего ключа в алгоритме AH. AH также гарантирует происхождение данных путем аутентификации IP- пакетов . Необязательно порядковый номер может защитить содержимое пакета IPsec против атак воспроизведения , [20] с помощью скользящего окна техника и отбрасывая старые пакеты.
- В IPv4 AH предотвращает атаки с вставкой опций. В IPv6 AH защищает как от атак вставки заголовков, так и от атак вставки опций.
- В IPv4 AH защищает полезную нагрузку IP и все поля заголовка дейтаграммы IP, за исключением изменяемых полей (т. Е. Тех, которые могут быть изменены при передаче), а также параметры IP, такие как параметр безопасности IP (RFC 1108). Изменяемые (и, следовательно, не прошедшие аутентификацию) поля заголовка IPv4 - это DSCP / ToS , ECN , флаги, смещение фрагмента , TTL и контрольная сумма заголовка . [14]
- В IPv6 AH защищает большую часть базового заголовка IPv6, сам AH, неизменяемые заголовки расширения после AH и полезную нагрузку IP. Защита заголовка IPv6 исключает изменяемые поля: DSCP , ECN , Flow Label и Hop Limit. [14]
AH работает непосредственно поверх IP, используя IP-протокол номер 51 . [21]
Следующая диаграмма пакета AH показывает, как создается и интерпретируется пакет AH: [13] [14]
Смещения | Октет 16 | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Октет 16 | Бит 10 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 год | 22 | 23 | 24 | 25 | 26 год | 27 | 28 год | 29 | 30 | 31 год |
0 | 0 | Следующий заголовок | Полезная нагрузка Len | Зарезервированный | |||||||||||||||||||||||||||||
4 | 32 | Индекс параметров безопасности (SPI) | |||||||||||||||||||||||||||||||
8 | 64 | Последовательность чисел | |||||||||||||||||||||||||||||||
C | 96 | Значение проверки целостности (ICV) ... | |||||||||||||||||||||||||||||||
... | ... |
- Следующий заголовок (8 бит)
- Тип следующего заголовка, указывающий, какой протокол верхнего уровня был защищен. Значение берется из списка номеров IP-протоколов .
- Длина полезной нагрузки (8 бит)
- Длина этого заголовка аутентификации в 4-октетных единицах минус 2. Например, значение AH, равное 4, равно 3 × (32-битные поля AH фиксированной длины) + 3 × (32-битные поля ICV) - 2 и, следовательно, значение AH, равное 4, означает 24 октета. Хотя размер измеряется в 4-октетных единицах, длина этого заголовка должна быть кратной 8 октетам, если он передается в пакете IPv6. Это ограничение не применяется к заголовку аутентификации, передаваемому в пакете IPv4.
- Зарезервировано (16 бит)
- Зарезервировано для использования в будущем (до этого момента все нули).
- Индекс параметров безопасности (32 бита)
- Произвольное значение, которое используется (вместе с IP-адресом назначения) для идентификации ассоциации безопасности принимающей стороны.
- Порядковый номер (32 бита)
- Монотонна строго возрастает порядковый номер (увеличивается на 1 для каждого отправленного пакета) для предотвращения повторных атак . Когда включено обнаружение воспроизведения, порядковые номера никогда не используются повторно, потому что новое сопоставление безопасности должно быть повторно согласовано перед попыткой увеличить порядковый номер сверх его максимального значения. [14]
- Значение проверки целостности (кратное 32 битам)
- Контрольное значение переменной длины. Он может содержать заполнение для выравнивания поля по 8-октетной границе для IPv6 или 4-октетной границе для IPv4 .
Инкапсуляция полезной нагрузки безопасности
Полезная нагрузка IP Encapsulating Security Payload (ESP) [22] была разработана в Военно-морской исследовательской лаборатории, начиная с 1992 года в рамках исследовательского проекта, спонсируемого DARPA , и была открыто опубликована рабочей группой IETF SIPP [23], созданной в декабре 1993 года в качестве обеспечения безопасности. расширение для SIPP. Этот ESP был первоначально получен из протокола SP3D Министерства обороны США , а не на основе протокола безопасности сетевого уровня (NLSP) ISO. Спецификация протокола SP3D была опубликована NIST в конце 1980-х годов, но была разработана в рамках проекта Secure Data Network System Министерства обороны США. Инкапсуляция полезной нагрузки безопасности (ESP) является членом набора протоколов IPsec. Она обеспечивает происхождения подлинность через источник аутентификации , целостности данных с помощью хэш - функций и конфиденциальности с помощью шифрования защиты IP - пакетов . ESP также поддерживает шифрование -только и аутентификации -Только конфигурации, но с использованием шифрования без проверки подлинности настоятельно не рекомендуется , потому что это небезопасно. [24] [25] [26]
В отличие от заголовка аутентификации (AH) , ESP в транспортном режиме не обеспечивает целостность и аутентификацию для всего IP-пакета . Однако в туннельном режиме , когда весь исходный IP-пакет инкапсулируется с добавленным новым заголовком пакета, защита ESP предоставляется для всего внутреннего IP-пакета (включая внутренний заголовок), в то время как внешний заголовок (включая любые внешние параметры IPv4 или расширение IPv6 заголовки) остается незащищенным. ESP работает непосредственно поверх IP, используя IP-протокол номер 50. [21]
На следующей диаграмме пакетов ESP показано, как создается и интерпретируется пакет ESP: [1] [27]
Смещения | Октет 16 | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Октет 16 | Бит 10 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 год | 22 | 23 | 24 | 25 | 26 год | 27 | 28 год | 29 | 30 | 31 год |
0 | 0 | Индекс параметров безопасности (SPI) | |||||||||||||||||||||||||||||||
4 | 32 | Последовательность чисел | |||||||||||||||||||||||||||||||
8 | 64 | Данные полезной нагрузки | |||||||||||||||||||||||||||||||
... | ... | ||||||||||||||||||||||||||||||||
... | ... | ||||||||||||||||||||||||||||||||
... | ... | Заполнение (0–255 октетов) | |||||||||||||||||||||||||||||||
... | ... | Длина колодки | Следующий заголовок | ||||||||||||||||||||||||||||||
... | ... | Значение проверки целостности (ICV) ... | |||||||||||||||||||||||||||||||
... | ... |
- Индекс параметров безопасности (32 бита)
- Произвольное значение, используемое (вместе с IP-адресом назначения) для идентификации ассоциации безопасности принимающей стороны.
- Порядковый номер (32 бита)
- Монотонно возрастает порядковый номер (увеличивается на 1 для каждого отправленного пакета) для защиты от атак воспроизведения . Для каждой ассоциации безопасности ведется отдельный счетчик.
- Данные полезной нагрузки (переменная)
- Защищенное содержимое исходного IP-пакета, включая любые данные, используемые для защиты содержимого (например, вектор инициализации для криптографического алгоритма). Тип защищенного содержимого указывается в поле « Следующий заголовок» .
- Заполнение (0–255 октетов)
- Padding для шифрования, чтобы расширить полезные данные до размера , который соответствует шифрованию в шифре размера блока, а также для выравнивания следующего поля.
- Длина контактной площадки (8 бит)
- Размер заполнения (в октетах).
- Следующий заголовок (8 бит)
- Тип следующего заголовка. Значение берется из списка номеров IP-протоколов .
- Значение проверки целостности (кратное 32 битам)
- Контрольное значение переменной длины. Он может содержать заполнение для выравнивания поля по 8-октетной границе для IPv6 или 4-октетной границе для IPv4 .
Ассоциация безопасности
Протоколы IPsec используют ассоциацию безопасности , при которой взаимодействующие стороны устанавливают общие атрибуты безопасности, такие как алгоритмы и ключи. Таким образом, IPsec предоставляет ряд опций после того, как было определено, используется ли AH или ESP. Перед обменом данными два хоста согласовывают, какой алгоритм используется для шифрования IP-пакета, например DES или IDEA , и какая хеш-функция используется для обеспечения целостности данных, например MD5 или SHA . Эти параметры согласованы для конкретного сеанса, для которого необходимо согласовать время жизни и сеансовый ключ . [28]
Алгоритм аутентификации также согласовывается до передачи данных, и IPsec поддерживает ряд методов. Аутентификация возможна через предварительный общий ключ , когда симметричный ключ уже находится во владении обоих хостов, и хосты отправляют друг другу хэши общего ключа, чтобы доказать, что они обладают одним и тем же ключом. IPsec также поддерживает шифрование с открытым ключом , где каждый хост имеет открытый и закрытый ключи, они обмениваются своими открытыми ключами, и каждый узел отправляет другому одноразовый номер, зашифрованный открытым ключом другого узла. В качестве альтернативы, если оба хоста имеют сертификат открытого ключа от центра сертификации , его можно использовать для аутентификации IPsec. [29]
Связи безопасности IPsec устанавливаются с использованием протокола сопоставления безопасности Интернета и управления ключами (ISAKMP). ISAKMP реализуется путем ручной настройки с использованием предварительно общих секретов, обмена ключами в Интернете (IKE и IKEv2), согласования ключей в Интернете по протоколу Kerberized (KINK) и использования записей DNS IPSECKEY . [19] [30] [31] RFC 5386 определяет безопасность лучше, чем ничего (BTNS) как неаутентифицированный режим IPsec с использованием расширенного протокола IKE. К. Медоуз, К. Кремерс и другие использовали формальные методы для выявления различных аномалий, существующих в IKEv1, а также в IKEv2. [32]
Чтобы решить, какая защита должна быть обеспечена для исходящего пакета, IPsec использует индекс параметров безопасности (SPI), индекс базы данных сопоставлений безопасности (SADB), а также адрес назначения в заголовке пакета, который вместе однозначно определяет ассоциация безопасности для этого пакета. Аналогичная процедура выполняется для входящего пакета, когда IPsec собирает ключи дешифрования и проверки из базы данных сопоставлений безопасности.
Для многоадресной IP-рассылки для группы предоставляется ассоциация безопасности, которая дублируется для всех авторизованных получателей группы. Для группы может быть несколько ассоциаций безопасности, использующих разные SPI, что позволяет использовать несколько уровней и наборов безопасности внутри группы. Действительно, у каждого отправителя может быть несколько ассоциаций безопасности, позволяющих аутентификацию, поскольку получатель может знать только то, что кто-то, знающий ключи, отправил данные. Обратите внимание, что соответствующий стандарт не описывает, как ассоциация выбирается и дублируется в группе; предполагается, что выбор сделает ответственная сторона.
Режимы работы
Протоколы IPsec AH и ESP могут быть реализованы в транспортном режиме от хоста к хосту, а также в режиме сетевого туннелирования.
Транспортный режим
В транспортном режиме обычно шифруется или аутентифицируется только полезная нагрузка IP-пакета . Маршрутизация остается неизменной, поскольку заголовок IP не модифицируется и не зашифровывается; однако, когда используется заголовок аутентификации , IP-адреса не могут быть изменены преобразованием сетевых адресов , так как это всегда делает недействительным значение хеш-функции . На транспортные и прикладные слои всегда обеспечены хэша, так что они не могут быть изменены каким - либо образом, например , путем перевода на порт номера.
Средства инкапсуляции сообщений IPsec для прохождения NAT были определены в документах RFC, описывающих механизм NAT-T .
Туннельный режим
В туннельном режиме весь IP-пакет зашифрован и аутентифицирован. Затем он инкапсулируется в новый IP-пакет с новым IP-заголовком. Туннельный режим используется для создания виртуальных частных сетей для связи между сетями (например, между маршрутизаторами для связывания сайтов), обмена данными между хостами (например, удаленный доступ пользователей) и обмена данными между хостами (например, частный чат). [33]
Туннельный режим поддерживает обход NAT.
Алгоритмы
Симметричные алгоритмы шифрования
Криптографические алгоритмы, определенные для использования с IPsec, включают:
- HMAC - SHA1 / SHA2 для защиты целостности и аутентичности.
- TripleDES - CBC для конфиденциальности
- AES- CBC и AES-CTR для конфиденциальности.
- AES- GCM и ChaCha20 - Poly1305, обеспечивающие конфиденциальность и одновременно эффективную аутентификацию.
Подробную информацию см. В RFC 8221.
Алгоритмы обмена ключами
- Диффи – Хеллмана (RFC 3526)
- ECDH (RFC 4753)
Алгоритмы аутентификации
- ЮАР
- ECDSA (RFC 4754)
- PSK (RFC 6617)
Реализации
IPsec может быть реализован в стеке IP операционной системы , что требует модификации исходного кода. Этот метод реализации предназначен для хостов и шлюзов безопасности. Различные IP-стеки с поддержкой IPsec доступны от таких компаний, как HP или IBM. [34] Альтернативой является так называемая реализация Bump-in-the-stack (BITS), при которой не нужно изменять исходный код операционной системы. Здесь IPsec устанавливается между стеком IP и сетевыми драйверами . Таким образом операционные системы могут быть дооснащены IPsec. Этот метод реализации также используется как для хостов, так и для шлюзов. Однако при модернизации IPsec инкапсуляция IP-пакетов может вызвать проблемы для автоматического определения MTU пути , когда устанавливается максимальный размер единицы передачи (MTU) на сетевом пути между двумя IP-узлами. Если у хоста или шлюза есть отдельный криптопроцессор , который широко используется в вооруженных силах, а также может быть найден в коммерческих системах, возможна так называемая реализация IPsec с технологией Bump-in-the-Wire (BITW). [35]
Когда IPsec реализован в ядре , управление ключами и согласование ISAKMP / IKE осуществляется из пользовательского пространства. Разработанный NRL и открыто указанный "API управления ключами PF_KEY, версия 2" часто используется, чтобы позволить приложению управления ключами пространства приложений обновлять сопоставления безопасности IPsec, хранящиеся в реализации IPsec пространства ядра. [36] Существующие реализации IPsec обычно включают ESP, AH и IKE версии 2. Существующие реализации IPsec в UNIX-подобных операционных системах, например, Solaris или Linux, обычно включают PF_KEY версии 2.
Встроенный IPsec может использоваться для обеспечения безопасной связи между приложениями, работающими в системах с ограниченными ресурсами, с небольшими накладными расходами. [37]
Статус стандартов
IPsec был разработан вместе с IPv6 и изначально должен был поддерживаться всеми совместимыми со стандартами реализациями IPv6, прежде чем RFC 6434 сделал это только рекомендацией. [38] IPsec также является необязательным для реализаций IPv4 . IPsec чаще всего используется для защиты трафика IPv4. [ необходима цитата ]
Протоколы IPsec были первоначально определены в RFC 1825 - RFC 1829, которые были опубликованы в 1995 году. В 1998 году эти документы были заменены RFC 2401 и RFC 2412 с некоторыми несовместимыми инженерными деталями, хотя они были концептуально идентичны. Кроме того, был определен протокол взаимной аутентификации и обмена ключами Internet Key Exchange (IKE) для создания ассоциаций безопасности и управления ими. В декабре 2005 г. новые стандарты были определены в RFC 4301 и RFC 4309, которые в значительной степени представляют собой надмножество предыдущих редакций со второй версией стандарта Internet Key Exchange IKEv2 . Эти документы третьего поколения стандартизировали сокращение IPsec до прописных «IP» и строчных «sec». «ESP» обычно относится к RFC 4303, который является самой последней версией спецификации.
С середины 2008 г. в IETF действует рабочая группа по обслуживанию и расширению IPsec (ipsecme). [39] [40]
Предполагаемое вмешательство АНБ
В 2013 годе , как часть утечек Snowden , было выявлено , что США Агентство национальной безопасности было активно работает «Вставка уязвимостей в коммерческие системы шифрования, информационные системы, сети и устройства связи конечных точек , используемых целями» в рамках Bullrun программы . [41] Есть утверждения, что IPsec был целевой системой шифрования. [42]
Стек OpenBSD IPsec появился позже и также был широко скопирован. В письме, которое ведущий разработчик OpenBSD Тео де Раадт получил 11 декабря 2010 года от Грегори Перри, утверждается, что Джейсон Райт и другие, работающие на ФБР, вставили «ряд бэкдоров и механизмов утечки ключей побочного канала » в криптографическую систему OpenBSD. код. В переадресованном электронном письме от 2010 года Тео де Раадт сначала не выразил официальной позиции по обоснованности претензий, за исключением неявного подтверждения от пересылки электронного письма. [43] Ответ Джейсона Райта на обвинения: «Каждая городская легенда становится более реальной благодаря включению реальных имен, дат и времени. Электронное письмо Грегори Перри попадает в эту категорию… Я четко заявляю, что я не добавлял бэкдоры в операционная система OpenBSD или криптографическая структура OpenBSD (OCF) ». [44] Несколько дней спустя де Раадт прокомментировал: «Я считаю, что NETSEC, вероятно, заключила контракт на написание бэкдоров, как якобы… Если бы они были написаны, я не думаю, что они вошли в наше дерево». [45] Это было опубликовано до утечки информации о Сноудене.
Альтернативное объяснение, выдвинутое авторами атаки Logjam, предполагает, что АНБ взломало IPsec VPN, подорвав алгоритм Диффи-Хеллмана , используемый при обмене ключами. В своей статье [46] они утверждают, что АНБ специально построило вычислительный кластер для предварительного вычисления мультипликативных подгрупп для определенных простых чисел и генераторов, например, для второй группы Oakley, определенной в RFC 2409. По состоянию на май 2015 года 90% адресных IPsec VPN поддерживали вторая группа Oakley в составе IKE. Если организация должна предварительно вычислить эту группу, она могла бы получить ключи, которыми обмениваются, и расшифровать трафик, не вставляя никаких программных бэкдоров.
Второе альтернативное объяснение, которое было выдвинуто, заключалось в том, что Equation Group использовала эксплойты нулевого дня против VPN-оборудования нескольких производителей, которые были проверены « Лабораторией Касперского» как привязанные к Equation Group [47] и подтвержденные этими производителями как реальные эксплойты. некоторые из них были эксплойтами нулевого дня на момент их раскрытия. [48] [49] [50] Cisco PIX и ASA брандмауэры были слабые места, которые были использованы для прослушки АНБ [ править ] .
Более того, IPsec VPN, использующие настройки «Агрессивного режима», отправляют хэш PSK в открытом виде. Это может быть и, по-видимому, является целью NSA, использующего автономные словарные атаки. [51] [52] [53]
Документация IETF
Трек стандартов
- RFC 1829: преобразование ESP DES-CBC
- RFC 2403: Использование HMAC-MD5-96 в ESP и AH
- RFC 2404: Использование HMAC-SHA-1-96 в ESP и AH
- RFC 2405: алгоритм шифрования ESP DES-CBC с явным IV
- RFC 2410: алгоритм шифрования NULL и его использование с IPsec
- RFC 2451: алгоритмы шифрования ESP в режиме CBC
- RFC 2857: Использование HMAC-RIPEMD-160-96 в ESP и AH
- RFC 3526: больше модульных экспоненциальных (MODP) групп Диффи-Хеллмана для обмена ключами в Интернете (IKE)
- RFC 3602: алгоритм шифрования AES-CBC и его использование с IPsec
- RFC 3686: Использование режима счетчика Advanced Encryption Standard (AES) с IPsec Encapsulating Security Payload (ESP)
- RFC 3947: Согласование прохождения NAT в IKE
- RFC 3948: UDP-инкапсуляция пакетов IPsec ESP
- RFC 4106: Использование режима Галуа / счетчика (GCM) в IPsec Encapsulating Security Payload (ESP)
- RFC 4301: Архитектура безопасности для Интернет-протокола
- RFC 4302: заголовок аутентификации IP
- RFC 4303: полезная нагрузка IP-инкапсуляции безопасности
- RFC 4304: Дополнение с расширенным порядковым номером (ESN) к домену интерпретации IPsec (DOI) для протокола ассоциации безопасности Интернета и протокола управления ключами (ISAKMP)
- RFC 4307: криптографические алгоритмы для использования в Internet Key Exchange версии 2 ( IKEv2 )
- RFC 4308: криптографические пакеты для IPsec
- RFC 4309: Использование режима CCM Advanced Encryption Standard (AES) с IPsec Encapsulating Security Payload (ESP)
- RFC 4543: Использование кода аутентификации сообщений Галуа (GMAC) в IPsec ESP и AH
- RFC 4555: протокол мобильности и множественной адресации IKEv2 (MOBIKE)
- RFC 4806: Расширения протокола состояния онлайн-сертификатов (OCSP) для IKEv2
- RFC 4868: Использование HMAC-SHA-256, HMAC-SHA-384 и HMAC-SHA-512 с IPsec
- RFC 4945: Профиль PKI безопасности IP в Интернете для IKEv1 / ISAKMP, IKEv2 и PKIX
- RFC 5280: Сертификат инфраструктуры открытого ключа Internet X.509 и профиль отзыва сертификатов (CRL)
- RFC 5282: Использование аутентифицированных алгоритмов шифрования с зашифрованной полезной нагрузкой протокола Internet Key Exchange версии 2 (IKEv2)
- RFC 5386: Безопасность лучше, чем ничего: режим IPsec без аутентификации
- RFC 5529: Режимы работы Camellia для использования с IPsec
- RFC 5685: механизм перенаправления для протокола обмена ключами в Интернете версии 2 (IKEv2)
- RFC 5723: возобновление сеанса протокола обмена ключами Интернета версии 2 (IKEv2)
- RFC 5857: расширения IKEv2 для поддержки надежного сжатия заголовков через IPsec
- RFC 5858: расширения IPsec для поддержки надежного сжатия заголовков по IPsec
- RFC 7296: протокол обмена ключами в Интернете версии 2 (IKEv2)
- RFC 7321: Требования к реализации криптографического алгоритма и руководство по использованию для инкапсуляции полезной нагрузки безопасности (ESP) и заголовка аутентификации (AH)
- RFC 7383: фрагментация сообщений протокола обмена ключами в Интернете версии 2 (IKEv2)
- RFC 7427: Аутентификация подписи в Internet Key Exchange версии 2 (IKEv2)
- RFC 7634: ChaCha20, Poly1305 и их использование в протоколе обмена ключами в Интернете (IKE) и IPsec
Экспериментальные RFC
- RFC 4478: повторная проверка подлинности в протоколе обмена ключами в Интернете (IKEv2)
Информационные RFC
- RFC 2367: интерфейс PF_KEY
- RFC 2412: протокол определения ключа OAKLEY
- RFC 3706: метод определения неработающих узлов обмена ключами в Интернете (IKE) на основе трафика
- RFC 3715: Требования совместимости IPsec с трансляцией сетевых адресов (NAT)
- RFC 4621: Разработка протокола мобильности и множественной адресации IKEv2 (MOBIKE)
- RFC 4809: Требования к профилю управления сертификатом IPsec
- RFC 5387: Проблема и Заявление о применимости для безопасности Better-Than-Nothing (BTNS)
- RFC 5856: интеграция надежного сжатия заголовков через ассоциации безопасности IPsec
- RFC 5930: Использование стандартного режима счетчика расширенного шифрования (AES-CTR) с протоколом Internet Key Exchange версии 02 (IKEv2)
- RFC 6027: Описание проблемы кластера IPsec
- RFC 6071: план разработки документов IPsec и IKE
- RFC 6379: криптографические наборы Suite B для IPsec
- RFC 6380: профиль Suite B для защиты интернет-протокола (IPsec)
- RFC 6467: Secure Password Framework для Internet Key Exchange версии 2 (IKEv2)
RFC с лучшими текущими практиками
- RFC 5406: Рекомендации по определению использования IPsec версии 2
Устаревшие / исторические RFC
- RFC 1825: Архитектура безопасности для Интернет-протокола (устарела RFC 2401)
- RFC 1826: заголовок аутентификации IP (устарел RFC 2402)
- RFC 1827: IP Encapsulating Security Payload (ESP) (устарело в соответствии с RFC 2406)
- RFC 1828: IP-аутентификация с использованием ключа MD5 (исторический)
- RFC 2401: Архитектура безопасности для Интернет-протокола (обзор IPsec) (устарело в соответствии с RFC 4301)
- RFC 2406: IP Encapsulating Security Payload (ESP) (устарело в соответствии с RFC 4303 и RFC 4305)
- RFC 2407: Internet IP Security Domain of Interpretation for ISAKMP (устарело RFC 4306)
- RFC 2409: Интернет-обмен ключами (устарело в соответствии с RFC 4306)
- RFC 4305: Требования к реализации криптографического алгоритма для инкапсуляции полезной нагрузки безопасности (ESP) и заголовка аутентификации (AH) (устарело в соответствии с RFC 4835)
- RFC 4306: протокол обмена ключами в Интернете (IKEv2) (устарел RFC 5996)
- RFC 4718: Разъяснения и рекомендации по реализации IKEv2 (устарело RFC 7296)
- RFC 4835: Требования к реализации криптографического алгоритма для инкапсуляции полезной нагрузки безопасности (ESP) и заголовка аутентификации (AH) (устарело в соответствии с RFC 7321)
- RFC 5996: протокол обмена ключами в Интернете версии 2 (IKEv2) (устарел RFC 7296)
Смотрите также
- Динамическая многоточечная виртуальная частная сеть
- Информационная безопасность
- Обход NAT
- Оппортунистическое шифрование
- tcpcrypt
Рекомендации
- ^ a b c Kent, S .; Аткинсон, Р. (ноябрь 1998 г.). IP-инкапсуляция безопасности полезной нагрузки (ESP) . IETF . DOI : 10,17487 / RFC2406 . RFC 2406 .
- ^ «Внедрение протокола IPSec - публикация конференции IEEE». DOI : 10,1109 / ACCT.2012.64 . S2CID 16526652 . Цитировать журнал требует
|journal=
( помощь ) - ^ «Архивная копия» . Архивировано из оригинала на 2014-09-03 . Проверено 18 февраля 2014 .CS1 maint: заархивированная копия как заголовок ( ссылка )
- ^ «История создания VPN» .
- ^ " http://web.mit.edu/network/isakmp/ "
- ^ " https://www.usenix.org/legacy/publications/library/proceedings/sd96/atkinson.html "
- ^ " http://web.mit.edu/network/isakmp/ "
- ^ «История рабочей группы протокола безопасности IP IETF (ipsec)» .
- ^ «RFC4301: Архитектура безопасности для Интернет-протокола» . Сетевая рабочая группа IETF. Декабрь 2005. с. 4.
Написание «IPsec» является предпочтительным и используется во всем этом и во всех связанных стандартах IPsec. Все другие заглавные буквы IPsec [...] устарели.
- ^ «Достижения NRL ITD - IPSec и IPv6» (PDF) . Лаборатории военно-морских исследований США .
- ^ Thayer, R .; Doraswamy, N .; Гленн Р. (ноябрь 1998 г.). Дорожная карта документа по безопасности ИС . IETF . DOI : 10,17487 / RFC2411 . RFC 2411 .
- ^ Хоффман, П. (декабрь 2005 г.). Криптографические пакеты для IPsec . IETF . DOI : 10,17487 / RFC4308 . RFC 4308 .
- ^ а б Kent, S .; Аткинсон, Р. (ноябрь 1998 г.). Заголовок аутентификации IP . IETF . DOI : 10,17487 / RFC2402 . RFC 2402 .
- ^ а б в г д Кент, С. (декабрь 2005 г.). Заголовок аутентификации IP . IETF . DOI : 10,17487 / RFC4302 . RFC 4302 .
- ^ Internet Key Exchange (IKE), RFC 2409, § 1 Аннотация
- ^ Харкинс, Д .; Каррел, Д. (ноябрь 1998 г.). Обмен ключами в Интернете (IKE) . IETF . DOI : 10,17487 / RFC2409 . RFC 2409 .
- ^ Кауфман, К. (ред.). IKE версии 2 . IETF . DOI : 10,17487 / RFC4306 . RFC 4306 .
- ^ Sakane, S .; Камада, К .; Thomas, M .; Вилхубер, Дж. (Ноябрь 1998 г.). Керберизованное Интернет-согласование ключей (KINK) . IETF . DOI : 10,17487 / RFC4430 . RFC 4430 .
- ^ а б Ричардсон, М. (февраль 2005 г.). Метод хранения ключевого материала IPsec в DNS . IETF . DOI : 10,17487 / RFC4025 . RFC 4025 .
- ^ Питер Уиллис (2001). IP-сети операторского масштаба: проектирование и эксплуатация Интернет-сетей . ИЭПП. п. 270. ISBN 9780852969823.
- ^ а б «Номера протоколов» . IANA . IANA . 27 мая 2010 г. Архивировано из оригинала на 2010-05-29.
- ^ «SIPP инкапсулирует полезную нагрузку безопасности» . Рабочая группа IETF SIPP. 1993. Архивировано из оригинала на 2016-09-09 . Проверено 7 августа 2013 .
- ^ «Проект Спецификации SIPP» . IETF. 1993. стр. 21.
- ^ Белловин, Стивен М. (1996). «Проблемные области для протоколов IP-безопасности» ( PostScript ) . Материалы шестого симпозиума по безопасности Usenix Unix . Сан-Хосе, Калифорния. С. 1–16 . Проверено 9 июля 2007 .
- ^ Патерсон, Кеннет Дж .; Яу, Арнольд К.Л. (24 апреля 2006 г.). «Криптография в теории и на практике: случай шифрования в IPsec» (PDF) . Eurocrypt 2006, Lecture Notes in Computer Science Vol. 4004 . Берлин. С. 12–29 . Проверено 13 августа 2007 .
- ^ Дегабриеле, Жан Поль; Патерсон, Кеннет Г. (2007-08-09). «Атака на стандарты IPsec в конфигурациях только для шифрования» (PDF) . Симпозиум IEEE по безопасности и конфиденциальности, IEEE Computer Society . Окленд, Калифорния. С. 335–349 . Проверено 13 августа 2007 .
- ^ Кент, С. (декабрь 2005 г.). IP-инкапсуляция безопасности полезной нагрузки (ESP) . IETF . DOI : 10,17487 / RFC4303 . RFC 4303 .
- ^ Питер Уиллис (2001). IP-сети операторского масштаба: проектирование и эксплуатация Интернет-сетей . ИЭПП. п. 271. ISBN. 9780852969823.
- ^ Питер Уиллис (2001). IP-сети операторского масштаба: проектирование и эксплуатация Интернет-сетей . ИЭПП. С. 272–3. ISBN 9780852969823.
- ^ RFC 2406, §1, стр. 2
- ^ Томас, М. (июнь 2001 г.). Требования к керберизованному Интернет-согласованию ключей . DOI : 10,17487 / RFC3129 . RFC 3129 .
- ^ C. Cremers, Обмен ключами в IPsec Revisited: формальный анализ IKEv1 и IKEv2, ESORICS 2011, опубликовано Springer: " https://link.springer.com/chapter/10.1007/978-3-642-23822-2_18 "
- Перейти ↑ William, S., & Stallings, W. (2006). Криптография и сетевая безопасность, 4 / E. Pearson Education India. п. 492-493
- ^ Питер Уиллис (2001). IP-сети операторского масштаба: проектирование и эксплуатация Интернет-сетей . ИЭПП. п. 266. ISBN. 9780852969823.
- ^ Питер Уиллис (2001). IP-сети операторского масштаба: проектирование и эксплуатация Интернет-сетей . ИЭПП. п. 267. ISBN. 9780852969823.
- ^ RFC 2367, API управления ключами PF_KEYv2 , Дэн Макдональд, Бао Фан и Крейг Мец (июль 1998 г.)
- ^ Хамад, Мохаммад; Превелакис, Василис (2015). Внедрение и оценка производительности встроенного IPsec в ОС микроядра . Всемирный симпозиум 2015 года по компьютерным сетям и информационной безопасности (WSCNIS) . IEEE. DOI : 10,1109 / wscnis.2015.7368294 . ISBN 9781479999064. S2CID 16935000 .
- ^ RFC 6434, «Требования к узлу IPv6», Э. Янкевич, Дж. Лоуни, Т. Нартен (декабрь 2011 г.)
- ^ «устав ipsecme» . Проверено 26 октября 2015 .
- ^ "статус ipsecme" . Проверено 26 октября 2015 .
- ^ «Секретные документы раскрывают кампанию АНБ против шифрования» . Нью-Йорк Таймс .
- ^ Джон Гилмор. "Re: [Криптография] Вступительное обсуждение: Спекуляции на" BULLRUN " " .
- ^ Тео де Раадт. «Утверждения относительно OpenBSD IPSEC» .
- ^ Джейсон Райт. «Утверждения относительно OpenBSD IPSEC» .
- ^ Тео де Раадт. «Обновленная информация по обвинению в бэкдоре OpenBSD IPSEC» .
- ^ Дэвид Адриан; Картикеян Бхаргаван; Закир Дурумерик; Пьеррик Годри; Мэтью Грин; Дж. Алекс Халдерман ; Надя Хенингер ; Дрю Спринголл; Эммануэль Томе; Люк Валента; Бенджамин ВандерСлот; Эрик Вустров; Сантьяго Занелла-Бегелинк; Пол Циммерманн. «Несовершенная прямая секретность: как Диффи-Хеллман терпит неудачу на практике» (PDF) .
- ^ Гудин, Дэн (16 августа 2016 г.). «Подтверждено: утечка средств взлома исходила от« всемогущей »группы, связанной с АНБ» . Ars Technica . Проверено 19 августа 2016 года .
- ^ Томсон, Иэн (17 августа 2016 г.). «Cisco подтверждает, что две уязвимости« АНБ »Shadow Brokers реальны» . Реестр . Проверено 16 сентября 2016 года .
- ^ Паули, Даррен (24 августа 2016 г.). «Эксплойт Equation Group поражает более новую версию Cisco ASA, Juniper Netscreen» . Реестр . Проверено 16 сентября 2016 года .
- ^ Чиргвин, Ричард (18 августа 2016 г.). «Fortinet следует за Cisco в подтверждении уязвимости Shadow Broker» . Реестр . Проверено 16 сентября 2016 года .
- ^ https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf
- ^ Каковы проблемы агрессивного режима IKEv1 (по сравнению с основным режимом IKEv1 или IKEv2)?
- ^ https://nohats.ca/wordpress/blog/2014/12/29/dont-stop-using-ipsec-just-yet/
Внешние ссылки
- Компьютерная безопасность в Curlie
- Все рабочие группы IETF по активной безопасности
- IETF ipsecme WG (Рабочая группа по поддержке и расширению IP-безопасности)
- IETF btns WG (рабочая группа «Безопасность лучше, чем ничего») (уполномочена работать с IPsec без аутентификации, API IPsec, фиксацией соединений)]
- Защита данных при передаче с помощью IPsec Статья Деб Шиндер на WindowsSecurity.com
- IPsec в Microsoft TechNet
- Средство диагностики Microsoft IPsec в Центре загрузки Майкрософт
- Иллюстрированное руководство по IPsec Стива Фридла
- Архитектура безопасности для передачи данных IP (IPsec) Лекции Манфреда Линднера Часть IPsec
- Создание виртуальных частных сетей с использованием IPsec и SSL / TLS Статья в Linux Journal Рами Розена