Сравнение технологий

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

Место в сетевой модели

Прежде всего необходимо отметить, что данные технологии относятся к различным уровням эталонной сетевой модели ISO/OSI. Протоколы VPN обычно соответствуют канальному или сетевому уровням, тогда как протокол SSL/TLS находится между транспортным и прикладным уровнями (как правило, его причисляют к уровню представления). Это во многом определяет возможности технологий и сценарии их применения.

VPN-протоколы IPSec и IPlir защищают весь трафик между двумя узлами, позволяя пользователю в случае удалённого подключения к доверенной сети быть её полноправным членом, как если бы он находился непосредственно в ней.

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

Оно лишь позволяет судить о степени соответствия конкретной технологии конкретной задаче. Например, в случае необходимости защиты всего трафика приоритет, очевидно, должен быть отдан технологии VPN, тогда как в случае необходимости доступа только к одному приложению более рациональным может оказаться применение SSL/TLS. При этом не стоит забывать и про такие сопутствующие нюансы, как последствия взлома защиты для каждого из случаев (получение доступа ко всей сети или только к одному приложению) или особенности работы конкретных приложений, некоторые из которых могут не обеспечивать важные с точки зрения безопасности функции, например проверку списка отозванных сертификатов. Отметим также, что контроль доступа при защите с помощью SSL/TLS может быть настроен более тщательным образом, ведь организация защищённого соединения непосредственно между приложениями позволяет устанавливать различные права доступа пользователя для каждого из приложений. Кроме того, упрощается и дифференциация прав доступа для различных пользователей.

Принадлежность рассматриваемых технологий разным сетевым уровням также накладывает свой отпечаток на специфику их работы с NAT-устройствами. Данные устройства изменяют IP-адреса в IP-пакетах, что может вызывать трудности при передаче через них защищённого трафика в случае использования VPN-протоколов, следящих за целостностью IP-пакетов. К таким протоколам относится, например, IPsec. В качестве решения данной проблемы может рассматриваться использование технологии NAT-T, позволяющей защищённым пакетам успешно проходить через NAT-устройства. Тем не менее технология NAT-T поддерживается далеко не всеми реализациями VPN, что отрицательно сказывается на совместимости используемых решений. Протокол SSL/TLS не имеет описанных проблем с NAT-устройствами, так как лежит выше транспортного уровня и корректность его работы не зависит от смены IP-адресов и номеров портов. Еще одним важным отличием между рассматриваемыми технологиями является то, что VPN-решения могут использовать в качестве транспортного протокола как TCP, так и UDP, в то время как классические SSL/TLS решения — только TCP. Это ограничивает применение SSL/TLS в сценариях, для которых задержка трафика, вызванная потерями пакетов, является критичной. Стоит отметить, что для таких случаев был разработан альтернативный протокол под названием DTLS, представляющий собой переработанную с целью поддержки транспортного протокола UDP версию TLS 1.1. Однако поддержка DTLS обеспечивается далеко не всеми распространёнными реализациями SSL/TLS

Вопросы безопасности

Аутентификация сторон при использовании технологии VPN обычно выполняется на основе сертификатов (IPsec) или предварительно распределённых секретных ключей (IPsec, IPlir). Это позволяет выбрать наиболее подходящий способ аутентификации в зависимости от конкретного сценария.

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

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

При применении SSL/TLS также существует возможность выполнения ряда проверок клиентского устройства перед предоставлением ему прав доступа. Однако осуществление таких проверок обычно также требует установки дополнительных апплетов к браузеру.
Широкая распространенность протокола SSL/TLS послужила основанием для его детального изучения, что привело к обнаружению целого ряда уязвимостей, имеющихся в этом протоколе. Уязвимости можно разделить на архитектурные, то есть основанные на недостатках самой спецификации протокола SSL/TLS, и на присущие только конкретным реализациям протокола. Такое разделение можно назвать условным, поскольку большинство архитектурных уязвимостей основаны на теоретических особенностях спецификации SSL/TLS, но для своей эксплуатации требуют выполнения ряда практических требований. К основным атакам на SSL/TLS можно отнести BEAST, Padding Oracle Attacks (атака Водонея, Lucky 13, POODLE), атаки на поточный шифр RC4, атака при «пересогласовании», атаки на основе сжатия данных (CRIME, TIME, BREACH), атаки, основанные на навязывании небезопасных криптографических параметров (FREAK, Logjam), атаки, основанные на понижении версии используемого протокола SSL/TLS, Heartbleed.

Большинство из перечисленных атак были реализуемы только на момент своего обнародования и впоследствии устранялись. Можно сказать, что обнаружение новых уязвимостей в SSL/TLS сыграло и положительную роль в становлении этого протокола, поскольку во многом обуславливало его развитие, приводя либо к разработке дополнительных рекомендаций по его использованию, либо к выпуску новых версий протокола с иммунитетом к найденным недостаткам. Несмотря на это, на большом количестве узлов в сети до сих пор используются старые версии протоколов SSL/TLS или же попросту игнорируются имеющиеся рекомендации, что, наряду с большой вероятностью обнаружения новых атак, не позволяет говорить о гарантированной надёжности при использовании технологий на основе SSL/TLS. Некоторые протоколы, применяющиеся для развёртывания VPN, также могут быть подвержены разного рода атакам, в частности протокол PPTP имеет целый ряд серьезных уязвимостей. Тем не менее считается, что такие протоколы, как IPsec и IPlir, обеспечивают достаточный уровень безопасности, поскольку на данный момент не имеют каких-либо существенных выявленных уязвимостей.

Заключение

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