Включение tls 1.2 на серверах сайта и удаленных системах сайтаhow to enable tls 1.2 on the site servers and remote site systems

FTPS

FTPS (FTP + SSL) – расширение стандартного протокола передачи файлов, добавляющее в его базовый функционал создание шифрованных сессий с помощью протокола SSL (Secure Sockets Layer — уровень защищенных сокетов). На сегодняшний день защита обеспечивается его более продвинутым аналогом TLS (Transport Layer Security — защита транспортного уровня).

SSL

Протокол SSL предложен корпорацией Netscape Communications в 1996 году с целью обеспечения безопасности и секретности интернет-соединений. Протокол поддерживает аутентификацию (установление подлинности) клиента и сервера, не зависит от приложений и прозрачен для протоколов HTTP, FTP и Telnet.

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

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

SSL поддерживает разнообразные криптографические алгоритмы. В ходе установления связи используется криптосистема открытого ключа RSA. После обмена ключами используется много разных шифров: RC2, RC4, IDEA, DES и TripleDES. Также используется MD5 — алгоритм создания дайджеста сообщений. Синтаксис сертификатов открытого ключа описан в X.509.

Одним из немаловажных преимуществ SSL, является его полная программно-платформенная независимость. Протокол разработан на принципах переносимости, и идеология его построения, не зависит, от тех приложений, в составе которых он используется

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

SSL-подключение

Предоставляемый SSL безопасный канал обладает тремя основными свойствами:

• Канал является частным. Шифрование используется для всех сообщений после простого диалога, который служит для определения секретного ключа.
• Канал аутентифицирован. Серверная сторона диалога всегда аутентифицируется, в то время как клиентская — аутентифицируется опционально.
• Канал надежен. Транспортировка сообщений включает в себя проверку целостности (с привлечением MAC).

Особенности FTPS

Существуют две реализации FTPS, использующие различные методы предоставления безопасности:

• Неявный метод предполагает использование стандартного протокола SSL с установлением сессии перед отправкой данных, что, в свою очередь, нарушает совместимость с обычным FTP клиентами и серверами. Для обратной совместимости с клиентами, которые не поддерживают FTPS, для контрольного соединения используется TCP-порт 990, а для передачи данных — 989. Это позволяет сохранить стандартный порт 21 для протокола FTP. Данный метод признан устаревшим.
• Явный – намного более удобен, так как использует команды стандартного FTP, но при ответе шифрует данные, что позволяет использовать одно и тоже управляющее соединение как для FTP, так и для FTPS. Клиент должен явно запросить защищенную передачу данных у сервера, а после утвердить способ шифрования. Если клиент не запросит защищенную передачу, FTPS сервер вправе как сохранить, так и закрыть незащищенное соединение. Механизм согласования идентификации и защиты данных был добавлен под RFC 2228 который включает в себя новую FTP команду AUTH. Хотя этот стандарт не определяет явно механизмы защиты, он определяет, что защищенное соединение должен инициировать клиент с помощью описанного выше алгоритма. Если защищенные соединения не поддерживаются сервером, должен быть возвращен код ошибки 504. FTPS клиенты могут получить информацию о поддерживаемых сервером протоколах защиты при помощи команды FEAT, тем не менее сервер не обязан разглашать то, какие уровни безопасности он поддерживает. Наиболее распространены FTPS команды AUTH TLS и AUTH SSL, обеспечивающие защиту TLS и SSL соответственно.

Как установить SSL-сертификат на сайт WordPress

Установка SSL на Вордпресс происходит в несколько этапов:

1. приобретение SSL-сертификата;
2. подключение HTTPS-протокола;
3. переход на HTTPS.

1. Покупка SSL

Первый этап установки заключается в выборе и покупке SSL-сертификата. Рекомендуем познакомиться со статьёй: Как правильно выбрать SSL-сертификат

Обратите внимание на предложение REG.RU: при регистрации домена и заказе хостинга вы можете подключить бесплатный сертификат на один год

SSL должен быть выпущен для нужного домена. После того как сертификат будет выпущен, перейдите к следующему этапу установки SSL на CMS.

2. Подключение HTTPS

