Безопасность и анонимность в сети - часть 7

Безопасность и анонимность в сети - часть 7

t.me/nightbiznes

HTTPS (HTTP Secure)

HTTP - это протокол прикладного уровня передачи данных, как вы уже, наверное, знаете. Именно поэтому мы набираем HTTP:// и затем переходим на www.google.com, и по этому адресу мы попадем на HTTP-версию этого веб-сайта.


Теперь смотрите, в адрес серверов и обратно, в буквальном смысле, происходит отправка текста, который выглядит следующим образом. Здесь указан HTTP протокол.

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

Давайте я это закрою, перейду на Google и поменяю здесь на HTTPS, теперь у меня запущен HTTP поверх TLS или SSL. HTTPS предоставляет средства защиты TLS, потому что он использует TLS, это шифрование данных, аутентификация, обычно на серверной стороне, целостность сообщений и по выбору - аутентификация клиента или браузера.

Когда вы заходите на веб-сайт при помощи HTTPS, веб-сервер запускает задачу по вызову SSL и защите обмена данными. Сервер отправляет сообщение обратно клиенту с указанием, что должен быть установлен защищенный сеанс, и клиент, в ответ, отправляет ему свои параметры безопасности. Это значит, что клиент скажет: "Я готов использовать такую-то цифровую подпись, я готов использовать такой-то метод обмена ключами, алгоритм, я готов использовать такой-то симметричный ключ", а сервер сравнивает эти параметры безопасности со своими собственными до тех пор, пока не находит соответствие, и это называется фазой “рукопожатия” или handshake.

Сервер аутентифицирует клиент посредством отправки ему цифрового сертификата, мы рассмотрим сертификаты позже, и если клиент решает доверять серверу, то процесс продолжается. Сервер может запросить клиент также отправить ему цифровой сертификат для взаимной аутентификации, но такое происходит не часто.

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

Клиент генерирует симметричный сеансовый ключ, например при помощи алгоритма AES, и шифрует его при помощи открытого ключа сервера. Этот зашифрованный ключ отправляется в адрес веб-сервера и оба они, и клиент, и сервер, используют этот симметричный ключ для шифрования данных, которые они отправляют друг другу. Так и устанавливается защищенный канал обмена данными.

Для работы TLS нужен сервер и браузер с поддержкой TLS, а все современные браузеры поддерживают TLS, как мы убедились в статье на Википедии. И во всех браузерах вы увидите HTTPS, что будет указывать на то, что используется TLS, и кроме того, вы часто встречаете замок, все браузеры имеют нечто подобное с целью держать вас в курсе, используете ли вы HTTPS или HTTP с TLS.

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


Если мы посмотрим на замок здесь, то увидим технические детали, какие алгоритмы шифрования используются. В данном случае, используется TLS. Эллиптические кривые с Диффи-Хеллманом, RSA. AES со 128-битным ключом, режим шифрования GCM, и SHA256 для целостности данных. Все это будет согласовываться между клиентом и сервером.

А если мы посмотрим в Wireshark, Wireshark - это анализатор протоколов, то увидим, как трафик принимается и отправляется. Мы видим здесь, что произошел диалог, в котором мой клиент, то есть браузер, сказал: "Вот вещи, которые я поддерживаю". А сервер ответил ему и сказал: "Что ж, вот то, что я, собственно, хотел бы использовать". Затем сервер предоставил сертификат с цифровой подписью и открытый ключ к нему.

https://www.ssllabs.com/ssltest/

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

Посмотрим на сайт Bank of America. Алгоритм подписи SHA-256 с RSA. Это для цифровой подписи. Здесь мы видим цепочку сертификатов, сертификат Bank of America, цепочка спускается вниз, и здесь стоит корневой сертификат, и протоколы, которые сервер готов использовать. Довольно интересный сайт, и он предоставляет вам свою оценку, насколько надежным является целевой сайт.

И есть еще один полезный веб-сайт для оценки при помощи Firefox, а Firefox - это браузер, который я рекомендую. Чтобы попасть на него, нужно пройти по этой ссылке, но она довольно-таки длинная, так что просто наберите в поиске: "Как мне узнать, является ли мое соединение с веб-сайтом безопасным?"

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

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

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

Оранжевый предупреждающий треугольник: Веб-сайт не предоставляет идентификационную информацию. Соединение между Firefox и веб-сайтом только частично зашифровано и не исключает прослушивание.

