Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 83
По TLS и SSL.
описанная атака человек по середине по мне так сомнительна, в случае подмены сертификата PKI X.509 атакующий ничего не добьется. Т.к. сам сертификат уже будет выдан другой организацией. А получить такой же DN-идентификатор он не сможет.
И вообще в стандарте используется протокол обмена ключами Диффи-Хелмана, который как раз и создан для обмена сессиоными ключами в открытом эфире.
описанная атака человек по середине по мне так сомнительна, в случае подмены сертификата PKI X.509 атакующий ничего не добьется. Т.к. сам сертификат уже будет выдан другой организацией. А получить такой же DN-идентификатор он не сможет.
И вообще в стандарте используется протокол обмена ключами Диффи-Хелмана, который как раз и создан для обмена сессиоными ключами в открытом эфире.
> принять сертификат и работать с сайтом, либо отказаться его принимать, но и работать с сайтом тогда уже не получится
если пользователь, пардон, дурак, то его надо либо уволить, за служебное не соответствие, либо отправить на переобучение.
если пользователь, пардон, дурак, то его надо либо уволить, за служебное не соответствие, либо отправить на переобучение.
Вот в том-то и дело, что сертификат будет подложный, это будет видно, НО у вас останется два варианта: либо принять подложный (согласиться, что вас будут прослушивать), либо не работать с этим сайтом вообще. Только одно из двух.
Если же HTTPS будет идти внутри VPN-тоннеля, то тут уже подложить левый сертификать просто не выйдет. А ключи для VPN можно принести безопасными путями. Главное чтобы бинарный SSL-трафик не был закрыт на файрволе как таковой, хотябы на одном порте (а обычно именно так и происходит — по 443 порту разрешают гонять SSL-трафик всем юзерам корпоративного файрвола).
Если же HTTPS будет идти внутри VPN-тоннеля, то тут уже подложить левый сертификать просто не выйдет. А ключи для VPN можно принести безопасными путями. Главное чтобы бинарный SSL-трафик не был закрыт на файрволе как таковой, хотябы на одном порте (а обычно именно так и происходит — по 443 порту разрешают гонять SSL-трафик всем юзерам корпоративного файрвола).
так это проблема не SSL! Сам по себе протокол достаточно продуманный, стандартизованный, в нем уже не определен RSA как основной криптоалгоритм. Такой себе хороший констуркор под свои нужды :)
В случае VPN могут быть закрыты порты, может стоять файрволл с проверкой передаваемых пакетов (допустим, запрещающий не-HTTP пакеты). В этом случае VPN бессилен.
А в вышем случае я смотрю начальство желает смотреть все SSL-соединения, но VPN открыто для всех и все. Т.е. вопрос стоит сомнительно. И это проблема не _безопасности_, а организационных мер, не связанных с безопасностью.
В случае VPN могут быть закрыты порты, может стоять файрволл с проверкой передаваемых пакетов (допустим, запрещающий не-HTTP пакеты). В этом случае VPN бессилен.
А в вышем случае я смотрю начальство желает смотреть все SSL-соединения, но VPN открыто для всех и все. Т.е. вопрос стоит сомнительно. И это проблема не _безопасности_, а организационных мер, не связанных с безопасностью.
Ну во-первых, у меня лично пока вообще таких проблем (с прослушкой) нет :)
Во-вторых, на множестве корпоративных файрволов открыт не-HTTP-трафик по порту 443 (по вполне понятным причинам), чего вполне достаточно (просто VPN-сервер надо настроить на прослушку именно этого порта).
В-третьих, речь не идет о «проблемах SSL». Я к этому протоколу тоже претензий не имею :) Речь идет о том, с какими проблемами могут сталкнуться пользователи, даже при использовании HTTPS :)
Во-вторых, на множестве корпоративных файрволов открыт не-HTTP-трафик по порту 443 (по вполне понятным причинам), чего вполне достаточно (просто VPN-сервер надо настроить на прослушку именно этого порта).
В-третьих, речь не идет о «проблемах SSL». Я к этому протоколу тоже претензий не имею :) Речь идет о том, с какими проблемами могут сталкнуться пользователи, даже при использовании HTTPS :)
В корпоративной среде должен быть только один вариант. Работа через TLS/SSL-соединения, использующие подложные сертификаты, должна быть запрещена политиками безопасности.
>Вот в том-то и дело, что сертификат будет подложный, это будет видно, НО у вас останется два варианта: либо принять подложный (согласиться, что вас будут прослушивать), либо не работать с этим сайтом вообще. Только одно из двух.
Не обязательно. Есть, по крайней мере, два варианта оставить корпоративного пользователя в неведении.
Первый, наиболее просто реализуемый:
Сертификат, который использует «сервер-прослушка» самоподписанный, добавляется к доверенным сертификатам браузера и убирается галочка «Предупреждать о недействительных серфитикатах узлов» в настройках браузера, что бы не ругался на несовпадения имен узлов.
Второй, более правильный, реализованный в SSL Mitm proxy:
СА сертификат «сервера-прослушки» добавляется к доверенным сертификатам браузера. Когда пользователь подключается куда-либо через SSL, прокси получив сертификат сервера генерирует аналогичный сертификат, подписанный собственным СА. Поскольку данный СА прописан у пользователя никаких предупреждений пользователь не получит.
Не обязательно. Есть, по крайней мере, два варианта оставить корпоративного пользователя в неведении.
Первый, наиболее просто реализуемый:
Сертификат, который использует «сервер-прослушка» самоподписанный, добавляется к доверенным сертификатам браузера и убирается галочка «Предупреждать о недействительных серфитикатах узлов» в настройках браузера, что бы не ругался на несовпадения имен узлов.
Второй, более правильный, реализованный в SSL Mitm proxy:
СА сертификат «сервера-прослушки» добавляется к доверенным сертификатам браузера. Когда пользователь подключается куда-либо через SSL, прокси получив сертификат сервера генерирует аналогичный сертификат, подписанный собственным СА. Поскольку данный СА прописан у пользователя никаких предупреждений пользователь не получит.
Часто пользователи все же имеют админские права (в виду специальности у программистов, например) и могут менять настройки браузеров. Впрочем, если админ очень захочет — сделает что угодно. Однако на практике в большенстве случаев так не делают.
Там не только диффи хелман используется, впрочем это в данном случае неважно.
атакующий ничего не добьется. Т.к. сам сертификат уже будет выдан другой организацией.
KIS так HTTPS-тафик проверяет, но он об этом честно предупреждает и оставляет выбор пользователю соглашаться на подмену сертификатов и читать предупреждения или не проверять шифрованный трафик.
Насчёт покупки VPN аккаунта. Есть же бесплатная альтернатива — Hamachi. Или это не то?
Они используют UDP, а внешний UDP-трафик открыт на корпоративных файрволах редко. И бесплатно оно только для некоммерческого использования.
В статье написано очень много умных слов, но по большому счёту она ниочём :(
В начале описана классическая схема man-in-the-middle. Да, криптография с открытым ключём уязвима к этой атаке. Это никто не скрывает — и именно для этого придуманы сеть доверия PGP и X.509, а браузеры кричат если не могут проверить подлинность сертификата сайта.
Такое вот имхо.
В начале описана классическая схема man-in-the-middle. Да, криптография с открытым ключём уязвима к этой атаке. Это никто не скрывает — и именно для этого придуманы сеть доверия PGP и X.509, а браузеры кричат если не могут проверить подлинность сертификата сайта.
Такое вот имхо.
Кстати еще неверно:
«Приватный ключ служит для зашифрования и находится у отправителя данных, а публичный — для дешифрования, он передается получателю.»
На самом деле открытый ключ служит для шифрования информации, а закрытый (приватный) для ее дешифрации.
«Приватный ключ служит для зашифрования и находится у отправителя данных, а публичный — для дешифрования, он передается получателю.»
На самом деле открытый ключ служит для шифрования информации, а закрытый (приватный) для ее дешифрации.
Назначение ключей я действительно перепутал. Исправил.
Подправьте еще то, что отправителю передается открытый ключ (на то он и открытый), а приватный остается у получателя. Иначе никакого бы смысла в таких ключах небыло бы, так как перехватив ключ для дешифрации (приватный), никаких промежуточных серверов уже не надо — бери и дешифровывай. А так как передается только ключ, с помощью которого информация шифруется, но ее невозможно раскрыть, становится необходима атака с подменой источника отправления, которая и описана у вас ниже.
Подправьте еще то, что отправителю передается открытый ключ (на то он и открытый), а приватный остается у получателя. Иначе никакого бы смысла в таких ключах небыло бы, так как перехватив ключ для дешифрации (приватный), никаких промежуточных серверов уже не надо — бери и дешифровывай. А так как передается только ключ, с помощью которого информация шифруется, но ее невозможно раскрыть, становится необходима атака с подменой источника отправления, которая и описана у вас ниже.
Давайте разберемся. Когда я изучал этот вопрос, пользовался Википедией. В статье про HTTPS написано «Данные, передаваемые по протоколу HTTP, «упаковываются» в криптографический протокол SSL или TLS, тем самым обеспечивается защита этих данных». Ну это конечно и так понятно, приведено для целостности цепочки.
Теперь идем на страничку про SSL. Там сказано: «Использует шифрование с открытым ключом для подтверждения подлинности передатчика и получателя».
Кликаем на шифрование_с_открытым_ключом и там видим:
Криптографическая система с открытым ключом (или Асимметричное шифрование, Асимметричный шифр) — система шифрования и/или электронной цифровой подписи (ЭЦП), при которой открытый ключ передаётся по открытому (то есть незащищённому, доступному для наблюдения) каналу, и используется для проверки ЭЦП и для шифрования сообщения. Для генерации ЭЦП и для расшифрования сообщения используется секретный ключ.
Где ошибка, что я пропустил?
Теперь идем на страничку про SSL. Там сказано: «Использует шифрование с открытым ключом для подтверждения подлинности передатчика и получателя».
Кликаем на шифрование_с_открытым_ключом и там видим:
Криптографическая система с открытым ключом (или Асимметричное шифрование, Асимметричный шифр) — система шифрования и/или электронной цифровой подписи (ЭЦП), при которой открытый ключ передаётся по открытому (то есть незащищённому, доступному для наблюдения) каналу, и используется для проверки ЭЦП и для шифрования сообщения. Для генерации ЭЦП и для расшифрования сообщения используется секретный ключ.
Где ошибка, что я пропустил?
Кстати еще неверно:
«Приватный ключ служит для зашифрования и находится у отправителя данных, а публичный — для дешифрования, он передается получателю.»
На самом деле открытый ключ служит для шифрования информации, а закрытый (приватный) для ее дешифрации.
«Приватный ключ служит для зашифрования и находится у отправителя данных, а публичный — для дешифрования, он передается получателю.»
На самом деле открытый ключ служит для шифрования информации, а закрытый (приватный) для ее дешифрации.
В большинстве случаев хостинг компании запрещают поднимать любые vpn и прокси.
Правда я на своем выделеном сервере поднял OpenVPN, сижу через него пока не заметили :)
В моем случаи очень классная схема получилась.
Живу я в общаге, там где злые админы-студенты частенько смотрят трафик. Интернет у меня UA-IX 10 мбит/сек а на МИР 128 кбит/сек.
При помощи OpenVPN я убиваю 2 зайца:
1. Мой трафик шифруется при помощи OpenVPN
2. У меня мировой канал поднимается до скорости равной скорости UA-IX (мой сервер входит в эту зону + подключен к мировым точкам обмена траффика)
Правда я на своем выделеном сервере поднял OpenVPN, сижу через него пока не заметили :)
В моем случаи очень классная схема получилась.
Живу я в общаге, там где злые админы-студенты частенько смотрят трафик. Интернет у меня UA-IX 10 мбит/сек а на МИР 128 кбит/сек.
При помощи OpenVPN я убиваю 2 зайца:
1. Мой трафик шифруется при помощи OpenVPN
2. У меня мировой канал поднимается до скорости равной скорости UA-IX (мой сервер входит в эту зону + подключен к мировым точкам обмена траффика)
Будьте добры, ссылочку на типовой договор с хостинговой компанией, в котором будет прописан пункт запрещающий поднимать что либо. Арендуем vds,vps, ставим свои дедики в Росиии и штатах, соединяем их различными видами шифрованых каналов (mysql+ssl, postgres+ssl, openvpn туннели, ldaps, ssh) и единственное ограничение — запрет на спам и действия противоречащие законодательству страны.
Ограничивающий фактор — платный входящий трафик при превышении соотношения входящий/исходящей > X
Ограничивающий фактор — платный входящий трафик при превышении соотношения входящий/исходящей > X
Если у вас VPS или VDS с собственным администрированием, то таких запретов теоретически быть не должно. Бывают VPS/VDS с администрированием хостером (он владеет root'ом), тогда конечно VPN от них врядле дождешся.
К примеру, очень популярный в украине Hosting.Ua
Договор о предоставлении услуг аппаратного хостинга (аренда выделенного сервера) — Физ. Лицам
3 страница:
Договор о предоставлении услуг аппаратного хостинга (аренда выделенного сервера) — Физ. Лицам
3 страница:
не размещать и не запускать PROXY, VPN или туннели;
Интересно для общего кругозора, спасибо :)
Ерунда все это. Человеку даны глаза чтобы смотреть на сертификат сайта (в чем помогает браузер) и мозг, чтобы оценивать эту информацию. Тоже самое с SSH — идентификатор ключа, при первом подключении, весьма разумно проверить другим путем. Оба протокола весьма разумно защищены от атаки man-in-the-middle, вопрос только в исползовании их.
И никакой прокси не расшифрует трафик.
И никакой прокси не расшифрует трафик.
Такое сплошь и рядом. Есть примеры покруче: https://ibank.bpsb.by
Объясните, пожалуйста, как действовать в следующей ситуации: вы работаете из офиса, при любом https-соединении вам суют фальшивый сертификат. Вы хотите периодически проводить операции, которые требует строгой приватности, даже от начальства и IT-отдела. На корпоративном файрволе открыт исходящий SSL-трафик на порт 443. Уволится? Или поднять SSH, VPN?
Уволится, или как минимум серьезно поговорит с начальством.
Ну или всячески изголяться, игнорируя то, что по сути на предприятии установлен режим тотальной слежки.
Ну или всячески изголяться, игнорируя то, что по сути на предприятии установлен режим тотальной слежки.
Объясните, пожалуйста, зачем вы пользуетесь в рабочее время вычислительной техникой в личных целях?
Потому что не жизнь ради работы, а работа ради жизни… Наверное я еще не стал совсем роботом и позволяю себе жить как человек даже в рабочее время. Ну а, когда надо, позволяю себе работать в нерабочее. Короче, мы с работой в дружеских отношениях и бюрократией не страдаем.
Я считаю, что так должно быть у всех.
Я считаю, что так должно быть у всех.
OpenVPN классная штука. Пользовался несколько раз.
А вообще конечно удобно, если сервак есть, если висишь где-то в незащищенной сети или потенциально прослушиваемой сети, то можно через свой впн шифровать трафик. :)
А вообще конечно удобно, если сервак есть, если висишь где-то в незащищенной сети или потенциально прослушиваемой сети, то можно через свой впн шифровать трафик. :)
Проблема в том, что многие (криворукие) https:// сайты и спользуют неподписанный сертификат, просто привыкаешь к этому, хотя как я понял, в этом случае https эквивалентен http((
Гмм… Хронической дисфункцией головного мозга должны обладать IT-шники той конторы, которая снифает на проксе проходящий трафик путем дешифрования SSL-сессий. Надо же, как они повышают безопасность, расшифровывая секьюрные соединения банк-клиентских приложений. Любой тривиальный руткит, будучи без проблем установленным на проксе (которая, как правило является машиной с торчащей в Интернет жопой), будет собирать массу полезной для третих лиц информации и банковских проводках, не говоря о формировании фальсифицированных платежей.
И любая служба безопасности банка пошлет лесом ту контору, которая заявит о пропаже средств с банковского счета, если узнает, что у них такая схема SSL-снифинга.
И любая служба безопасности банка пошлет лесом ту контору, которая заявит о пропаже средств с банковского счета, если узнает, что у них такая схема SSL-снифинга.
почему на тот же banking.webmoney.ru FF 3.04 ругается на непописанный сертификат?
*неподписанный
У меня — не ругается, говорит — все ОК. FF 3.04.
У вас noscript наверное стоит — там тягается скрипт с https://dynamic.exaccess.ru/, а их сертификат подписан самими вебманями.
Нет у меня NoScript-a. Да и зачем, по-вашему, носкрипту пользоваться сертификатами, которые подписаны недоверенным ЦС?
Вы не поняли. У них в самом низу страницы вот такой код:
<script type=«text/javascript» src=«https://dynamic.exaccess.ru/asp/dynamic_script.asp?id_d=143996»></script>
У dynamic.exaccess.ru сертификат выдан webmoney, именно на него у меня ругается firefox. Если отключены скрипты или срабатывает какой-нибудь AdBlock, или фаервол, или у Вас вебмани в Trusted Authorities, то, конечно, Вы предупреждений не увидите.
<script type=«text/javascript» src=«https://dynamic.exaccess.ru/asp/dynamic_script.asp?id_d=143996»></script>
У dynamic.exaccess.ru сертификат выдан webmoney, именно на него у меня ругается firefox. Если отключены скрипты или срабатывает какой-нибудь AdBlock, или фаервол, или у Вас вебмани в Trusted Authorities, то, конечно, Вы предупреждений не увидите.
Вы не поверите, но в общем случае (и конкретно в вашем описании) SSH соединение менее безопасно, чем HTTPS(SSL) :]
> Чтобы далее «читать» весь трафик пользователя, промежуточный сервер подменяет сертификат на свой. Т.е. он просто сам подключается к клиенту со своим сертификатом, и в то же время подключается к удаленному серверу. Клиенту приходит «левый» сертификат от сервера-злоумышленника, а браузер сообщает пользователю об опасности (такие сертификаты всегда не подписаны). У пользователя остается выбор: принять сертификат и работать с сайтом, либо отказаться его принимать, но и работать с сайтом тогда уже не получится. Иногда пользователи вообще игнорируют содержимое сертификатов и машинально принимают любые переданные им.
Собственно говоря вся эта инфраструктура PKI назначена как раз для защиты именно от такой атаки. )
А если надо работать «без вариантов» — то простите, о какой безопасности может идти речь?
> Чтобы далее «читать» весь трафик пользователя, промежуточный сервер подменяет сертификат на свой. Т.е. он просто сам подключается к клиенту со своим сертификатом, и в то же время подключается к удаленному серверу. Клиенту приходит «левый» сертификат от сервера-злоумышленника, а браузер сообщает пользователю об опасности (такие сертификаты всегда не подписаны). У пользователя остается выбор: принять сертификат и работать с сайтом, либо отказаться его принимать, но и работать с сайтом тогда уже не получится. Иногда пользователи вообще игнорируют содержимое сертификатов и машинально принимают любые переданные им.
Собственно говоря вся эта инфраструктура PKI назначена как раз для защиты именно от такой атаки. )
А если надо работать «без вариантов» — то простите, о какой безопасности может идти речь?
Поясните такой момент. При https соединении сервер присылает браузеру свой сертификат, так? После чего браузер должен проверить его подпись, так? Как он это делает — посылает запрос в центр сертификации (не знаю как правильно — ну то есть VeriSign)? Тогда что мешает также вклинится между браузером и верисигном и прислать ответ — все окей, сервак правильный?
Нет, запросов в центр сертификации нет. Подлинность сертификата подтверждает цифровая подпись, которая идет вместе с сертификатом.
Угу. А список центров сертификации жестко где-то прописан? Просто что мешает полностью эмулировать центр сертификации — сгенерить пару ключей, подписать приватным сертификат псевдосерверу, отдать пользователю, когда тот запросит публичный для проверки подписи — выдать?
Тут я уже точно не знаю, но могу сказать вот что. Для проверки подписи нужен ключ (подпись — это ассиметричный шифр, один ключ шифрует — он остается у того, кто выдал сертификат, второй видимо отдается всем, кто хочет сертификат проверить). Так как количество авторизированных раздатчиков сертификатов ограничено, предполагаю, что их ключи проверки встроены в браузеры. Подделать в этом случае ничего не удастся.
Повторю — информация основана на догадках и не точна, если кто-то может ее подтвердить или апровергнуть — милости прошу. А саму уточнять все это сейчас нет времени.
Повторю — информация основана на догадках и не точна, если кто-то может ее подтвердить или апровергнуть — милости прошу. А саму уточнять все это сейчас нет времени.
Операционная система (и сами браузеры, кстати, тоже) содержит корневые сертификаты многих центров сертификации. В Windows их можно посмотреть выполнив certmgr.msc
С помощью корневых сертификатов в системе, собственно, и проверяется, был ли сертификат сервера подписан у доверенного центра или нет. Это еще одна дырка — имея доступ к компьютеру, можно подменить корневой сертификат или добавить свой корневой сертификат в список доверенных, тогда браузер уже не будет ругаться при атаке Man-in-the-Middle.
С помощью корневых сертификатов в системе, собственно, и проверяется, был ли сертификат сервера подписан у доверенного центра или нет. Это еще одна дырка — имея доступ к компьютеру, можно подменить корневой сертификат или добавить свой корневой сертификат в список доверенных, тогда браузер уже не будет ругаться при атаке Man-in-the-Middle.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Безопасность (шифрование) трафика