Второй этап — настройка HTTPS-протокола. Без него страницу нельзя будет считать безопасной. Если ресурс, на который вы хотите установить SSL, работал по незащищённому HTTP-протоколу, вам нужно перевести его на HTTPS. Для этого:

Перейдите в раздел «Настройки» и выберите пункт Общие:

В двух выделенных строках измените http на https перед именем домена и внизу страницы нажмите Сохранить изменения:

3. Переезд на HTTPS

Затем осуществите переход на HTTPS в WordPress, чтобы пользователи, которые добавили в закладки вашу страницу с http, перейдя по старой ссылке, попали на ресурс с https. Без этого перехода (редиректа) Интернет не поймёт, что это один и тот же ресурс. Кроме того, редирект позволит не потерять SEO-позиции.

Вы можете настроить редирект двумя способами:

• в конфигурационном файле .htaccess на хостинге;
• с помощью плагина в Вордпресс.

Настройка редиректа с http на https в файле .htaccess описана в инструкции: Редирект с http на https для Linux. Мы рекомендуем более простой способ — плагин Really Simple SSL. Помимо этого плагина вы можете использовать и другие приложения: WP Force SSL, Easy HTTPS Redirection и пр.

Чтобы настроить редирект с помощью плагина Really Simple SSL:

Перейдите в раздел Плагины. Нажмите кнопку Добавить новый и введите в строке поиска «really simple ssl». Затем нажмите Установить:

Нажмите Активировать:

После активации плагина нажмите отмеченную кнопку:

Готово! Теперь ваш сайт надёжно защищён. Если вы хотите подкорректировать действие плагина, перейдите на его страницу и нажмите Настройки.

После выполнения этих действий ресурс будет обладать сертификатом SSL и работать по защищённому протоколу HTTPS. Это позволит посетителям не беспокоиться о сохранности своих данных при работе с вашим сайтом.

Доверьте хостинг профессионалам. Быстрая работа и круглосуточная техническая поддержка.

www.reg.ru

Закручиваем гайки: настройки криптоалгоритмов на хосте

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

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

Как через групповую политику изменить список поддерживаемых SSL/TLS криптоалгоритмов

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

1. Скопируйте в Блокнот все cipher suites, которые там есть.
2. Удалите те, которые включают в себя согласование нестойких алгоритмов и методов (например, RC2, RC4, DES, MD5 и прочее. всякие ужасы вида TLS_RSA_WITH_NULL_MD5 Вам же не нужны, правда?).
3. Превратите список в одну большую строку, которая состоит из cipher suites, разделённых запятыми, и не содержит больше ничего. Пробелов тоже.
4. Вставьте эту строку в окно данной настройки групповой политики.

Учтите, что не всё, что поддерживается системой, присутствует в этом списке. И наоборот – данный список не прикажет системе начать поддерживать неизвестные ей криптоалгоритмы. Например, если у Вас есть системы на Windows XP / Windows Server 2003, убедитесь, что на них установлено обновление KB 948963, которое добавляет поддержку AES-128 и AES-256, необходимых для TLS.

А вот как можно изменить этот список через реестр.

Как через реестр изменить список поддерживаемых SSL/TLS криптоалгоритмов

Откройте редактор реестра. Ваша задача – ключи вида:

где идентификатор алгоритма – это, например, RC4, а размерность ключа – например, 128. Понятное дело, что данных комбинаций фиксированное число, поэтому для отключения всех из них в явном виде надо забежать в MSDN и найти эти комбинации. Например, для старых симметричных алгоритмов семейства RCx это будут:

• RC4 128/128
• RC2 128/128
• RC4 64/128
• RC4 56/128
• RC2 56/128
• RC4 40/128
• RC2 40/128

Во всех этих ключах надо будет создать параметр (как обычно, DWORD32) и выставить его в нуль.

Интересным моментом является отключение возможности установить “пустой” SSL – без криптоалгоритма. Ну, типа как в PPP можно вообще без фазы авторизации, так и тут – есть такая тонкость. Чтобы эту тонкость тоже убрать, надо зайти в ключ:

и опять же создать там со значением 0x0.