Серый предупреждающий треугольник: Адрес веб-сайта был верифицирован. Соединение между Firefox и веб-сайтом зашифровано для предотвращения прослушивания.

Зеленый замок: Адрес веб-сайта был верифицирован при помощи сертификата расширенной проверки (EV). Это означает, что владельцу веб-сайта требуется предоставить гораздо больше информации, гораздо больше достоверной информации, чтобы доказать, что он именно тот, за кого себя выдает. Так что если вы видите EV и зеленый замок, то это означает, что была проведена расширенная проверка владельцев сайта. Соединение между Firefox и веб-сайтом зашифровано для предотвращения прослушивания. Такие дела.

Цифровые сертификаты

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

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

Одно из решений, или решение, которое используется в Интернете, это использование цифровых сертификатов, подписанных цифровой подписью в составе цепочки сертификатов. Итак, X.509 - это наиболее часто используемый стандарт для защиты цифровых сертификатов, и эти сертификаты представляют собой цифровые документы, содержащие информацию о владельце сертификата или, например, о веб-сайте или компании, владеющей веб-сайтом, в данном случае это Mozilla.

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

Давайте кликнем на замок, теперь на "Дополнительную информацию"... Видим здесь надпись: "Верифицировано DigiCert". Итак, DigiCert - это удостоверяющий центр. Это сторона, которая утверждает, что Mozilla является именно Mozilla, и что открытый ключ этого сертификата подлинный, и что он не был изменен.

Давайте теперь посмотрим на сам сертификат. Здесь внизу видим согласованные алгоритмы. Теперь взглянем на сертификат. Этот сертификат действителен только для этого домена. Он валидирует данную организацию и он выпущен DigiCert. Здесь контрольные суммы. Пока что не будем их касаться. Можете считать, что контрольная сумма - это уникальное значение. Это хеши сертификатов. То есть это действительно лишь уникальное значение, вычисленное для конкретно этого сертификата.

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

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

Этот сертификат был подписан DigiCert. И если я нажму сюда, то мы увидим их сертификат. Это подводит нас к вопросу о цепочке сертификатов, потому что открытый ключ RSA для этого сертификата должен быть использован, чтобы дешифровать подпись из этого первого сертификата, чтобы получить хеш SHA-256, который должен подойти к хешу SHA-256, вычисленному для остальной части сертификата, так чтобы вы знали, что этот сертификат доподлинно выпущен DigiCert.

И такой же процесс происходит для валидации, что этот сертификат является действующим. А если мы поднимемся на верхний из сертификатов в цепочке, который является корневым сертификатом, как нам узнать, что этот сертификат действующий, и что мы можем ему доверять?

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

Если вы желаете посмотреть сертификаты в Firefox, идем сюда, "Настройки", расширенные, сертификаты, посмотреть сертификаты. И если вы нажмете на "Центры сертификации", то увидите список, и это все корневые центры сертификации, которым вы доверяете. Их здесь сотни.

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

Давайте закроем это. Промотаем список вниз... Как там он назывался? Это был DigiCert. Здесь мы видим... DigiCert... И поскольку в нашем хранилище доверенных сертификатов есть тот сертификат из цепочки сертификатов открытого ключа подписи, то мы доверяем веб-сайту Mozilla. Здесь мы видим цепочку сертификатов. Это сертификат Bank of America. В самом низу этой цепочки имеется корневой сертификат.

Центры сертификации ключей и HTTPS

А теперь мы поговорим о центрах сертификации ключей и HTTPS. HTTPS полагается на сертификаты для аутентификации, что сайт подлинный, а открытый ключ принадлежит именно этому сайту. Без сертификатов защищенность HTTPS попросту не работает. Она ломается.

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

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

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

Давайте посмотрим, сравнительно недавно, читайте заголовок, "Google ставит ультиматум Symantec касаемо неавторизованных HTTPS сертификатов". Что же там произошло? Symantec выпустил сертификаты, объявляющие о своей принадлежности Google, но Google, по факту, никогда не запрашивал этих сертификатов. А Symantec - это реально один из лидеров рынка по части удостоверения сертификатов. Это крупнейший игрок на рынке удостоверяющих центров. Эти ребята должны задавать стандарты.

Немного проскроллим вниз, читаем: "Вначале Symantec заявлял, что были выпущены 23 сертификата", и когда речь идет о 23 сертификатах, то это означает, что этих 23 сертификатов не должно было быть вообще. И что же дальше: "Google поставил под сомнение эту цифру, отмечая, что она значительно выше. Проведя дополнительные проверки, в Symantec признали, что были выпущены 164 сертификата для 76 доменов и 2458 сертификатов для даже незарегистрированных доменов".

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

