Выбираем надежный VPN: TLS authentication, порт соединения и сессионный ключ.

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

Точно такая же ситуация и с портами. У VPN есть стандартные порты, которые зависят от используемого протокола:

• OpenVPN 1194 

• PPTP 1723

• IPsec 500 и 4500

Как правило, VPN-провайдеры используют стандартные порты. Это позволяет сайтам определять наличие VPN, а интернет-провайдерам и системным администраторам –блокировать его использование. 

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

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

Генерация сессионного ключа

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

Что решил Цезарь?

1. Ключ должен быть уникальным для каждого сенатора.

2. Ключ должен меняться после каждой переписки.

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

Изначально и сенатор, и Цезарь знают общий ключ – смещение букв на один символ вправо, это стандартный шифр Цезаря. Этот ключ не известен врагу. Дальше Цезарь отправляет сенатору с гонцом сообщение "+ 2 влево", что значит, что текст шифра будет смещаться на два символа по алфавиту влево в дополнение к изначальному смещению  вправо на один символ. Сенатор отмечает это у себя и в ответ шлет Цезарю: "Буквы «О» в каждой нечетной строке меняем: O на A в исходном тексте" – и так, отправляя гонцов друг другу, они создадут уникальный ключ, не известный другим сенаторам. 

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

Аналогично и в шифровании данных от клиента до VPN-сервера используется механизм генерации сессионного ключа. Для этого происходит обмен временными ключами по алгоритму Диффи-Хеллмана, для подтверждения факта обмена именно с сервером VPN используется сертификат. Как правило, он бывает 1024-, 2048- и 4096-разрядным.

Многие VPN-провайдеры используют значения 2048, а то и 1024. Это делается по нескольким причинам. 

1. Чем меньше этот показатель, тем меньше нагрузка на VPN-сервер и процессор пользователя. Генерировать ключ не такая простая работа.

2. Чем меньше этот показатель, тем медленнее расходуется батарея мобильного устройства. Тут все понятно: нагрузка на процессор – беда для батареи.

3. Сложность генерации замедляет процесс подключения к VPN. Вы наверняка замечали, что с момента нажатия кнопки "Соединиться" до момента подключения к серверу проходит некоторое время, оно будет возрастать или уменьшаться в зависимости от разрядности ключа. 

4. Многие считают, что 2048 бит вполне достаточно и 4096 – излишняя безопасность. 

Использовать показатель 2048 бит – правильный шаг с точки зрения бизнеса. 99% пользователей все равно не понимают значимость этого показателя, в то же время это сократит нагрузку на сервер при генерации сессионного ключа и ускорит процесс подключения пользователя к VPN, что, безусловно, пойдет плюсом сервису.

RSA 512, бывший некогда стандартом надежности, был взломан в 1999 году. Ключ длиной 1024 бит ученые из Мичигана смогли "вскрыть" еще в 2010-м с помощью простых компьютеров, это заняло у них 100 часов, но еще в 2003-м израильские ученые смогли взломать его с помощью суперкомпьютера. А потому мы настоятельно рекомендуем не использовать VPN с RSA 1024 бит.  

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

Вернемся к длине ключа. Иногда пишут, что и 2048-битный ключ также ненадежен и его можно взломать. На самом деле любой ключ можно взломать, но для ключа большой длины нужны очень большие мощности, которыми, по нашей информации, сегодня не обладают не только злоумышленники, но и спецслужбы. Однако это не истина в последней инстанции. В 2010 году ученые научились "вскрывать" RSA 1024, следующим на очереди может стать RSA 2048. Весьма вероятно, его уже научились взламывать, а мы просто не знаем об этом.

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