пїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ
Слишком длинный поисковый запрос.
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Когда вы входите на финансовый или медицинский веб-сайт и входите в систему, вы должны ожидать, что полученная вами информация не будет перехвачена и прочитана кем-либо на пути между вашим компьютером и сервером. Менее очевидная, но не менее важная проблема заключается в том, что информация, которую вы отправляете на сайт, не должна быть открыта для изменения во время ее передачи по сети.
Но как это можно обеспечить? Это две области, для решения которых можно использовать транспортную безопасность. В этой серии статей будет рассмотрено пространство проблем транспортной безопасности, а затем будет проведено исследование нескольких видов решений, включая шифрование. Наконец, в этой серии статей мы рассмотрим спецификацию безопасности транспортного уровня (TLS) в качестве примера шифрования транспортного уровня.
Проблемное пространство
Безопасность обычно решает одну из четырех проблем: подтверждение того, что данные не были изменены при передаче, предотвращение доступа к информации никому, кроме предполагаемого получателя, защита конфиденциальности людей, использующих сеть, и подтверждение того, что информация была доставлена. Вторая и третья проблемы, предотвращение несанкционированного доступа к данным при их передаче по сети и защита конфиденциальности пользователей, являются связанными проблемами, но будут рассматриваться отдельно в следующих разделах. Последняя отмеченная проблема, проблема доказательства обхода (которая аналогична проблеме доказательства работы, которая встречается в других контекстах информационных технологий), здесь не рассматривается, поскольку это область активных исследований с небольшим количеством развернутых систем.
Проверка данных
Если вы войдете на сайт своего банка и переведете 100 рублей с одного счета на другой, вы, скорее всего, будете расстроены, если на самом деле сумма перевода составит 1000 рублей или если номера счетов будут изменены, так что 100 рублей окажутся на чьем-то другом счете. Существует ряд других ситуаций, когда необходимо убедиться, что передаваемые данные совпадают с полученными, например:
Если вы покупаете пару синих туфель, вы не хотите, чтобы вместо них доставили комплект красных.
Если ваш врач дает вам рецепт на лекарство от изжоги (вероятно, вызванной стрессом от работы сетевым инженером), вы не хотите, чтобы вам доставляли лекарство от артрита (вероятно, из-за того, что вы печатаете так много документов и книг).
Существует множество ситуаций, когда полученные данные должны совпадать с переданными, а отправитель и/или получатель должны быть поддающимися проверке.
Защита данных от проверки
Примеры защиты данных, приведенные выше, позволяют сделать еще один шаг вперед: вы не хотите, чтобы кто-то видел номер вашего счета, рецепт или другую информацию, когда она передается по сети. Номера счетов, пароли и любая личная информация (PII) очень важны, поскольку эти виды информации могут быть использованы для взлома счетов с целью кражи денег или даже для кражи конфиденциальной информации.
Как можно защитить такую информацию? Основным средством защиты, используемым для предотвращения неавторизованных пользователей (или злоумышленников), является шифрование.
Защита конфиденциальности пользователей
Конфиденциальность - это не просто приятно особенность глобального интернета, это требование пользователей доверять системе. Это верно и для локальных сетей, если пользователи считают, что за ними каким-то образом шпионят, они вряд ли будут использовать сеть. Скорее всего, они будут использовать sneakernet, распечатывая информацию и перенося ее вручную, а не передавая по сети. Хотя многие люди считают, что конфиденциальность не является обоснованной проблемой, в этой области существует много обоснованных проблем.
Например, в области управления информацией часто говорят: "Знание - сила". Информация о компьютере или сети дает вам определенную власть над компьютером, сетью или системой. Например, предположим, что банк настраивает автоматическое резервное копирование для определенной таблицы базы данных; когда остатки на счете, хранящемся в таблице, изменяются на определенную величину, резервное копирование запускается автоматически. Это может показаться вполне разумным вариантом резервного копирования, но оно требует исчерпания некоторого объема данных.
Примечание: исчерпание данных - это информация о физических движениях людей или информация, которая может быть использована для вывода о том, что делают эти люди или эта информация. Например, если вы каждое утро едете на работу одним и тем же маршрутом, кто-то может сделать вывод, что после того, как вы проделали какую-то небольшую часть поездки в сочетании со временем суток, вы собираетесь работать. Такие же типы данных существуют и в сетевом мире; если каждый раз, в определенное время суток, через сеть передается определенный фрагмент данных определенного размера, и он случайно совпадает с определенным событием, таким как перевод денег между двумя счетами, то, когда появляются эти конкретные данные, передача должна иметь место. Просмотр, история электронной почты и другие действия в интернете-все это приводит к исчерпанию данных, которые иногда могут быть использованы для вывода содержимого потока данных, даже если поток зашифрован.
Уязвимость здесь заключается в следующем: если злоумышленник создает резервную копию вместе с изменением значения учетной записи, этот человек будет точно знать, какова модель активности учетной записи. Достаточное количество таких подсказок можно превратить в целый набор планов атаки.
То же самое верно и в отношении людей; знание о людях может дать вам некоторую способность влиять на людей в определенных направлениях. Хотя влияние на людей не так велико, как влияние на машины, передача власти одному человеку над другим всегда несет в себе моральные последствия, с которыми нужно обращаться осторожно.
Область решений
Хотя каждое решение проблем безопасности и конфиденциальности, описанных в предыдущих разделах, обычно включает в себя сложные математические вычисления, в этом разделе будут (попытаемся) описать решения без математических расчетов.
Шифрование
Шифрование берет блок информации (открытый текст) и кодирует его, используя некоторую форму математической операции, чтобы скрыть текст, в результате чего получается зашифрованный текст. Чтобы восстановить исходный простой текст, математические операции должны быть отменены. Хотя шифрование часто рассматривается как математическая конструкция, иногда проще начать думать о нем как о шифре подстановки с таблицей подстановок, которая меняется в зависимости от используемого ключа. Рисунок 1 иллюстрирует это.
Кстати, про типы шифрования в России и за рубежом можно почитать тут.
На рисунке 1 показан четырехбитовый блок информации - тривиальный пример, но все же полезный для демонстрации. Процесс шифрования концептуально представляет собой серию прямых замен:
Рис. 1 Блок шифрования как таблица подстановки
Если 0001 находится в исходном блоке данных (открытый текст) и используется ключ 1, то 1010 подставляется в фактический передаваемый поток (зашифрованный текст).
Если 0010 обнаружен в открытом тексте и используется ключ 1, то 0100 подставляется в передаваемые данные.
Если 0001 найден в открытом тексте и используется ключ 2, то в передаваемые данные подставляется 0000.
Если 0110 находится в открытом тексте и используется ключ 2, то в передаваемые данные подставляется 1001.
Процесс замены одного блока бит на другой называется преобразованием. Эти преобразования должны быть симметричными: они должны не только позволять шифрование открытого текста в зашифрованный текст, но они также должны позволять восстанавливать открытый текст (незашифрованный) из зашифрованного текста. В таблице подстановок этот процесс включает поиск ключа на стороне зашифрованного текста таблицы и замену эквивалента открытого текста.
Размер таблицы подстановки определяется размером блока или количеством битов, кодируемых за один раз. Если, например, используется 128-битный блок, в поисковой таблице должно быть 2128 записей - действительно, очень большое количество. Этот вид пространства все еще можно быстро найти с помощью эффективного алгоритма, поэтому блок должен иметь некоторые другие особенности, кроме просто большого размера.
Во-первых, шифротекстовая сторона блока подстановки должна быть как можно более случайной. Чтобы преобразование было идеальным, любой шаблон, найденный в открытом тексте, не должен быть доступен для анализа в результирующем зашифрованном тексте. Выход зашифрованного текста должен выглядеть как можно ближе к случайному набору чисел, независимо от того, какой вход.
Во-вторых, блок подстановки должен быть настолько большим, насколько это практически возможно. Чем более случайным и большим является блок подстановки, тем труднее вернуться от открытого и зашифрованного текста к обнаружению используемого шаблона подстановки. Чтобы выполнить brute-force атаку против подстановки с использованием 128-битного размера блока, злоумышленник должен соотнести как можно больше из 2128 записей в блоке открытого текста с 2128 записями в блоке подстановки зашифрованного текста-если информация использует только небольшой (или разреженный) набор возможных записей из исходного 128-битного пространства, практически нет способа сделать корреляцию достаточно быстрой, чтобы сделать такую атаку практичной, учитывая, что шифрующий отправитель достаточно часто меняет свой ключ.
Примечание. Когда дело доходит до размера блока, существует закон убывающей доходности; в какой-то момент увеличение размера блока не увеличивает эффективность шифра при сокрытии информации.
Плотность лучше всего объяснить на примере. Предположим, что вы используете шифр прямой подстановки в английском языке, где каждая буква заменяется буквой, смещенной на четыре шага в алфавите. В этом виде (тривиального) шифра:
Каждая буква А будет заменена буквой Е.
Каждая буква B будет заменена буквой F.
Каждая буква С будет заменена буквой G.
и т.д.
Теперь попробуйте зашифровать два разных предложения с помощью этого преобразования:
THE SKY IS BLUE == XLI WOC MW FPYI
THE QUICK BROWN FOX JUMPED OVER THE LAZY DOG == XLI UYMGO FVSAR JSB NYQTIH SZIV XLI PEDC HSK
Для злоумышленника, пытающегося выяснить, как версия предложения с зашифрованным текстом соотносится с версией открытого текста, первое предложение представляет 9 совпадающих пар букв из пространства, содержащего 26 возможных букв. Есть хороший шанс, что вы сможете угадать правильное преобразование - переместитесь на четыре шага вправо - из этого небольшого образца, но возможно, что здесь задействован какой-то "трюк", из-за которого будущие сообщения, зашифрованные с помощью этого преобразования, не будут расшифрованы правильно. Однако второе предложение - это хорошо известный пример предложения, содержащего все возможные буквы английского алфавита. Преобразование может быть проверено на соответствие каждому возможному значению во всем диапазоне ввода и вывода, что делает обнаружение преобразования тривиальным.
В этом примере первое предложение будет менее плотным, чем второе. В реальных криптографических системах общая идея состояла бы в том, чтобы использовать всего несколько тысяч возможных символов из 2128 или 2512 возможных символов, что создает гораздо менее плотный набор информации для работы. В какой-то момент плотность становится достаточно низкой, преобразование - достаточно сложным, а зашифрованный текст - достаточно случайным, так что не существует практического способа вычислить взаимосвязь между входом (открытым текстом) и выходом (зашифрованный текст).
В реальной жизни блоки замены не вычисляются заранее таким образом. Скорее, для вычисления значения замены в реальном времени используется криптографическая функция. Эти криптографические функции принимают входной размер блока, открытый текст, выполняют преобразование и выводят правильный зашифрованный текст. Ключ - это второй вход, который изменяет выходные данные преобразования, поэтому каждый ключ приводит к тому, что преобразование производит разные выходные данные. Если размер ключа равен 128 битам, а размер блока равен 256 битам, существует 2128 × 2256 возможных выходных комбинаций из преобразования. Рисунок 2 иллюстрирует это.
На рисунке 2 каждая таблица подстановки представляет собой размер блока. Если размер блока составляет 256 бит, то в каждой таблице имеется 2256 возможных замен. Каждый ключ создает новую таблицу, поэтому, если ключ составляет 128 бит, то существует 2128 возможных таблиц. Есть два основных способа атаковать такую систему шифрования.
Первый способ атаковать этот тип системы шифрования-попытаться сопоставить каждое возможное входное значение с каждым возможным выходным значением, раскрывая всю таблицу подстановок. Если входные данные представляют только небольшой набор возможных входных данных (таблица используется редко или, точнее, представляет собой разреженный массив), эта задача практически невыполнима. Если пользователь меняет свой ключ, а следовательно, и конкретную таблицу среди возможного набора таблиц, достаточно часто, нет никакого способа выполнить это сопоставление быстрее, чем изменяется ключ.
Примечание. Даже в больших блоках, объединенных с преобразованиями, все еще есть потенциальные слабые места, позволяющие получить почти случайный результат-другими словами, даже если преобразование близко к идеалу. Если вы соберете 23 человека в одной комнате, есть большая вероятность, что у двух из них будет один и тот же день рождения-но это кажется иррациональным, потому что есть 365 потенциальных дней (не считая високосные года), в которые человек может родиться. Причина несоответствия между тем, что должно произойти, и тем, что происходит, заключается в следующем: в реальном мире дни рождения людей группируются по очень небольшому числу дней в течение года. Таким образом, входные данные представляют собой очень плотное "пятно" в умеренно большом наборе возможных значений. Когда это происходит, разреженность данных может работать против системы шифрования. Если небольшой набор данных повторяется в большом наборе на регулярной основе, злоумышленник может сосредоточиться только на наиболее часто используемых заменах и потенциально обнаружить содержимое сообщения, достаточное для восстановления большей части смысла.
Второй способ атаковать систему шифрования такого типа - атаковать само преобразование - криптографическую функцию. Помните, что эти большие таблицы подстановки часто невозможно сгенерировать, сохранить и транспортировать, поэтому используется некоторая форма криптографической функции, чтобы принимать блок открытого текста в качестве входных данных и генерировать блок зашифрованного текста в качестве выходных данных. Если бы вы могли обнаружить эту функцию преобразования, то вы могли бы вычислить вывод таким же образом, как передатчик и приемник, и расшифровать открытый текст в реальном времени.
В реальном мире эта проблема усложняется из-за:
Принцип Керкхоффа, согласно которому само преобразование не должно быть секретом. Скорее, только ключ, используемый для выбора таблицы из возможных, должен храниться в секрете.
По крайней мере, некоторый открытый и зашифрованный текст иногда может быть восстановлен из текущей зашифрованной передачи данных по различным причинам-возможно, ошибка, или, возможно, смысл шифрования заключается в проверке текста, а не в том, чтобы не дать тексту быть прочитанным.
Учитывая эти ограничения, следует учитывать несколько ключевых моментов:
Сложность вычисления ключа из открытого текста, зашифрованного текста и криптографической функции (преобразования) должна быть очень высокой.
Случайность вывода криптографической функции должна быть очень высокой, чтобы снизить вероятность успешных brute-force атак - просто перебора всех возможных ключей в пространстве.
Ключевое пространство должно быть большим, опять же, чтобы предотвратить успешные brute-force атаки.
Качество криптографической функции определяется способностью функции выдавать максимально близкий к случайному результату практически любой вход таким образом, чтобы злоумышленник не мог обнаружить, какой ключ используется, даже если у них есть как открытый текст, так и зашифрованный текст. Таким образом, криптографические функции обычно используют ту или иную форму одной из самых сложных для вычисления задач. В частности, часто используется вычисление множителей очень больших простых чисел.
Что произойдет, если вы используете 128-битный блок и у вас есть 56 бит данных для транспортировки? В этой ситуации наиболее естественным образом было бы дополнить открытый текст некоторым числом: скорее всего, всеми нулями или единицами. Качество вывода в некоторой степени зависит от разреженности ввода, чем меньше диапазон чисел используется как вход, тем более предсказуемым будет выход криптографической функции. В этом случае важно использовать заполнение, максимально приближенное к случайному. Существует целая область изучения того, как дополнять блоки открытого текста, чтобы "помочь" криптографической функции создавать зашифрованный текст, максимально приближенный к случайному.
Несколько раундов шифрования
Одну и ту же информацию можно обрабатывать с помощью криптографической функции несколько раз. Например, если у вас есть 128-битный блок и 128-битный ключ, вы можете:
Возьмите открытый текст и с помощью ключа вычислите зашифрованный текст. Назовите это ct1.
Возьмите ct1 и с помощью ключа вычислите шифротекст второго раунда; назовите это ct2.
Возьмите ct2 и, используя ключ, вычислите шифротекст третьего раунда; назовите это ct3.
Фактический передаваемый шифротекст будет последним ct3. К чему приводит этот процесс? Помните, что качество процесса шифрования связано со случайностью выхода по отношению к входу. Каждый раунд во многих ситуациях лишь немного увеличивает случайность. В этом процессе есть точка уменьшения отдачи; обычно после третьего раунда данные не становятся "более случайными", и, следовательно, больше раундов, по сути, просто тратят вычислительную мощность и время для очень небольшого выигрыша.
Криптография с открытым и закрытым ключом
Существует класс криптографических функций, которые могут преобразовывать открытый текст в зашифрованный текст и обратно, используя два разных ключа. Эта возможность полезна, когда вы хотите иметь возможность зашифровать блок данных одним ключом и позволить кому-то другому расшифровать данные, используя другой ключ. Ключ, который вы держите в секрете, называется закрытым ключом, а ключ, который вы передаете другим или публикуете, называется открытым ключом.
Например, чтобы доказать, что вы являетесь фактическим отправителем конкретного файла, вы можете зашифровать файл своим закрытым ключом. Теперь любой человек с вашим открытым ключом может расшифровать файл, который мог быть отправлен только вами. Обычно вы не шифруете весь блок данных своим закрытым ключом (на самом деле большинство систем, использующих пары ключей, спроектированы так, что вы не можете этого сделать). Скорее, с помощью вашего закрытого ключа создается подпись, которая может быть проверена с помощью вашего открытого ключа. Чтобы убедиться, что только человек, которому вы отправляете данные, может что-то прочитать, вы можете зашифровать некоторые данные своим открытым ключом, опубликовать их, и только человек с правильным закрытым ключом может их расшифровать.
Такие системы называют криптографией с открытым ключом (иногда названия, которые выбирают инженеры, возможно, слишком очевидны), или асимметричной криптографией. В криптографии с открытым ключом открытый ключ часто "выпускается на волю"; это то, что может найти любой, у кого есть доступ к ключевому серверу или другому источнику.
Альтернативой криптографии с открытым ключом является криптография с симметричным ключом. В криптографии с симметричным ключом отправитель и получатель используют один ключ, который используется как для шифрования, так и для расшифровки данных (общий секрет). Учитывая, что общие секреты (очевидно) сложно создавать и использовать, почему вообще используется криптография с симметричным ключом? При выборе между симметричной криптографией и криптографией с открытым / закрытым ключом необходимо учитывать два основных компромисса:
Сложность обработки: системы криптографии с открытым ключом обычно требуют гораздо большей вычислительной мощности для шифрования и расшифровки передаваемых данных. Системы с симметричными ключами, как правило, намного проще разрабатывать и развертывать, не требуя больших вычислительных мощностей и времени. Из-за этого криптография с открытым ключом часто используется для шифрования очень небольших объемов данных, таких как закрытый ключ.
Безопасность: криптография с открытым ключом обычно требует отчасти уникального набора механизмов математического преобразования. Системы с симметричным ключом, как правило, имеют более широкий диапазон доступных преобразований, которые также являются более сложными и, следовательно, более безопасными (они обеспечивают большую случайность на выходе и, следовательно, их труднее взломать).
С учетом этих компромиссов и реальных требований есть место для обоих типов систем.
В связи с проблемами безопасности в протоколе TLSv1.0 организации PCI (индустрия платежных карт) и BSI предложили внедрить и включить протоколы TLSv1.1 или TLSv1.2, а, также, как можно скорее отойти от использования TLSv1.0. В этой статье мы представляем текущее состояние этой реализации в соответствующих продуктах VMware.
Отказ от ответственности
1.Некоторые продукты или более старые версии некоторых продуктов могут отсутствовать в этом списке, поскольку, либо нет планов реализации более новых протоколов TLS, либо изменения TLS не применимы. Возможно, эти продукты уже достигли или приближаются к истечению срока действия (EOA) или концу срока службы (EOS).
Резолюция
С точки зрения реализации, включение протоколов TLSv1.1/1.2 всегда выполняется по умолчанию, в то время как отключение TLSv1.0 могло быть либо по умолчанию (отключено по умолчанию), либо через параметр (может быть отключено через параметр).
По умолчанию компания VMware стремится к взаимодействию всех продуктов по самым высокоуровневым стандартам, доступным в программах и между ними.
Замечание: Для обратного рассмотрения обеспечения совместимости и интероперабельности в некоторых продуктах, хотя отключение TLSv1.0 и реализовано по умолчанию, есть возможность вернуть это изменение. По мере необходимости, ознакомьтесь с прилагаемой документацией, чтобы узнать подробности.
Программы и их статус перечислены в 3-х таблицах ниже.
Программы, в которых обе реализации, включение TLSv1.1/1.2 и отключение TLSv1.0 - реализованы.
Программы, для которых завершена только реализация TLSv1.1/1.2, но ожидается отключение TLSv1.0.
Программы, в которых обе реализации, включение TLSv1.1/1.2 и отключение TLSv1.0, ожидают разработки.
Примечания
Версия с отключением протокола TLSv.1.0 является его первым релизом, во всех последующих релизах эта функция будет отключена по умолчанию.
Версия с включенным по умолчанию протоколом TLSv1.1/1.2 является его первым релизом, во всех последующих релизах эта опция будет отключена по умолчанию.
Программы, в которых обе реализации, включение TLSv1.1/1.2 и отключение TLSv1.0, завершены
Продукт
Включение (всегда по умолчанию) TLSv1.1/1.2 Версия
Отключение TLSv1.0 - версия
Отключение TLSv1.0 - тип реализации
Документация
VMware Platform Services Controller (External) 6.xVMware Platform Services Controller Appliance (External) 6.x
6.7
6.7
По умолчанию
Managing TLS Protocol Configuration with the TLS Configurator UtilityRelease Notes for Platform Services Controller 6.7
6.5
6.5
Через параметр
Managing TLS protocol configuration for vSphere 6.5 (2147469)Release Notes for Platform Services Controller 6.5
6.0 Update 3
6.0 Update 3
Через параметр
Managing TLS protocol configuration for vSphere 6.0 Update 3 (2148819)
Release Notes for vCenter Server 6.0 U3
VMware Identity Manager 2.x
2.6
2.6
По умолчанию
Enabling TLS 1.0 protocol in VMware Identity Manager 2.6 (2144805)Release Notes for VMware Identity Manager 2.6
VMware Integrated OpenStack 3.x
3.0
3.0
Через параметр
Release Notes for VMware Integrated OpenStack 3.0
VMware vCloud Director for Service Providers 8.x
8.10
8.10
Через параметр
Managing the List of Allowed SSL Protocols in the vCloud Director Administrator's GuideRelease Notes for VMware vCloud Director for Service Providers 8.10
VMware vCloud Availability for vCloud Director 1.x
1.0.1
1.0.1
Через параметр
Configuring vCloud Director for Installation in the vvCloud Availability for vCloud Director Installation and Configuration GuideRelease Notes for vCloud Availability for vCloud Director 1.0.1
VMware vCloud Usage Meter 3.5
3.5
3.5
По умолчанию
Release Notes for VMware vCloud Usage Meter 3.5
VMware vCloud Usage Meter 3.6
3.6
3.6
По умолчанию
Release Notes for VMware vCloud Usage Meter 3.6
VMware vCloud Air Hybrid Cloud Manager 2.x
2.0
2.0
Через параметр
Hybrid Cloud Manager Security Protocol (2146900)Release Notes for VMware vCloud Air Hybrid Cloud Manager 2.0
VMware vRealize Business Advanced and Enterprise 8.x
8.2.4
8.2.4
По умолчанию
Release Notes for vRealize Business Advanced and Enterprise 8.2.4
VMware vRealize Business Standard for Cloud 7.x
7.1.0
7.1.0
По умолчанию
Enable or Disable TLS in the vRealize Business for Cloud Install GuideRelease Notes for vRealize Business Standard for Cloud 7.1.0
VMware vRealize Configuration Manager 5.x
5.8.2
5.8.3
По умолчанию
Release Notes for VMware vRealize Configuration Manager 5.8.3Release Notes for VMware vRealize Configuration Manager 5.8.2
VMware NSX for vSphere 6.xIncludes: Manager, Controller, Endpoint, Edge.
6.2.4
6.2.4
Через параметр
Disabling Transport Layer Security (TLS) 1.0 on NSX (2145749)Release Notes for VMware NSX for vSphere 6.2.4
VMware vCenter Server 6.xVMware vCenter Server Appliance 6.x
6.7
6.7
По умолчанию
Managing TLS Protocol Configuration with the TLS Configurator UtilityRelease Notes for vCenter Server 6.7
6.5
6.5
Через параметр
Managing TLS protocol configuration for vSphere 6.5 (2147469)Release Notes for vCenter Server 6.5
6.0 Update 3
6.0 Update 3
Через параметр
Managing TLS protocol configuration for vSphere 6.0 Update 3 (2148819)
Release Notes for vCenter Server 6.0 U3
vCenter Server Heartbeat 6.6.x
6.6 Update 2
6.6 Update 2
Через параметр
Configuring VMware vCenter Server Heartbeat to use only TLS2v1.1 and TLSv1.2 (2146352)Release Notes for vCenter Server Heartbeat 6.6 Update 2
VMware vRealize Automation 7.x
7.0.1
7.1.0
Через параметр
Disabling TLS 1.0 in vRealize Automation (2146570)Release Notes for VMware vRealize Automation 7.1.0Release Notes for VMware vRealize Automation 7.0.1
VMware vRealize Orchestrator 7.x
7.0.0
7.0.1
По умолчанию
Enable SSLv3 and TLSv1 for outgoing HTTPS connections in vRealize Orchestrator 6.0.4 and 7.0.x manually (2144318)Release Notes for vRealize Orchestrator 7.0.0Release Notes for vRealize Orchestrator 7.0.1
VMware vSphere Update Manager 6.x
6.5
6.5
Через параметр
Managing TLS protocol configuration for vSphere 6.5 (2147469)Release Notes for vSphere Update Manager 6.5
6.0 Update 3
6.0 Update 3
Через параметр
Configuring the TLS protocol for Update Manager 6.0 Update 3 (2149136)
Release Notes for vSphere Update manager 6.0 U3
VMware vRealize Infrastructure Navigator 5.8.x
5.8.5
5.8.5
Через параметр
Disabling TLSv1 Support in vRealize Infrastructure Navigator (2139941)Release Notes for vRealize Infrastructure Navigator 5.8.5
VMware vCenter Support Assistant 6.x
6.0.2
6.0.2
По умолчанию
TLS protocol configuration options for vCenter Support Assistant (2146079)Release Notes for vCenter Support Assistant 6.0.2
VMware vRealize Operations 6.2.x
6.2.0
6.2.x
Через параметр
Disable TLS 1.0 in vRealize Operations Manager 6.2 (2138007)Release Notes for vRealize Operations Manager 6.2.0
VMware vRealize Operations Management pack for MEDITECH 1.0
6.2.0
6.2.x
Через параметр
Disable TLS 1.0 in vRealize Operations Manager 6.2 (2138007)Release Notes for vRealize Operations Manager 6.2.0
VMware vRealize Operations Management pack for Epic 1.0
6.2.0
6.2.x
Через параметр
Disable TLS 1.0 in vRealize Operations Manager 6.2 (2138007)Release Notes for vRealize Operations Manager 6.2.0
VMware vRealize Operations Management pack for Published Applications 6.x
6.1.1
6.1.1
По умолчанию
Release Notes for VMware vRealize Operations for Published Applications 6.1.1
VMware vRealize Hyperic 5.x
5.8.6
5.8.6
По умолчанию
Release Notes for vRealize Hyperic 5.8.6
VMware vRealize Log Insight 4.x
4.0
4.0
Через параметр
How to disable TLS 1.0 in vRealize Log Insight (2146305)Release Note for vRealize Log Insight 4.0
VMware vRealize Log Insight 3.x
3.0
3.0
Через параметр
Log Insight 2.5 and 3.0 cannot establish connection to remote TLSv1.1 or TLSv1.2 servers (2144162)How to disable TLS 1.0 in vRealize Log Insight (2146305)Release Note for vRealize Log Insight 3.6Release Note for vRealize Log Insight 3.3Release Note for vRealize Log Insight 3.0
VMware Site Recovery Manager 6.x
6.5
6.5
По умолчанию
Release Notes for Site Recovery Manager 6.5
6.1
6.1.1
Через параметр
TLS Configuration Options For Site Recovery Manager 6.1.1 (2145910)Release Notes for Site Recovery Manager 6.1Release Notes for Site Recovery Manager 6.1.1
VMware vSphere Replication 6.x
6.5
6.5
По умолчанию
Release Notes for vSphere Replication 6.5
6.1.1
6.1.1
Через параметр
TLS protocol configuration options for vSphere Replication 6.1.1 (2145893)Release Notes for vSphere Replication 6.1.1
VMware ESXi 6.x
6.7
6.7
Через параметр
Managing TLS Protocol Configuration with the TLS Configurator UtilityRelease Notes for vSphere ESXi 6.7
6.5
6.5
Через параметр
Managing TLS protocol configuration for vSphere 6.5 (2147469)Release Notes for vSphere ESXi 6.5
6.0 Update 3
6.0 Update 3
Через параметр
Managing TLS protocol configuration for vSphere 6.0 Update 3 (2148819)
Release Notes for vSphere ESXi 6.0 U3
VMware Tools 10.x
10.0.0
10.1.0
По умолчанию
Release Note for VMware Tools 10.1.0Release Note for VMware Tools 10.0.12Note: TLSv1.2 is leveraged for internal communications only as VMware Tools does not use SSL based communication to other components.
VMware vSAN 6.x
6.7
6.7
Через параметр
Release Notes for VMware vSAN 6.7
6.6
6.6
Через параметр
Release Notes for VMware vSAN 6.6
6.5
6.5
Через параметр
Managing TLS protocol configuration for vSphere 6.5 (2147469)Release Notes for VMware vSAN 6.5
6.2
6.2
Через параметр
Release Notes for VMware vSAN 6.2
VMware AppVolumes 2.x
2.11.0
2.11.0
Через параметр
Release Notes for VMware App Volumes 2.11.0Patch required
VMware AppVolumes 3.x
3.0
3.0
По умолчанию
VMware AppVolumes 3.0 Installation and Administration GuideRelease Notes for VMware App Volumes 3.0
VMware vRealize Code Stream 2.x
2.1.0
2.1.0
Через параметр
Disabling TLS 1.0 in vRealize Automation (2146570)Release Notes for VMware vRealize Code Stream 2.1
VMware Remote Console 8.x
8.0
8.0
По умолчанию
Release Notes for VMware Remote Console 8.0
VMware vFabric tc Server 2.9.x
2.9.13
2.9.13
Через параметр
Release Notes for vFabric tc Server 2.9
VMware Horizon for Linux 6.2.x
6.2.1
6.2.1
По умолчанию
Setting Options in Configuration Files on Linux Desktop in the Horizon 6 Version 6.2 GuideRelease Notes for VMware Horizon 6 version 6.2.1
VMware Horizon Client 4.x
4.0.1
4.0.1
Через параметр
Configure Advanced TLS/SSL Options in the VMware Horizon Client Admin Guide for iOSConfigure Advanced TLS/SSL Options in the VMware Horizon Client Admin Guide for AndroidConfigure Advanced TLS/SSL Options in the VMware Horizon Client Admin Guide for Mac OS XConfigure Advanced TLS/SSL Options in the VMware Horizon Client Admin Guide for LinuxConfigure Advanced TLS/SSL Options in the VMware Horizon Client Admin Guide for WindowsRelease Notes for VMware Horizon Client 4.1 for iOSRelease Notes for VMware Horizon Client 4.1 for AndroidRelease Notes for VMware Horizon Client 4.1 for Mac OS XRelease Notes for VMware Horizon Client 4.1 for LinuxRelease Notes for VMware Horizon Client 4.1 for Windows
VMware Horizon View 7.x
7.0
7.0
По умолчанию
Configuring security protocols on components to connect the View Client with desktops (2130798)Release Notes for VMware Horizon View 7.0
VMware Horizon View 6.x
6.2.1
6.2.1
По умолчанию
Configuring security protocols on components to connect the View Client with desktops (2130798)Release Notes for VMware Horizon View 6.2.1
VMware Horizon Air 16.x
16.6.0
16.6.0
Через параметр
Disabling TLS 1.0 in Horizon Air Appliances (2146781)Release Notes for VMware Horizon Air 16.6
Horizon Daas 7.0
7.0.0
7.0.0
По умолчанию
Release Notes for VMware Horizon DaaS 7.0
VMware Mirage
5.7
5.7
Через параметр
Disabling TLS 1.0 on Windows systems (2145606)Release Notes for VMware Mirage 5.7
VMware Horizon Air Hybrid-mode 1.x
1.0
1.0
По умолчанию
Change the Security Protocols and Cipher Suites Used for TLS or SSL Communication in VMware Horizon Air Hybrid-Mode 1.0 Administration GuideConfiguration Settings for System Settings and Server Certificates in VMware Horizon Air Hybrid-Mode 1.0 Administration GuideRelease Notes for VMware Horizon Air Hybrid-mode 1.0
VMware Software Manager - Download Server
1.3
1.3
По умолчанию
Enable SSLv3 or TLSv1 in the VMware Software Manager - Download Service User Guide.Release Notes for VMware Software Manager 1.3
VMware Photon OS
1.0
1.0
Через параметр
Disabling TLS 1.0 to Improve Transport Layer Security in the Photon OS Administration Guide
VMware Continuent 5.xIncludes: Analytics and Big Data, Cluster, Disaster Recovery, Replication
5.0
5.0
По умолчанию
Release Notes for VMware Software Manager 5.0
VMware vSphere Big Data Extension 2.3.x
2.3.2
2.3.2
Через параметр
Release Notes for vSphere Big Data Extension 2.3
NSX-T
1.1
1.1
По умолчанию
Release Notes for NSX-T 1.1
vCenter Chargeback Manager
2.7.2
2.7.1
По умолчанию
Release Notes for Chargeback Manager 2.7.2
VMware Network Insight 3.x
3.3
3.3
По умолчанию
Release Notes for VMware Network Insight 3.3
Продукты, для которых завершена только реализация TLSv1.1/1.2, но ожидается отключение TLSv1.0
По мере выпуска софта с обеими реализациями они будут перемещаться из этого раздела в верхнюю таблицу; однако, программы и их доступность могут изменяться и оставаться в этой таблице.
Продукт
Включение (всегда по умолчанию) TLSv 1.1/1.2 Версия
Отключение TLSv1.0 Плановая версия
Документация
VMware vCenter Converter Standalone 6.x
6.1.1
(Ожидающий)
VMware vCenter Converter Standalone User's Guide (Страница 40)Release Notes for VMware vCenter Converter Standalone 6.1.1
VMware Fusion 8.x
8.0.0
(Ожидающий)
Release Notes for VMware Fusion 8
VMware Workstation Pro/Player 12.x
12.0.0
(Ожидающий)
Release Notes for VMware Workstation 12 ProRelease Notes for VMware Workstation 12 Player
VMware vSphere Data Protection 6.1.x
6.14
(Ожидающий)
Release Notes for Data Protection 6.1.4
Продукты, в которых обе реализации, включение TLSv1.1/1.2 и отключение TLSv1.0, ожидают обработки
По мере выпуска софта с обеими реализациями они будут перемещаться из этого раздела в верхнюю таблицу; однако, программы и их доступность могут изменяться и оставаться в этой таблице.
Продукт
Включение (всегда по умолчанию) TLSv 1.1/1.2 Плановая версия
Отключение TLSv1.0 Плановая версия
Документация
VMware Photon Controller 1.x
(Ожидающий)
(Ожидающий)
(Ожидающий)
Эта статья подробно объясняет функции и терминологию протокола RIP (административное расстояние, метрики маршрутизации, обновления, пассивный интерфейс и т.д.) с примерами.
RIP - это протокол маршрутизации вектора расстояния. Он делится информацией о маршруте через локальную трансляцию каждые 30 секунд.
Маршрутизаторы хранят в таблице маршрутизации только одну информацию о маршруте для одного пункта назначения. Маршрутизаторы используют значение AD и метрику для выбора маршрута.
Первая часть статьи про базовые принципы работы протокола RIP доступна по ссылке.
Административная дистанция
В сложной сети может быть одновременно запущено несколько протоколов маршрутизации. Различные протоколы маршрутизации используют различные метрики для расчета наилучшего пути для назначения. В этом случае маршрутизатор может получать различную информацию о маршрутах для одной целевой сети. Маршрутизаторы используют значение AD для выбора наилучшего пути среди этих маршрутов. Более низкое значение объявления имеет большую надежность.
Административная дистанция
Протокол/Источник
0
Непосредственно подключенный интерфейс
0 или 1
Статическая маршрутизация
90
EIGRP
110
OSPF
120
RIP
255
Неизвестный источник
Давайте разберемся в этом на простом примере: А маршрутизатор изучает два разных пути для сети 20.0.0.0/8 из RIP и OSPF. Какой из них он должен выбрать?
Ответ на этот вопрос скрыт в приведенной выше таблице. Проверьте объявленную ценность обоих протоколов. Административное расстояние - это правдоподобие протоколов маршрутизации. Маршрутизаторы измеряют каждый источник маршрута в масштабе от 0 до 255. 0 - это лучший маршрут, а 255-худший маршрут. Маршрутизатор никогда не будет использовать маршрут, изученный этим (255) источником. В нашем вопросе у нас есть два протокола RIP и OSPF, и OSPF имеет меньшее значение AD, чем RIP. Таким образом, его маршрут будет выбран для таблицы маршрутизации.
Метрики маршрутизации
У нас может быть несколько линий связи до целевой сети. В этой ситуации маршрутизатор может изучить несколько маршрутов, формирующих один и тот же протокол маршрутизации. Например, в следующей сети у нас есть два маршрута между ПК-1 и ПК-2.
Маршрут 1:
ПК-1 [10.0.0.0/8] == Маршрутизатор OFF1 [S0/1 - 192.168.1.254] = = Маршрутизатор OFF3 [S0/1-192.168.1.253] = = ПК-2 [20.0.0.0/8]
Маршрут 2:
ПК-1 [10.0.0.0/8] == Маршрутизатор OFF1 [S0/0 - 192.168.1.249] == Маршрутизатор OFF2 [S0/0 - 192.168.1.250] == Маршрутизатор OFF2 [S0/1 - 192.168.1.246] == Маршрутизатор OFF3 [S0/0 - 192.168.1.245] == ПК-2 [20.0.0.0/8]
В этой ситуации маршрутизатор использует метрику для выбора наилучшего пути. Метрика - это измерение, которое используется для выбора наилучшего пути из нескольких путей, изученных протоколом маршрутизации. RIP использует счетчик прыжков в качестве метрики для определения наилучшего пути. Прыжки - это количество устройств уровня 3, которые пакет пересек до достижения пункта назначения.
RIP (Routing Information Protocol) - это протокол маршрутизации вектора расстояния. Он использует расстояние [накопленное значение метрики] и направление [вектор], чтобы найти и выбрать лучший путь для целевой сети. Мы объяснили этот процесс с помощью примера в нашей первой части этой статьи.
Хорошо, теперь поймите концепцию метрики; скажите мне, какой маршрут будет использовать OFF1, чтобы достичь сети 20.0.0.0/8? Если он выбирает маршрут S0/1 [192.168.1.245/30], он должен пересечь устройство 3 уровня. Если он выбирает маршрут S0/0 [19.168.1.254/30], то ему придется пересечь два устройства уровня 3 [маршрутизатор OFF! и последний маршрутизатор OFF3], чтобы достичь целевой сети.
Таким образом, он будет использовать первый маршрут, чтобы достигнуть сети 20.0.0.0/8.
Маршрутизация по слухам
Иногда RIP также известен как маршрутизация по протоколу слухов. Потому что он изучает информацию о маршрутизации от непосредственно подключенных соседей и предполагает, что эти соседи могли изучить информацию у своих соседей.
Обновления объявлений
RIP периодически транслирует информацию о маршрутизации со всех своих портов. Он использует локальную трансляцию с IP-адресом назначения 255.255.255.255. Во время вещания ему все равно, кто слушает эти передачи или нет. Он не использует никакого механизма для проверки слушателя. RIP предполагает, что, если какой-либо сосед пропустил какое-либо обновление, он узнает об этом из следующего обновления или от любого другого соседа.
Пассивный интерфейс
По умолчанию RIP транслирует со всех интерфейсов. RIP позволяет нам контролировать это поведение. Мы можем настроить, какой интерфейс должен отправлять широковещательную передачу RIP, а какой нет. Как только мы пометим любой интерфейс как пассивный, RIP перестанет отправлять обновления из этого интерфейса.
Расщепление горизонта
Split horizon-это механизм, который утверждает, что, если маршрутизатор получает обновление для маршрута на любом интерфейсе, он не будет передавать ту же информацию о маршруте обратно маршрутизатору-отправителю на том же порту. Разделенный горизонт используется для того, чтобы избежать циклов маршрутизации.
Чтобы понять эту функцию более четко, давайте рассмотрим пример. Следующая сеть использует протокол RIP. OFF1-это объявление сети 10.0.0.0/8. OFF2 получает эту информацию по порту S0/0.
Как только OFF2 узнает о сети 10.0.0.0/8, он включит ее в свое следующее обновление маршрутизации. Без разделения горизонта он будет объявлять эту информацию о маршруте обратно в OFF1 на порту S0/0.
Ну а OFF1 не будет помещать этот маршрут в таблицу маршрутизации, потому что он имеет более высокое значение расстояния. Но в то же время он не будет игнорировать это обновление. Он будет предполагать, что OFF1 знает отдельный маршрут для достижения сети 10.0.0.0/8, но этот маршрут имеет более высокое значение расстояния, чем маршрут, который я знаю. Поэтому я не буду использовать этот маршрут для достижения 10.0.0.0/8, пока мой маршрут работает. Но я могу воспользоваться этим маршрутом, если мой маршрут будет недоступен. Так что это может сработать как запасной маршрут для меня.
Это предположение создает серьезную сетевую проблему. Например, что произойдет, если интерфейс F0/1 OFF1 выйдет из строя? OFF1 имеет прямое соединение с 10.0.0.0/8, поэтому он сразу же узнает об этом изменении.
В этой ситуации, если OFF1 получает пакет для 10.0.0.0/8, вместо того чтобы отбросить этот пакет, он переадресует его из S0/0 в OFF2. Потому что OFF1 думает, что у OFF2 есть альтернативный маршрут для достижения 10.0.0.0/8.
OFF2 вернет этот пакет обратно в OFF1. Потому что OFF2 думает, что у OFF1 есть маршрут для достижения 10.0.0.0/8.
Это создаст сетевой цикл, в котором фактический маршрут будет отключен, но OFF1 думает, что у OFF2 есть маршрут для назначения, в то время как OFF2 думает, что у OFF1 есть способ добраться до места назначения. Таким образом, этот пакет будет бесконечно блуждать между OFF1 и OFF2. Чтобы предотвратить эту проблему, RIP использует механизм подсчета прыжков (маршрутизаторов).
Количество прыжков
RIP подсчитывает каждый переход (маршрутизатор), который пакет пересек, чтобы добраться до места назначения. Он ограничивает количество прыжков до 15. RIP использует TTL пакета для отслеживания количества переходов. Для каждого прыжка RIP уменьшает значение TTL на 1. Если это значение достигает 0, то пакет будет отброшен.
Это решение только предотвращает попадание пакета в петлю. Это не решает проблему цикла маршрутизации.
Split horizon решает эту проблему. Если расщепление горизонта включено, маршрутизатор никогда не будет вещать тот же маршрут обратно к отправителю. В нашей сети OFF2 узнал информацию о сети 10.0.0.0/8 от OFF1 на S0/0, поэтому он никогда не будет транслировать информацию о сети 10.0.0.0/8 обратно в OFF1 на S0/0.
Это решает нашу проблему. Если интерфейс F0/1 OFF1 не работает, и OFF1, и OFF2 поймут, что нет никакого альтернативного маршрута для достижения в сети 10.0.0.0/8.
Маршрут отравления
Маршрут отравления работает противоположном режиме расщепления горизонта. Когда маршрутизатор замечает, что какой-либо из его непосредственно подключенных маршрутов вышел из строя, он отравляет этот маршрут. По умолчанию пакет может путешествовать только 15 прыжков RIP. Любой маршрут за пределами 15 прыжков является недопустимым маршрутом для RIP. В маршруте, находящимся в неисправном состоянии, RIP присваивает значение выше 15 к конкретному маршруту. Эта процедура известна как маршрутное отравление. Отравленный маршрут будет транслироваться со всех активных интерфейсов. Принимающий сосед будет игнорировать правило разделения горизонта, передавая тот же отравленный маршрут обратно отправителю. Этот процесс гарантирует, что каждый маршрутизатор обновит информацию об отравленном маршруте.
Таймеры RIP
Для лучшей оптимизации сети RIP использует четыре типа таймеров.
Таймер удержания (Hold down timer) - RIP использует удерживающий таймер, чтобы дать маршрутизаторам достаточно времени для распространения отравленной информации о маршруте в сети. Когда маршрутизатор получает отравленный маршрут, он замораживает этот маршрут в своей таблице маршрутизации на период таймера удержания. В течение этого периода маршрутизатор не будет использовать этот маршрут для маршрутизации. Период удержания будет прерван только в том случае, если маршрутизатор получит обновление с той же или лучшей информацией для маршрута. Значение таймера удержания по умолчанию составляет 180 секунд.
Route Invalid Timer - этот таймер используется для отслеживания обнаруженных маршрутов. Если маршрутизатор не получит обновление для маршрута в течение 180 секунд, он отметит этот маршрут как недопустимый маршрут и передаст обновление всем соседям, сообщив им, что маршрут недействителен.
Route Flush Timer - этот таймер используется для установки интервала для маршрута, который становится недействительным, и его удаления из таблицы маршрутизации. Перед удалением недопустимого маршрута из таблицы маршрутизации он должен обновить соседние маршрутизаторы о недопустимом маршруте. Этот таймер дает достаточно времени для обновления соседей, прежде чем недопустимый маршрут будет удален из таблицы маршрутизации. Таймер Route Flush Timer по умолчанию установлен на 240 секунд.
Update Timer -В RIP широковещательная маршрутизация обновляется каждые 30 секунд. Он будет делать это постоянно, независимо от того, изменяется ли что-то в маршрутной информации или нет. По истечении 30 секунд маршрутизатор, работающий под управлением RIP, будет транслировать свою информацию о маршрутизации со всех своих интерфейсов.
RIP - это самый старый протокол вектора расстояний. Для удовлетворения текущих требований к сети он был обновлен с помощью RIPv2. RIPv2 также является протоколом вектора расстояния с максимальным количеством прыжков 15.
Вы все еще можете использовать RIPv1, но это не рекомендуется. В следующей таблице перечислены ключевые различия между RIPv1 и RIPv2.
Основные различия между RIPv1 и RIPv2
RIPv1
RIPv2
Он использует широковещательную передачу для обновления маршрутизации.
Он использует многоадресную рассылку для обновления маршрутизации.
Он посылает широковещательный пакет по адресу назначения 255.255.255.255.
Он отправляет многоадресную рассылку по адресу назначения 224.0.0.9.
Он не поддерживает VLSM.
Он поддерживает VLSM.
Он не поддерживает никакой аутентификации.
Он поддерживает аутентификацию MD5
Он поддерживает только классовую маршрутизацию.
Он поддерживает как классовую, так и бесклассовую маршрутизацию.
Он не поддерживает непрерывную сеть.
Он поддерживает непрерывную сеть.