Это третья глава, посвященная выбору VPN, ранее мы уже рассмотрели выбор количества серверов VPN. Исходя из своих задач и ожиданий, вы должны были определиться, нужен ли вам Single VPN или цепочка VPN-серверов. Также мы рассмотрели протоколы; предполагаю, что большинство из вас остановилось на протоколе OpenVPN, это разумный выбор.
Пока мы говорим исключительно о серверной части, так как в будущем вам придется выбирать программу на ваше устройство, с помощью которой вы будете использовать VPN.
Но еще до перехода к выбору программы нам надо рассмотреть ряд параметров: TLS authentication, порт соединения, сессионный ключ, алгоритм шифрования, длину ключа и аутентификацию данных.
Если с количеством серверов и выбором протокола знакомы многие, то эти показатели для неспециалистов часто выглядят пугающе. Но ничего сложного не будет, я постараюсь максимально понятно рассказать вам о каждом из них.
TLS authentication
Помните, в главе о шифровании я рассказывал про шифр Цезаря? Допустим, в Сенате принимают гонца от Цезаря, но как сенаторы проверят, что этот посол действительно от императора? Может быть, его шифр перехватили злоумышленники и отправили свое сообщение, зашифрованное ключом Цезаря?
Представьте себе, что гонец знает какой-то уникальный пароль, только назвав который его примут в пункте назначения. Примерно так работает и TLS authentication. Пакет handshake («рукопожатие» ‒ процесс начала взаимодействия пользователя и 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.
Генерация сессионного ключа
Простым пользователям сложно понять процесс генерации ключа, потому я постараюсь рассказать о нем на примере Цезаря и Сената. Цезарь использовал свой ключ со смещением на одну букву изо дня в день, из года в год. Спустя некоторое время он осознал, что таким образом он не может общаться с каждым сенатором отдельно, так как отправленное сообщение может прочесть каждый владелец ключа, да и в целом это не очень безопасно.
Что решил Цезарь?
- Ключ должен быть уникальным для каждого сенатора.
- Ключ должен меняться после каждой переписки.
Для этого необходимо придумать какую-то технологию дистанционного создания ключа, так как Цезарь находится на полях сражений, а сенаторы в Риме. Можно, конечно, его просто выслать гонцом нужному сенатору, но тогда враги будут иметь возможность перехватить его и разобраться, как создается ключ шифрования. И Цезарь придумал, как решить эту задачу.
Изначально и сенатор, и Цезарь знают общий ключ – смещение букв на один символ вправо, это стандартный шифр Цезаря. Этот ключ не известен врагу. Дальше Цезарь отправляет сенатору с гонцом сообщение "+ 2 влево", что значит, что текст шифра будет смещаться на два символа по алфавиту влево в дополнение к изначальному смещению вправо на один символ. Сенатор отмечает это у себя и в ответ шлет Цезарю: "Буквы «О» в каждой нечетной строке меняем: O на A в исходном тексте" – и так, отправляя гонцов друг другу, они создадут уникальный ключ, не известный другим сенаторам.
Даже если враг и перехватит данные, не получит конечного ключа, потому как ему не известен первоначальный ключ, который был у Цезаря и сенатора до начала обмена этими сообщениями. Ведь они начали сдвигать буквы уже с учетом первоначального смещения. Чем больше гонцов они отправят в процессе создания ключа и чем сложнее первоначальный способ шифрования, тем труднее неприятелю будет получить ключ для расшифрования переписки.
Аналогично и в шифровании данных от клиента до VPN-сервера используется механизм генерации сессионного ключа. Для этого происходит обмен временными ключами по алгоритму Диффи-Хеллмана, для подтверждения факта обмена именно с сервером VPN используется сертификат. Как правило, он бывает 1024-, 2048- и 4096-разрядным.
Многие VPN-провайдеры используют значения 2048, а то и 1024. Это делается по нескольким причинам.
- Чем меньше этот показатель, тем меньше нагрузка на VPN-сервер и процессор пользователя. Генерировать ключ не такая простая работа.
- Чем меньше этот показатель, тем медленнее расходуется батарея мобильного устройства. Тут все понятно: нагрузка на процессор – беда для батареи.
- Сложность генерации замедляет процесс подключения к VPN. Вы наверняка замечали, что с момента нажатия кнопки "Соединиться" до момента подключения к серверу проходит некоторое время, оно будет возрастать или уменьшаться в зависимости от разрядности ключа.
- Многие считают, что 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. Весьма вероятно, его уже научились взламывать, а мы просто не знаем об этом.
В следующей главе мы поговорим про алгоритм шифрования, длину ключа и аутентификацию данных.