Теперь другой случай, целая партия фальшивых сертификатов, выпущенных для нескольких доменов Google, включая, и в общем-то, это весь google.com, и некоторые другие домены Google. "Они были выпущены компанией MSC Holdings из Египта, это промежуточный центр сертификации, который работает под контролем Информационного центра сети Интернет Китая".

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

Это дерево доверия между центрами сертификации. Можно увеличить масштаб и рассмотреть все эти различные цепочки сертификатов и доверительных отношений.

Итак, удостоверяющие центры существуют в примерно 50 странах. Есть более 1400 центров, которым доверяет Microsoft и Mozilla, а следовательно и Firefox. Здесь есть даже такие центры, как почта Гонконга. Это обычный центр сертификации. Есть подразделения удостоверяющих центров типа Министерства внутренней безопасности США или военных подрядчиков США, которые являются нижестоящими центрами.

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

Это означает, что США, Великобритания, Китай, Россия, 14 глаз, все они могут выпускать фальшивые сертификаты, которым ваш браузер будет доверять, и следовательно, могут увидеть зашифрованный HTTPS трафик, который будет выглядеть абсолютно нормальным для вас, но они смогут дешифровать его. Вы будете считать, что у вас работает end-to-end шифрование, а на деле эти ребята могут выпускать фальшивые сертификаты, и HTTPS оказывается полностью бессмысленным.

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

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

Пожалуйста, вот вам sslsniff. Изначально он был разработан в связи с уязвимостью, обнаруженной в Internet Explorer, но он также мог быть использован для подстановки другого сертификата, если вы находитесь посередине. Очевидно, что если вы правительство, то у вас будет собственная версия подобного программного обеспечения, в котором вы сможете подставлять свой собственный сертификат в трафик.

Как видите, здесь говорится: "Разработан для MITM-атак на все SSL соединения в локальной сети, динамически генерирует сертификаты для доменов, доступные на лету. Новые сертификаты встраиваются в цепочку сертификатов, которая подписывается любым сертификатом, который вы обеспечите".

Есть множество способов борьбы с фальшивыми сертификатами и последующим дешифрованием вашего трафика. Вы можете уменьшить количество сертификатов, которым вы доверяете. Если мы зайдем в "Настройки", "Расширенные", “Сертификаты”, “Посмотреть сертификаты”, мы увидим здесь сотни сертификатов, которым вы непосредственно доверяете.

Вы можете удалить ненужные вам сертификаты. Вы обнаружите, что порядка 95% ресурсов, которые вы посещаете, нуждаются в малом количестве сертификатов.

Так что если уменьшение количества сертификатов вас заинтересует, можете погуглить на этот счет и изучить этот вопрос, поэкспериментировать с удалением сертификатов.

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

Другая вещь, которую вы можете сделать, это отслеживание изменений сертификатов тех сайтов, которые вы используете. Есть аддон для Firefox под названием "Certificate Patrol".

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

Спустимся ниже. Этот аддон показывает вам контрольную сумму сертификата во время вашего предыдущего посещения сайта, и контрольную сумму текущего сертификата.

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

Далее, есть другая опция, если вы владелец сервера или если у вас есть какие-либо связи с тем, куда вы коннектитесь, вы можете использовать так называемое "закрепление сертификата".

Что это такое? Как сказано на сайте проекта OWASP: "Закрепление - это процесс ассоциации хоста с его ожидаемым X.509 сертификатом или открытым ключом". Другими словами, это способ сказать: "Я принимаю только один определенный открытый ключ". Например, вы можете связать сертификат с его контрольной суммой или хешем, так что если кто-либо его поменяет, то вы сразу об этом узнаете.

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

Привязка работает не только для HTTPS. Ее можно использовать с VPN, SSL, TLS и другими протоколами, которые вы используете для работы с сертификатами.

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

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

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

Если атакующий может расположиться лишь посередине между вами и терминатором, то VPN туннелирование предотвратит подмену сертификата. Если атакующий получит доступ к трафику здесь, то конечно, он сможет заменить сертификат.

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

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

Это был фрагмент о центрах сертификации и HTTPS, а также вопросах, связанных с ними. Ваш основной подход к защите - это использование эшелонированной защиты.

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