Отключаем использование хэш-функции MD5 в SSL/TLS

И даже это можно. Через групповую политику нет (только вручную удалив из полного списка все suites с упоминанием MD5), а через реестр – пожалуйста.

Учтите только, что данная настройка – лидер по количеству приключений после её применения. Классика – умирающий SharePoint 2010; он использует MD5 для генерации внутренних идентификаторов безопасности, поэтому не найдя её очень страдает.

Заходим:

и отключаем аналогично – в 0x0. Заодно и MD4 можно, он в принципе может встретиться в IPSec, но если не используется в реальности – имеет смысл его отключить аналогичным способом.

Примечание: Если захотите что-нибудь из этого явно включить обратно, не стирая ключ, есть нюанс: Enabled надо будет ставить не в единицу, а в 0xFFFFFFFF.

HOW CAN I BUY TSL OUTDOOR PRODUCTS?

Where can I find TSL OUTDOOR products?You can find TSL products in a store near you.  Just have a look at our Points of Sale section.We do not sell our products on line directly.  We do however have a number of high-quality on-line partners in France who stock all of our products._Why can’t I find a TSL product on the site? The article you are looking for may be:- Simply no longer in our collection.  We are continuously working on our product range.- Part of a limited edition series developed especially for certain retailers, so is not part of our standard collection.I don’t live in France and no retailer seems to operate in my country.- You should contact the TSL distributor for your country: see the Points of Sale section to find the address of your closest retailer.- It is possible that our products are not distributed and sold in your country.

BEAST: как работает атака на SSL 2.0/3.0 и TLS 1.0

Эта достаточно нашумевшая атака (ну, благодаря прессе, у неё статус “Конец Интернета Почти Вот-Вот”), на самом деле, устроена достаточно просто.
Суть в том, что во всех протоколах до TLS 1.1 вместо генерации нового случайного IV (для каждого нового TLS message), использовался последний блок предыдущего TLS message. BEAST пользуется этим, чтобы значительно упростить процесс атаки на ключ – в частности, получив доступ к сессии, он может значительно упростить себе процедуру перебора сессионного ключа, влияя на состав нового вектора инициализации. В TLS 1.1 халтурить перестали, поэтому данная атака там просто не работает.

Если попробовать рамочно описать алгоритм атаки, можно это сделать так.

• Пользователь инициирует SSL-сессию к ресурсу (например, к веб-серверу). В этой сессии он постоянно передаёт какой-то элемент (например, жмёт на кнопку Like). Ну т.е. сессия одна, а он ходит по сайтам и делает что-то, что сопровождается хотя бы частично совпадающим обменом данными.
• Например, предположим, что согласовался протокол AES-128 (заметьте – стойкость самого протокола не критична, я его выбрал просто для удобного примера). Его блок будет равняться 128 / 8 = 16 байт.
• Атакующий участвует в обмене трафиком так, что может добавлять свои данные перед данными пользователя. Вариантов много – например, доп.заголовок в HTTP, или модификация исходных данных на уровне источника. Суть в том, чтобы атакующий мог добавить свои данные так, чтобы получился блок “Добавленные_данные_известные_атакующему + нормальные_данные_неизвестные_атакующему”. Т.е. исходное в атаке – это MITM. Если вы думаете, что условий дофига и это всё малореально, просто представьте себе обычного пользователя, который игнорирует антивирус, потому как, к примеру, верит рекламе “В нашей ОС нет вирусов, т.к. у неё красивые скруглённые уголочки да и цена намекает, что качество ну просто обязано быть”, который хочет в онлайне что-нибудь оплатить по карте и видит успокаивающую надпись “Protected by SSL 2.0/3.0 128bit cipher”.
• Атакующий начинает работать. Он вкидывает такие блоки данных в поток, чтобы последним получился блок, у которого 15 байт – добавленные данные, а единственный оставшийся – секретные. После пробует тестово расшифровывать этот блок перебором – перебирать-то интересно, т.к. из 16 байт 15 известны. А подбор 2^8 – это уже очень перспективно, учитывая, что в случае выигрыша можно будет вскрыть всю сессию (ведь никто не мешает впрок отправлять куда-нибудь полный дамп сессии, а после, в случае успеха метода, расшифровать всё целиком).
• Вскрыли 1 байт? Теперь будем подгадывать так, чтобы наших байт в блоке было 14, плюс один известный, плюс один пока что неизвестный

