Кеннет ванн Вик: проблемы безопасности при проверке сертификатов в браузере
Даже такой замечательный ресурс, как Groklaw, занялся дополнительной защитой своих сервисов из-за так называемой «войны на выживание». Очевидно, что сегодня нужно обратить внимание на создание приложений более защищенными и устойчивыми к атакам, независимо от того, с каких направлений они поступают.
Одним из решений, которое достойно нашего внимания, является переход от Web-приложений к их мобильным версиям. В чем резон? Целью атак чаще всего становятся передаваемые данные, и с этой точки зрения мобильные устройства и приложения, установленные на них, являются более защищенными.
Ранее мы уже обсуждали с вами тему о мерах, которые необходимо предпринимать для сохранения конфиденциальности электронной переписки, — прежде всего через управление ключами. В частности, самым сильным способом является самостоятельная генерация собственных ключей и управление ими, не доверяя внешним сервисам.
Но, помимо электронной почты, существует масса других средств коммуникации. С каждым из них можно рассмотреть возможность использования электронных ключей, но в каждом случае реализация может быть разной.
Сегодня большинство Интернет-коммуникаций использует транспортный уровень безопасности Transport Layer Security (TLS) и его предшественника, Secure Sockets Layer (SSL). В любом случае для шифрования данных используется актуальный ключ, созданный с помощью подсистемы SSL. Пока вы не создадите собственную библиотеку SSL, вам придется использовать SSL версии библиотек открытых и авторитетных ресурсов типа OpenSSL, Bouncy Castle и прочих.
Сегодня вы свободно можете использовать библиотеки OpenSSL в приложениях для платформ iOS и Android, ну и конечно для Android ключи от Bouncy Castle.
Но ведь этого совершенно недостаточно!
Когда инициируется сессия SSL/TLS, сервер первым делом представляет клиенту свой SSL сертификат. При традиционном уровне защиты SSL, его сертификат проверяется дважды: соответствует ли имя, указанное в сертификате имени и IP-адресу, определенному через DNS и подписан ли данный сертификат доверенным корневым сертификатом CA?
При этой процедуре возникает пара серьезных проблем. Первая заключается в том, что DNS служба, как таковая, не заслуживает особого доверия. То есть, по крайней мере, один способ проверки сертификата не может гарантировать его подлинность. Во-вторых, если мы увидим, что сертификат подписан доверенным коренным сертификатом, то это достаточно для SSL, но особо ничего не значит для нас. Вот именно в этот момент встает вопрос доверия к сертификатам. И именно поэтому уместно вернуться к плюсам мобильных клиентов.
В традиционных Web-приложениях, например браузерах (при использовании стандартных системных библиотек), выполняется обычная проверка SSL ключей и сертификатов. Некоторые браузеры типа Google Chrome используют технологию привязки сертификатов для проверки SSL в собственных целях, а именно для проверки URL-адресов и безопасного браузинга через сервера Google. Но когда браузер приступает к отображению HTML кода Web-приложения и оно переадресовывает пользователя на зашифрованную SSL страницу (HTTPS), браузер теряет информацию для привязки сертификата.
А это значит, что для обеспечения привязки сертификата, вы должны знать, каким доверенным корневым сертификатом CA подписан каждый сертификат сайта, к которому вы коннектитесь. А это уже выходит за пределы разумного для браузера, но вполне достижимо для большинства мобильных приложений. О чем мы расскажем чуть позже.
© IGeek
