Всегда ли данные шифруются при обмене данными по протоколу IPv6?


30

Я не могу получить прямой ответ на этот вопрос. Википедия говорит, что «IPsec является неотъемлемой частью набора базовых протоколов в IPv6», но означает ли это, что ВСЕ сообщения всегда зашифрованы, или это означает, что шифрование не является обязательным, но устройства должны быть в состоянии понять его (если оно используется )?

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

Я бы расследовал это сам, но мне не хватает подключения по IPv6.

Обновление: Хорошо, так что это необязательно. Мой дополнительный вопрос: как правило, это приложение, которое определяет, использовать ли шифрование, или это операционная система?

Конкретный пример: представьте, что у меня есть последняя версия Windows с собственной поддержкой ipv6, и я что-то ищу на ipv6.google.com с помощью Mozilla Firefox. Будет ли это зашифровано?


16
IPSec похож на замок на двери; это может быть часть двери, но это не значит, что дверь обязательно заперта.
Крис С

@ Крис С: Замечательный комментарий, у меня есть мой голос за это.
SplinterReality

Ответы:


31

Нет.

IPv6 имеет встроенную IPsec как часть протокола, и это не болт, как с IPv4. Однако это не означает, что он включен по умолчанию, это просто означает (теоретически) более низкую нагрузку на сетевой стек.

Обычно использование IPsec определяется на уровне IP сетевого стека и, следовательно, определяется самой системной политикой. Например, система A может иметь политику, которая требует, чтобы и AH, и ESP имели связь с подсетью 4.0.0.0/8.

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

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


1
Спасибо за то, что вы явно отвергли ужасно популярный миф.
Марчин

3
О, вещи, которые могли бы быть. Возможно, мы получим это в IPv8 через несколько сотен лет.
Майкл Хэмптон

1
Я не согласен - шифрование всегда должно быть возможным и, в лучшем случае, очень простым. Требование определенного типа управления безопасностью независимо от наличия других элементов управления является немного недальновидным в отношении случаев использования, когда вы активно не хотите шифрование на уровне IP.
Growse

20

Краткий ответ: Нет.

Длинный ответ: IPsec был рассмотрен при разработке IPv6 в том смысле, что, в отличие от IPv4, IPsec (при использовании) является частью заголовка IPv6.

Более подробное объяснение: в IPv4 IPsec работает поверх самого IP. На самом деле это протокол уровня 4, который «маскируется» под протокол уровня 3 (так что обычные протоколы L4 TCP и UDP по-прежнему будут работать). ESP (Encapsulation Security Payload) не может охватывать IP-пакеты. В результате пакеты IPsec, как правило, будут значительно снижать пропускную способность, если предотвращается фрагментация. Кроме того, поскольку он находится поверх IP, заголовок IP не защищен.

В IPv6 IPsec является частью самого IP. Он может охватывать пакеты, поскольку заголовок ESP теперь является частью заголовка IP. А поскольку он интегрирован с IP, можно защитить больше частей заголовка IP.

Я надеюсь, что мое «в двух словах» объяснение достаточно ясно.


1
На самом деле, AH подписывает весь пакет, что означает, что ничего нельзя изменить (т. Е. NAT нарушает его). Вот почему очень немногие IPSec-туннели фактически используют AH. И это один из многих расширений заголовков , а не буквально «часть заголовка IP».
Рикки Бим

2

Вопрос для вас:

Операционная система определяет, когда использовать шифрование. Эти параметры «политики» находятся внутри панелей управления / политик конфигурации. Вы говорите что-то вроде «если вы хотите подключиться к любому адресу в подсети ab12 :: у вас должен быть секретный Blah1234». Есть варианты использования PKI.

В настоящий момент приложение не может добавить эту политику или потребовать ее настройки. В разделе linux ipv6 есть упоминание «Поддержка IPSec для заголовков EH и AH отсутствует», поэтому люди подумали об этом, но в настоящее время нет известных рабочих реализаций.


1

К вашему последующему вопросу да и нет.

Приложения могут указывать шифрование, но шифрование выполняется на уровне приложения. Существует множество пар незашифрованных / зашифрованных протоколов, использующих разные порты, такие как HTTP / HTTPS, LDAP / LDAPS, IMAP / IMAPS и SMTP / SSMTP. Все они используют шифрование SSL или TLS. Некоторые сервисы предлагают опцию startTLS, которая позволяет запускать зашифрованное соединение через обычно незашифрованный порт. SSH - это приложение, которое всегда использует зашифрованное соединение. Шифрование является сквозным для этих случаев. (Существует алгоритм шифрования NULL, который можно использовать, и зашифрованный контент будет передаваться в незашифрованном виде.)

IPSEC настраивается администратором, и приложение не будет знать, зашифровано ли соединение. В основном я видел IPSEC, используемый для мостового трафика между локальными сетями через незащищенные соединения (VPN-соединения). Я считаю, что IPSEC может применяться только к части маршрута, поэтому в некоторых сегментах сети данные передаются в незашифрованном виде (в незашифрованном виде).

Если у меня есть выбор, я буду использовать шифрование приложений, так как сетевое шифрование не используется.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.