Бесплатные сертификаты SSL/TLS от Let’s Encrypt

Рекомендую воспользоваться сертификатами SSL/TLS от Let’s Encrypt, так как:

1. Они бесплатные;
2. Подойдут большинству проектов;
3. Установка и настройка относительно несложные, и не займут много сил и времени.

Из минусов — сертификат актуален 90 дней, поэтому настроим его обновление на автомате.

Установка Certbot

Сам гайд по установке Let’s Encrypt советует делать всё через Certbot. Сработает, если есть доступ по SSH.

Установка Certbot в Debian 8 Jessie

Помощник Certbot в выборе версии сервера

Выбираем установку

apt-get install certbot -t jessie-backports

Как настроить поддержку Backports

Пишете в консоль (добавляет дополнительный источник для пакетов):

echo "deb http://ftp.debian.org/debian jessie-backports main contrib non-free" >> /etc/apt/sources.list

Потом обновляете список пакетов:

apt-get update

и снова пробуете установить Certbot:

apt-get install certbot -t jessie-backports

Затем проверяете, как вышло

certbot --help

Установка Certbot в CentOS 7

Установка происходит так:

1. yum -y install yum-utils

2. yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional

3. yum install certbot

Универсальная инструкция по установке Certbot

1. Скачиваем Certbot:

   wget https://dl.eff.org/certbot-auto

2. Даём права на исполнение с помощью chmod

   chmod a+x certbot-auto

3. Перемещаем certbot-auto к остальным бинарным файлам, чтобы появилась возможность начинать команды с

   mv certbot-auto /usr/local/bin/certbot

4. Проверяем, что получилось:

   certbot --help

   Должы увидеть что-то подобное:

Настройка Certbot

Теперь, когда certbot установлен (а вы можете убедиться в этом, задав команду), советую заглянуть в cron-задачи

cd /etc/cron.d

В директории должен появиться файл с примерно следующим содержанием

Самая последняя строчка — это правило cron, которое будет проверять сертификаты SSL, TLS дважды в день и обновлять устаревшие. К сожалению, он не перезагружает вебсервер, поэтому Вам нужно добавить правило вручную в конец строки.

В итоге, строка будет выглядеть примерно так:

0 */12 * * * root test -x /usr/bin/certbot && perl -e 'sleep int(rand(3600))' && certbot -q renew && /etc/init.d/nginx reload

Добавили, сохраняем.

Далее, подготовка, тестирование и установка сертификата для сайта.

Подготовка и тестирование конфигурации SSL, TLS

Перед тем, как получить сертификат SSL/TLS, хорошей практикой будет протестировать правильность настройки сервера. Дело в том, что если есть проблема, которая не даст получить или обновить сертификат: центр сертификации имеет жёсткие лимиты обращений к нему (10 в час). И если есть ошибка, которую никак не удаётся выявить, то можно очень быстро упереться в лимит. Чтобы избежать этой проблемы, можно воспользоваться Staging Environment от Let’s Encrypt. — это тестовая среда, полностью имитирующая общение с центром сертификации, и выдающая недоверенные сертификаты-пустышки. Однако, она имеет повышенные лимиты обращения к ней и служит исключительно для тестирования и настройки конфигурации сервера:

• Выдача и обновление сертификата на 1 домен имеет лимит 30 000 в неделю.
• Ошибка валидации имеет лимит 60 раз в час.

Чтобы воспользоваться тестовой окружающей средой, достаточно для certbot использовать ключ .
Например, так можно протестировать выдачу сертификата:

certbot certonly --webroot -w /var/www/example.com -d example.com -d www.example.com --email  --agree-tos --staging

Кстати, посмотреть, как происходит обновление сертификатов, но без реального обновления, просто проверить правильность конфигурации, можно командой:

certbot renew --dry-run

А обновить все сертификаты на сервере вручную можно командой

certbot renew

После перезагрузите NGINX

nginx -s reload

Установка сертификата SSL, TLS от Let’s Encrypt

Вводим команду в консоль Putty:

certbot certonly --webroot -w /var/www/example.com -d example.com -d www.example.com --email  --agree-tos

• — путь до директории с файлами сайта
• — прописываем имена доменов
• — ваш email, куда можно будет восстановить доступ
• — согласие с лицензионными требованиями

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

Итак, сертификат установлен в директорию

Идём настраивать NGINX.

Инструкция по устранению ошибки

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

Если ошибка никуда не исчезла, тогда самое время опробовать альтернативные способы:

1. Отключите на какое-то время антивирусный софт. Очень часто именно антивирусы блокируют доступ к различным порталам. Деактивируйте программное обеспечение полностью или отключите проверку сертификатов (сделать это можно в меню «Настройки»).
2. Скачайте и установите на ПК последнюю версию утилиты КриптоПро. Конечно же, если ранее вы пользовались именно этой программой. Устаревшая версия может стать причиной появления проблем с безопасностью подключения.
3. Внесите коррективы в параметры браузера Internet Explorer. Откройте «Свойства браузера», а потом переключитесь на вкладку «Безопасность». Откройте раздел «Надежные сайты». Если в перечне отсутствует ваш портал, тогда обязательно добавьте его вручную. Обязательно снимите галочку напротив поля «Включить защищенный режим». Переключитесь на «Сайты», а потом снимите галочку напротив «Для всех сайтов это зоны». Согласитесь с внесенными изменениями, а потом постарайтесь подключиться заново.

надежные сайты IE

Практика показывает, что каждый из перечисленных советов может устранить проблему. Поэтому просто следуйте инструкции.

Аутентификация в рукопожатии TLS 1.2

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

С другой стороны, если Диффи-Хеллман не выполняет аутентификацию, то что он делает? Как было сказано выше, DH часто используют совместно с криптографией на основе эллиптических кривых, чтобы обеспечить аутентификацию и обмен ключами.

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

• 192 бит;
• 224 бита;
• 256 бит;
• 384 бит;
• 521 бит.

Но это не единственное различие между открытыми/закрытыми ключами ECC и ключами RSA. Они используются для двух совершенно разных целей во время рукопожатия TLS.

В RSA пара открытый/закрытый ключ используется как для проверки подлинности сервера, так и для обмена симметричным ключом сеанса. Фактически, именно успешное использование секретного ключа для расшифровки секрета (pre-master secret) аутентифицирует сервер.

С Диффи-Хеллманом пара открытый/закрытый ключ НЕ используется для обмена симметричным сеансовым ключом. Когда задействован Диффи-Хеллман, закрытый ключ фактически связан с прилагаемым алгоритмом подписи (ECDSA или RSA).

RSA-аутентификация

Процесс RSA-аутентификации связан с процессом обмена ключами. Точнее обмен ключами является частью процесса аутентификации.

Когда клиенту предоставляется SSL-сертификат сервера, он проверяет несколько показателей:

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

Если все эти проверки прошли, то проводится последний тест — клиент шифрует pre-master secret с помощью открытого ключа сервера и отправляет его. Любой сервер может попытаться выдать любой SSL/TLS-сертификат за свой. В конце концов, это общедоступные сертификаты. А так клиент может провести аутентификацию сервера, увидев закрытый ключ «в действии».

Таким образом, если сервер может расшифровать pre-master secret и использовать его для вычисления сессионного ключа, он получает доступ. Это подтверждает, что сервер является владельцем используемой пары из открытого и закрытого ключа.

DH-аутентификация

Когда используются Диффи-Хеллман и ECDSA/RSA, аутентификация и обмен ключами разворачиваются бок о бок. И это возвращает нас к ключам и вариантам их использования. Открытый/закрытый ключ RSA используется как для обмена ключами, так и для аутентификации. В DH + ECDSA/RSA асимметричная пара ключей используется только для этапа цифровой подписи или аутентификации.

Когда клиент получает сертификат, он всё ещё проводит стандартные проверки:

• проверяет подпись на сертификате,
• цепочку сертификатов,
• срок действия,
• статус отзыва.

Но владение закрытым ключом подтверждается по-другому. Во время обмена ключами TLS-рукопожатия (шаг 4) сервер использует свой закрытый ключ для шифрования случайного числа клиента и сервера, а также свой DH-параметр. Он действует как цифровая подпись сервера, и клиент может использовать связанный открытый ключ для проверки, что сервер является законным владельцем пары ключей.

GUARANTEE / CUSTOMER SERVICES

What are the guarantees on the TSL Outdoor products?TSL’s products are guaranteed against any operation defect resulting from any material, manufacturing or designing defect subject to the following provisions. This warranty applies for 2 years after the delivery of the product in accordance with article L. 211-12 of the french Consumers’ Code. Replacement parts available, 5 years. Manufacturing defects are covered subject to normal maintenance and normal use (hiking).The warranty shall not apply :- If the product has been repaired or changed by buyer or third parties appointed by either of these latter.- If it is for parts made by seller’s sub-contractors or suppliers, in which case the sub-contractor’s or supplier’s warranty applies.- If the defective operation results from negligence or imprudence on buyer’s part (example : tube breakage)- If the defective operation results from force majeure or an outside fact.

The guarantee does not cover: the parts subject to wear and tear (Example : handles, straps/gauntlets, tips), unless subject to a production defect identified by the manufacture.

When a guaranteed defect is found by the buyer, buyer should send a complaint with the proof of purchase, to the seller, by registered mail with acknowledgement of receipt within 45 days of the date on which the defect was found.Under the warranty the seller will replace any part found to be defective by his technical department, free of charge and promptly. This warranty applies in all countries regardless of the country where the product was purchased and regardless of where the damage occurs. In addition some agreements between TSL and its retailers may depart from this rule based on legislation on non-EU countries.How can I activate my guarantee?Your product is still covered by the guarantee (see above)If you bought your product from one of our retailers, you need to take it back to that shop with your proof of purchase within a maximum of two years.  The retailer will contact TSL for repairs if the product cannot by repaired in-store.Your product is no longer covered by the guaranteePlease contact our Customer Services department using our form.  We will provide you with a quote.Caring for your productsWe recommend that you dry your equipment before storing it in a completely dry place after each use.

Сравнение с аналогами

Одной из областей применения TLS-соединения является соединение узлов в виртуальной частной сети. Кроме TLS, также может использоваться набор протоколов IPSec и SSH-соединение. Каждый из этих подходов к реализации виртуальной частной сети имеет свои преимущества и недостатки.

1. TLS/SSL
   • Преимущества:
     • Невидим для протоколов более высокого уровня;
     • Популярность использования в Интернет-соединениях и приложениях электронной коммерции;
     • Отсутствие постоянного соединения между сервером и клиентом;
     • Позволяет создать туннель для приложений, использующих TCP, таких как электронная почта, инструменты программирования и т. д.
   • Недостатки:
     • Невозможность использования с протоколами UDP и ICMP;
     • Необходимость отслеживания состояния соединения;
     • Наличие дополнительных требований к программному обеспечению о поддержке TLS.
2. IPsec
   • Преимущества:
     • Безопасность и надёжность защиты данных протокола проверена и доказана, так как протокол был принят как Интернет-стандарт;
     • Работа в верхнем слое сетевого протокола и шифрование данных над уровнем сетевого протокола.
   • Недостатки:
     • Сложность реализации, создающая потенциал для уязвимостей;
     • Дополнительные требования к оборудованию сети (маршрутизаторы и т. п.);
     • Существует много различных реализаций, не всегда корректно взаимодействующих друг с другом.
3. SSH
   • Преимущества:
     • Позволяет создать туннель для приложений, использующих TCP/IP, таких как электронная почта, инструменты программирования и т. д.;
     • Слой безопасности невидим для пользователя.
   • Недостатки:
     • Трудность использования в сетях с большим числом шлюзов, таких как маршрутизаторы или брандмауэры;
     • Большая нагрузка на внутрисетевой трафик;
     • Невозможность использования с протоколами UDP и ICMP.
     • Не имеет PKI (PKI, основанная на DNSSEC, малораспространена).