Так ли приватен HTTPS?

    Недавно в одном из прочитанных блогов увидел интересное утверждение (в моем вольном переводе):
    Думаете, когда вы работаете с онлайн-банкингом из офиса, у вас сквозное безопасное соединение? Подумайте еще разок.

    Достаточно, чтобы заинтересовать и немного покопать. «И шо ви таки думаете? (с)» В «насквозь безопасное» HTTPS соединение можно врезать как минимум двух посредников (Man In The Middle). Правда, оба должны быть Trusted (TMITM), так что не надо сильно паниковать. Пока что.


    Вариант 1: корпоративный/операторский файрвол или прокси


    В корпоративных сетях пользователи обычно выходят в Интернет через прокси, который может быть задан явно или неявно (transparent или просто продвинутый firewall). Это необходимо для поддержания хотя-бы минимального корпоративного контроля над трафиком (фильтрация нежелательных сайтов/скриптов/рекламы, антивирусные проверки, кеширование и т.д.) и, в принципе, логично.
    Абсолютно понятно, как это работает для нешифрованного HTTP, а вот с HTTPS — понятно не все. Ведь HTTPS как раз и предназначен для защиты от «врезания» в сессию и перехвата трафика: данные шифруются, а аутентичность сервера проверяется сертификатами. Так что, возникают как минимум два вопроса:
    1. Почему я должен доверять сертификату прокси?
    2. Даже если я доверяю сертификату прокси, он же выпущен на имя прокси, а не на имя моего банка — как он может сработать?
    Выходит, что может.

    Первый вопрос вообще не возникает, если в компании развернута собственная инфраструкра сертификатов и есть свой CA. В таком случае, сертификат этого CA будет установлен как доверенный на каждой рабочей машине, и всё, что будет подписано этим же сертификатом (наш прокси) также будет доверенным. Именно из-за этого подобное «доверенное» (Trusted) внедрение и становится возможным в этом сценарии.

    Но что делать с неправильным именем в сертификате? Существует (и довольно давно) класс программ типа MITMproxy или HoneyProxy, которые этот вопрос успешно решают. Их основная функция — читить в Apple GameCenter генерировать сертификаты на лету! Прокси устанавливается в качестве промежуточного CA (подписанного Enterprise Root CA) и динамически генерирует сертификаты (для себя же) на любое имя. Таким образом, клиент думает, что он общается с банком, хотя, на самом деле, его HTTPS сессия заканчивается на прокси.
    Подробности тут.

    image

    Так что, исходное утверждение оказалось верным, и верить рабочим HTTPS-соединениям можно лишь настолько, насколько можно верить своему ИТ-отделу. Или же использовать браузер вроде Firefox, у которого имеется свое, независимое от ОС, хранилище сертификатов и поддержка Certificate Pinning (не так давно ставшая популярной в браузерах). Ну, или, конечно же, не использовать рабочие машины в рабочей сети в нерабочих целях, но кто будет следовать этому глупому правилу? VPN тоже может помочь, если он не на основе SSL.

    UPD: В комментариях натолкнули на мысль, что то же самое может произойти если использовать смартфон «от оператора» с операторской прошивкой — вероятность нахождения на нем по умолчанию доверенного сертификата для всей инфраструктуры оператора близка к 100%.

    Вариант 2: Облачный бесключевой прокси CloudFlare


    Ладно, в первом случае имеется прокси, который стоит в моей конторе и который инициирует соединения от моего имени. Ну да ладно. Во всяком случае, целевой сервер, к которому я подключаюсь должен быть аутентичным — иначе прокси запаникует и не построит до него HTTPS-сессию (если только админы не накосячили с настройкой). В свете недавнего анонса Keyless SSL от CloudFlare, похоже, это уже тоже не факт.

    image

    Технические подробности можно почитать тут. Для нас важно то, что в данном сценарии уже целевой сервер (тот же онлайн-банкинг), оказывается, уже банку не принадлежит! Хорошая новость в том, что он принадлежит кому-то, кому банк доверяет.

    Товарищи из CloudFlare разработали способ представляться HTTPS-сервером заказчика без необходимости подделывать сертификаты или даже подписываться ключами заказчика. По факту, как раз проверка аутентичности проводится с сервером банка, но как только она пройдена — сеанс устанавливается с доверенным сервером CloudFlare. Цель благородна — разгрузка HTTPS-трафика клиентов и защита от DDoS-атак. Сколько времени понадобится на изобретение метода имперсонации целевого сервера без необходимости получать его сертификаты и ключи (или как быстро «органы» разных стран затребуют себе бекдор-доступ) — кто его знает. Надеюсь, достаточно долго.

    Итого


    В, казалось бы, «безопасном от и до» HTTPS соединении могут успешно поселиться как минимум два посредника. Оба должны быть доверенными, но доверяет им ваш админ, ваш босс, ваш банк, ваш магазин — только не вы. Если вы думаете, что в Интернете еще есть 100% приватность — подумайте еще разок.

    А вы знаете какие-то еще методы атак на HTTPS?

    P.S. Оригинал тут.
    Интересно?

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    Метки:
    Поделиться публикацией
    Комментарии 123
    • +6
      Если кто-либо (был прецедент ( www.securitylab.ru/news/405198.php ) предположительно с Иранскими властями) сможет подписывать произвольные сертификаты от имени удостоверяющего центра и вклиниться на пути от вашего компьютера до сервера, обслуживающего атакуемый сайт, то он сможет читать и модифицировать ваш трафик. Угроза не пустая, как минимум правительственные структуры имеют возможность это делать, кроме этого злоумышленники могут взломать удостоверяющий центр.

      Certificate pinning, как я понимаю, пытается защитить от этого класса атак.
      • +3
        На черном рынке найдется все, в том числе зеленый сертификат, были бы деньги.
        Certificate pinning — общее понятие, стандарта нет. Поэтому в зависимости от реализации может пропускать некоторые нежелательные сертификаты.
      • +1
        Ростелеком (онлайм) тоже одно время игрался с фильтрацией трафика из черного списка подменяя сертификат
        • 0
          Правильно ли я понимаю, что если я работаю с сайтом по HTTPS, но мой компьютер находится в домене, то HTTPS прозрачен, и работодатель может спокойно воровать мои приватные данные?
          • +6
            Смотря какие настройки. Посмотрите полученный браузером сертификат — кем он подписан? Для верности зайдите на тот же сайт с мобильника и сравните по fingerprint'у.

            Но я бы так далеко не копал. На вашем компьютере запросто может быть ПО для контроля за продуктивностью, анализирующее все ваши действия.
            • –7
              В Windows или iOS — да, но не в GNU/Linux, так?
              • +1
                С чего вы взяли? Линукс перестал быть ОС?

                Впрочем, если вы самостоятельно ставили ОС и не давали рута корпоративным админам, то вероятность наличия шпионства минимальна. То же относится к винде и любой другой ОС.
                • –10
                  Вот это я и имел ввиду. Конечно же сам, и если в таком случае с Linux и другим open-source ПО все ясно (так или иначе), то с пред-компилированными Windows или iOS, или любым другим проприетарным ПО — нет. Вот почему Richard Stalman называет Windows — malware (в своей основе/по своей природе). Мне с трудом верится, что государственные структуры могут пользоваться Windows или другими не open-source OS.
                  • +11
                    Конечно же сам, и если в таком случае с Linux и другим open-source ПО все ясно

                    В каком месте там что-то ясно? Вы, наверное, имеете в виду глупость про открытые исходники и следующую из этого суперзащищенность, отсутствие или хотя бы минимальное количество експлоитов, бекдоров и любого рода дыр?

                    кхе-кхе-хартблид-хке-кхе
                    Что-то кашель замучил :)
                    • 0
                      Нет, просто Linux на десктопах слабо распространен и писать под него трояны невыгодно.
                      • +1
                        А с каких пор мы говорим о троянах? Вроде речь вообще шла о специализированном ПО для контроля за рабочим местом.
                        • –2
                          Оно должно как-то попасть на компьютер, не так ли? В случае Windows способов масса, они довольно простые, что усугубляется низким средним уровнем навыков компьютерной безопасности у пользователей. Linux или Mac OS X скомпрометировать гораздо сложнее, особенно если речь идет не об атаке на конкретного человека, группу или организацию, а о массовой компрометации. Просто по причине непопулярности. Разумеется, если нацелились конкретно на вас — никакой Linux и вообще ничто вас не спасет: сильно надо будет — взломают.
                          • +5
                            Linux или Mac OS X скомпрометировать гораздо сложнее, особенно если речь идет не об атаке на конкретного человека, группу или организацию, а о массовой компрометации.

                            По-моему, где-то раз в месяц на хабре публикуют експлоиты, позволяющие возвыситься до рута. И это на хабре, не особо специализированном ресурсе.
                            А вообще, смотрите на вебсервера. Заражения там — норма жизни, процент зараженных вызывает тревогу. Причем чаще всего заражают именно опенсорс. Вроде там в процентном соотношении дела обстоят куда хуже, чем у того же IIS.
                            • +1
                              Да тут причина в другмо — в случае с IIS обычно проще использовать уязвимости собственно винды, а не уязвимости жопоруких сайтописателей. Ну и, самые жопорукие сайтописатели используют пыхпых, который конечно тяготеет к линуксу. На asp.net обычно всё-таки жопорукости меньше. Кстати, заражённые вебсерверы обычно заражены «не совсем», а всё-таки только юзерспейс (а эксплоиты рутовые нечасты, обычно они роняют систему в панику, а не дают рута), что совершенно не верно в типовом случае заражённой винды.
                              • 0
                                Я не говорю, что эксплойтов не существует. Я говорю, что массовые заражения десктопов (а полезные нагрузки у десктопного и серверного зловреда принципиально разные) — экономически невыгодны ботоводам, и, следовательно, риск заражения гораздо меньше.
                                • +1
                                  Замечательно. Но опять же, почему тема перешла на обсуждение зловредов?
                                  • 0
                                    Потому, что конкретно мой компьютер никому не нужен, а вот если таких компьютеров будет штук тысяча, и на каждом провести Man-In-The-Browser — это совсем другой разговор. Локальные эксплойты на десктопе не несут угрозы пользователям. Угрозу несут именно зловреды.
                                    • +3
                                      А почему я за много лет не видел ни одного зловреда?

                                      На винду они, кстати, почти всегда проникают методом двойного клика и подтверждения в UAC со стороны пользователя. Кстати, какие-то линуксовые репы когда-то тоже заражали.

                                      Да и вообще… www.linux.org.ru/forum/development/392747
                                      • 0
                                        А почему я за много лет не видел ни одного зловреда?
                                        Плохо искали.
                                        На винду они, кстати, почти всегда проникают методом двойного клика и подтверждения в UAC со стороны пользователя.
                                        Не все, особенно на XP (которую многие отдельные одаренные личности вовсю используют).
                                        Да и вообще… www.linux.org.ru/forum/development/392747
                                        Баян. Чтобы запустить такое под рутом — надо быть идиотом.
                                        • +1
                                          Чтобы запустить такое под рутом — надо быть идиотом.

                                          А еще надо быть идиотом, чтобы дать права локального админа недоверенному софту. Или (за редкими исключениями) чтобы до сих пор работать на ХР, да еще и под админской учеткой.
                                          • 0
                                            Это достаточно, но не необходимо для многих зловредов.
                                            • 0
                                              Этот способ настолько прост и эффективен с точки зрения массового заражения, что другие обычно не особо и нужны. Против него нет защиты, нельзя пропатчить ДНК пользователя.
                                              • 0
                                                При таком подходе можно вообще забить на защиту.
                                        • +3
                                          UAC они уже давно не просят, нафига им полный доступ? Файлики потырят, зашифруют и деньги попросят, им для этого не надо никаких полномочий кроме пользовательских.

                                          А вообще надо mandatory access control внедрять в массы.
                                          • 0
                                            Это — один класс зловредов. А другой пропишет себя в файлике hosts, чтобы перенаправить к себе адресованный вконтактику трафик.
                                • +1
                                  Тут как раз все просто:

                                  1. Компания заботиться о своей корп безопасности, вы рядовой сотрудник => у вас будет или windows или Linux со спец софтом, без него в корпоративную сеть не пустят

                                  2. Компания заботиться о своей корп безопасности, вы доверенный сотрудник => у вас может быть Linux без спец софта, за вашей лояльностью будут следить другими средствами, не связанными с мониторингом сетевой активности (тупо камера наблюдения за спиной).

                                  3. Компания не заботится о своей безопасности: широкий спектр степени сетевого бардака.

                                  Собственно устойчивость той или иной ОС к троянам/бекдорам/активным мониторам рабочего места тут вообще не причем.

                              • –6
                                Такая жалость, что Linux на десктопах слабо распространен. Когда я перешел на Fedora Linux больше года назад, спустя 3 месяца, я не мог поверить что так все правильно, логично и понятно устроено и работает/взаимодействует. Поправде говоря, сегодня мне не хватает одной единственной программы — Photoshop. Все остальное — на две головы выше. Очень рекомендую Fedora GNU/Linux — лучшая OS по-моему мнению.
                                • 0
                                  Пользуюсь федорой и рад, что она слабо распространена. Исключительно из соображений безопасности. Дыр хватает и там и там, но под Linux их гораздо меньше эксплуатируют.
                              • –4
                                Да, HeartBleed — это позор. Мне досих пор кажется, что это сделанно намеренно. А ясно с open-source то, что вы и тысячи друих разработчиков можете посмотреть програмный код — это и ясно. А защищенным может быть как open-source ПО так и проприетарное. Просто в случае проприетарного софта вероятность вмешательства третих лиц (например АНБ) для установки malware гораздо выше, чем в open-source. В случае с open-source — community просто не допустит такого.
                                • +4
                                  В случае с open-source — community просто не допустит такого.

                                  Ну вы же сами упомянули эпичный баг. А OpenSSL — исключительно широко используемая, в том числе крупнейшими компаниями в коммерческом ПО, библиотека. Ну и много ли там насмотрели независимые исследователи? Нет, в итоге, конечно, спустя два года, нашли… А может, и не нашли, просто кто-то сдал им этот баг.
                                  А ясно с open-source то, что вы и тысячи друих разработчиков можете посмотреть програмный код — это и ясно.

                                  Между «могу просматривать» и «буду просматривать» зияет колоссальная пропасть. Обычно у людей найдутся более интересные занятия, чем построчно анализировать десятки тысяч строк кода (можно смотреть даже на куда более менее элегантную, чем heartbleed, дыру, и не видеть ее). Особенно если код — опенсорс, но в основном развивается не сообществом, а конкретными лицами, а такое сплошь и рядом. Вон Truecrypt опенсорс, но до сих пор никто не понимает, есть в нем закладки или нет. Даже специализированных аудиторов нанимали.
                                  Просто в случае проприетарного софта вероятность вмешательства третих лиц (например АНБ) для установки malware гораздо выше, чем в open-source.

                                  Heartbleed был вроде коммитом от третьего лица. А вы можете сделать коммит в ядро Windows?
                                  Опенсорс вообще жив благодаря непрерывному участию третьих лиц в собственном развитии.
                                  • +1
                                    Вы в целом конечно же правы, но если выбирать, то я бы все равно выбрал бы open-source, куда все мы можем сделать коммит.
                                    • 0
                                      А вы можете сделать коммит в ядро Windows?

                                      А сколько эпичных багов в винду было сделано родными разработчиками?

                                      Heartbleed был вроде коммитом от третьего лица.

                                      Интересно, как в закрытый RSA Security внедрили «люк» в код ГПСЧ, чтоб он стал более предсказуемым? И если опенсорц рано или поздно выявил это (тем более, что на openssl свет клином не сошёлся — куча решений используют другие библиотеки — надо перечислить?), случай RSA проявился только благодаря утечке данных спецслужб — считай, просто случайно повезло.
                                      • 0
                                        Ну на Dual_EC_DRBG свет тоже клином не сошелся. ГПСЧ вообще очень сложная и больная тема современной криптографии. Там задействован матан, доступный единицам, и очень сложно доказать для него достаточность генерируемой им энтропии. Dual_EC_DRBG ведь тоже все тесты прошел… Заподозрили его в основном из-за того, что предложен он был NSA, и все равно до сих пор нет однозначных доказательств его компрометации.
                                        • 0
                                          и очень сложно доказать для него достаточность генерируемой им энтропии

                                          строго говоря, именно доказать невозможно никак, и вот как раз это доказано
                                          • 0
                                            Строго говоря, я говорил про «достаточность», а не про действительную энтропийность как у квантового ГСЧ :) Dual_EC_DRBG ведь сам по себе был неплохим (разве что тормозной). Проблема в том, что кто-то теоретически мог обладать информацией для достаточно точного предсказания следующих цифр на основании предыдущих цифр.
                                        • 0
                                          Вообще «если у вас нет паранойи, то это не значит что за вами не следят.»

                                          Есть уверенность что кроме Heartbleed нет других закладок?

                                          Сложность и количество кода библиотек и всей ОС в целом практически исключает полноценный аудит. Проверить отсутствие известных косяков можно… Но неизвестных — практически нереально.
                                  • +1
                                    OpenSource/не OpenSource, а если багу найдут, то и в GNU/Linux могут руткит подсунуть так, что и не заметите.
                                    А с учетом развития аппаратных атак (та же недавняя BadUSB или более старые версии с PCI-контроллерами), ОС вообще не фактор.
                                    Да и в случае персонального ПК, если это не BYOD-система, корпоративный прокси уже будет не Trusted, и сценарий #1 не прокатит, так что не вижу повода обсуждать тут эту тему.
                            • +5
                              При работе с важными данными (например тот-же онлайн банк), нужно иметь полезную привычку заглядывать в информацию о сертификате для https-сессии, перед тем как вводить пароли.
                              • 0
                                Постепенный ввод принципов BYOD это становится все менее актуальным.
                                • +3
                                  Фингерпринты всё равно не запомните, а назвать свой CA можно как угодно.
                                  • –1
                                    какие-нибудь уникальные красивые 4 цифры фингерпринта вполне достаточно для «ручной проверки» их и запомнить не влом.
                                    • 0
                                      Проще заходить в ИБ с телефона.
                                      • 0
                                        А если мобильный провайдет тоже занимается такой фигнёй? Или еще хуже… договор с работодателем чтобы заворачивать весь мобильный трафик сотрудников(номера телефонов со временем очень быстро палятся и привязываются к сотрудникам) на ихний проксик… думаешь, такое в принципе невозможно?
                                        • +1
                                          Ставить сертификат корпоративного CA на личный телефон не заставят, а без него он будет ругаться на подмену.
                                          • 0
                                            Ну да, ругаться будет… тебе от этого станет легче?
                                            • 0
                                              Я не стану вводить логин/пароль.
                                              • 0
                                                Если это хоть немного массовая практика, нашлись бы пользователи, собравшие доказательства (дампы сессий и т.п.) и выложившие их на том же Хабре. Скандала не избежать.
                                  • +1
                                    HTTPS не прозрачен, просто вместо онлайн-магазина вы можете общаться с прокси работодателя. А от него идет сессия до магазина. Что прокси делает с вашими данными — одному прокси известно. Могут банально утекать из-за кривой настройки :)
                                    Но, в принципе, получается, что приватными вещами лучше заниматься с приватного устройства.
                                    • +2
                                      Конечно, поскольку админы домена могут с вашим компьютером сделать всё, что угодно, вплоть до подмены WinInet-библиотеки для IE, установки кастомного модифицированного Chrome, который будет верить всем, установки локальных снифферов\троянов и т.д. На то и админы.
                                      • НЛО прилетело и опубликовало эту надпись здесь
                                      • 0
                                        Обычно подменяют сертификаты и если уж рядовые обыватели устанавливают вирусы на Android, то на такую «мелочь» они точно не обратят внимание.
                                        • +12
                                          Вообще-то идея CloudFlare немного в другом. Традиционно, для организации SSL соединения требуется, чтобы на сервере присутствовал приватный ключ сертификата. И этот ключ используется только во время установления сессии и генерации временных ключей шифрования, которые в дальнейщем используются. Так вот ребята из CloudFlare предложили не хранить приавтные ключи на своих серверах, а передавать начальный зашифрованный handshake на специальный сервер заказчика для дешифровки/шифровки. Таким образом приватный ключ никогда не покидает сервер заказчика и позволяет масштабировать SSL фронтенды в облаке без передачи приватного ключа в облако.
                                          • 0
                                            Ну да, идея была в том, чтобы разгрузить каналы клиентов.
                                            Но ведь облако (CDN) уже принадлежит CloudFlare, а не клиенту?
                                            • +1
                                              Да, разумеется. Естественно, остается вопрос доверия собственно серверам CloudFlare.
                                              Но прелесть Keyless SSL в том, что на frontend HTTPS серверах _нет_ приватных ключей.
                                              Что сильно уменьшает риск из утечки.
                                              • 0
                                                Это да — в этом вся суть!
                                                Теперь вопрос: как быстро кто-то сумеет это проломить и имперсонивать CDN-сервер CloudFlare для back-end сервера, хранящего ключ. :) В конце концов, целью атаки являются данные. Если их можно получить без ключей — какая разница?
                                                • +3
                                                  А вот в этом и заключается работа и ответственность CloudFlare, чтобы их не подломили и не имперсонировали. :)
                                                  • 0
                                                    Оно-то да, но мне, как «потенциальному потерпевшему» от этого не легче :)

                                                    Возвращаясь к сценарию онлайн-банкинга: если HTTPS действительно 100% надежен между двумя конечными точками, то если меня хакнут и уведут деньги с аккаунта, путей атаки может быть только два:
                                                    1. Хакнули мой компьютер — сам виноват (только не надо поднимать тему с дефектами закрытого ПО и т.д. — там всё прикрыто, и в итоге всё равно пользователь сам виноват).
                                                    2. Хакнули банк. Тут вероятность вернуть деньги за счет банка близка к 100% (если только банк не пошел ко дну в результате массового взлома :) ).
                                                    Таким образом, все факторы или под моим контролем, или не несут серьезного ущерба — мне, как пользователю онлайн-банкинга особо страшиться нечего (именно поэтому, даже когда начались массовые хаки кредитных карт в США, уж сколько лет назад, они не перешли на чипы: банкам дорого, а пользователям все компенсируется).

                                                    А вот теперь, давайте включим в HTTPS-цепочку еще двух посредников, и спросим у банка, компенсируют ли они потери, если сессию уведут из-за криворукости админа на работе или косяка в CloudFlare (или какого-нибудь хитрого отвода трафика от их CDN через очередной BGP-poisoning)? Как вы считаете, какова вероятность вернуть деньги в подобном случае, и что на это ответят на работе и в CloudFlare? :)
                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                    • 0
                                                      Да, это решит проблему утечки ключей. Но если данные удастся получить без ключей (см. собственно комментарий, на который вы отвечали), то какая разница? Ну недоступен ключ, и не очень-то и хотелось.
                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                            • +1
                                              Нельзя доверять всем «доверенным» ЦС. Доверять можно только тем ЦС, чьи сертификаты ты установил в систему сам.
                                              • +1
                                                Помотрите, сколько доверенных сертификатов стоит по умолчанию в Windows, iOS, Android. :)
                                                На Android до 4.х нельзя было даже с ними ничего сделать — все сертификаты были R/O.
                                                • +1
                                                  Verisign доверяете? А Comodo?
                                                  • 0
                                                    я понимаю, к чему вы клоните

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

                                                    Конечно я предпочёл бы, чтобы сертификаты мне принёс специальный сотрудник на флешке, и мы с ним подписали бы определённые бумаги, но к сожалению у меня нет выбора. Единственное, что немного успокаивает — внедриться хотя и можно, но невероятно трудоёмко.
                                                    • +6
                                                      Если никогда ранее не общавшиеся Alice и Bob хотя конфиденциально перекинуться парой слов, не затрачивая на это непропорциональные усилия, то, в общем-то, у них два варианта.
                                                      1) Их сводит вместе авторитетное лицо, которому они оба доверяют. См. текущий PKI.
                                                      2) Толпа народу голосует по поводу того, являются ли они теми, за кого себя выдают. См. Bitcoin и тому подобное.

                                                      Оба подхода имеют свои проблемы… А то, что вы предлагаете, это третий вариант (изолированный, заранее защищенный канал связи с независимой аутентификацией сторон), который приводит к колоссальным неудобствам, так как курьер вам потребуется для каждого посещаемого вами сайта, и даже это не гарантирует, что кто-то не скоммуниздит у владельца сайта приватные ключи.
                                                      • 0
                                                        Нет, вы не поняли. Курьер мне нужен, чтобы он доставил мне ключи СЦ. Если они будут доставлены и переданы мне надлежащим образом, я смогу им доверять, примерно как своим собственным СЦ.

                                                        Ключам СЦ, полученным из интернета по HTTP, я не доверяю. А они сейчас все на поверку именно такие.

                                                        Имея РЕАЛЬНО доверенные СЦ, я смогу проверять уже сайты, которым сертификаты выдали эти СЦ.
                                                        • 0
                                                          Вы можете доверять ключу но не SC. Т. к. никакой гарантии, что злоумышленник не обладает доступом к секретному ключу нет.
                                                          • 0
                                                            Разумеется. Поэтому я своим СЦ доверяю больше. Тем не менее, сейчас у меня нет даже уверенности, что имеющиеся у меня сертификаты СЦ — подлинные. Будет хотя бы эта. СЦ декларируют, что надёжно хранят свои ключи, а под «подписать определённые бумаги» я имел ввиду именно какую-то форму договора с СЦ, что в случае компроментации ключа они несут ответственность.

                                                            А чего они хотели, воздух продавать и не нести ответственность в случае лажи?
                                                            • +1
                                                              А чего они хотели, воздух продавать и не нести ответственность в случае лажи?
                                                              Увы, большинство интернет-безопасников работают именно по этому принципу.
                                                              • 0
                                                                Я не зря упомянул Comodo. Вроде их спалили как-то раз на выдаче сертификатов спецслужбам…
                                                                • +1
                                                                  Есть мнение, что все они там такие. Просто не все спалились. Если бы на этом рынке была реально конкуренция, этот фейл комоды давно бы раздули до размеров вселенной и слили бы их к чертям — так нет же, живы-здоровы.
                                                  • +1
                                                    Именно так проверяют HTTPS трафик DLP. Так что это не совсем уязвимость. Вполне себе документированные особенности :)
                                                    • +1
                                                      А где сказано «уязвимость»? :) Скорее «блаженное неведение» множества пользователей…
                                                    • +5
                                                      Кого из крупных ЦС там ловили на выдаче сертификата на домен "*", т.е. на все домены?

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

                                                      Я к тому, что сколько еще не пойманных „доверенных“ товарищей что-то подобное делало? И это, заметьте, практика вполне легальная (по заверению той, проштрафившейся, компании-ЦС), мол, для in-house использования, и только серьезным клиентам. Я лично гроша не поставлю на то, что запрос от „органов“ они не выполнят из-за несерьезности „заказчика“.
                                                      • +3
                                                        Поискал, нашел один из таких случаев — когда поймали за руку Trustwave. Они не выдавали сертификат на "*", это я ошибся, они выдали вторичный корневой сертификат, которым можно подписать сертификат для любого домена. Объяснения компании свелись к тому, что он был нужен для системы проксирования и перехвата трафика:

                                                        The system was created using dedicated hardware device designed for SSL proxy and acceleration, with a FIPS-140-2 Level 3 compliant Hardware Security Module (HSM) (http://en.wikipedia.org/wiki/Hardware_security_module) for subordinate root storage and for the purpose of private key generation of the re-signed SSL certificates. This means that once the trusted subordinate root was placed into the device it could not be extracted.

                                                        (отсюда — blog.spiderlabs.com/2012/02/clarifying-the-trustwave-ca-policy-update.html )

                                                        (Mozilla тогда рассматривала вопрос об исключении корневого сертификата Trustwave из своего списка корневых. Источник: www.opennet.ru/opennews/art.shtml?num=33034 )
                                                        • +1
                                                          Может быть я чего-то не понимаю, но у того же Гугла тоже есть свой подчинённый CA, который может подписывать любые сертификаты. А в хранилище сертификатов Firefox оказался сертификат (!) РуЦентра, так что ФСБ давно может читать наш трафик.
                                                          • +2
                                                            К сожалению, да, и это то, что мне всегда в схемах доверия https не нравилось: можно верить https-защите не более, чем веришь корневым сертификатам, а также своей машине или ПО на ней, хранящей эти корневые сертификаты. Если вирус впишет мне сертификат каких-то негодяев, то они смогут MITM реализовать при полной моей уверенности в безопасности.

                                                            Уместно привести слова Шнайдера, что, мол, я плачу картой через интернет не потому, что верю, что https меня убережет на 100% или что https как-то гарантирует, что меня не обманет сам магазин, а потому, что в случае косяка магазина за это ответит Visa, которая вернет деньги, а потом разберется с магазином.
                                                      • 0
                                                        А если напечатать fingerprint сертификата прямо на банковской карте и проверять вручную, это спасет от TMITM?
                                                        • +5
                                                          Вы изобрели certificate pinning.
                                                          Там свои недостатки. Допустим, надо сменить сертификат…
                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                        • 0
                                                          MS TMG из коробки занимается перехватом SSL (называется ssl inspection), и он по умолчанию включен. Целенаправленно пока не учил его выпускать сертификаты с ГОСТ-ключами.
                                                          • +1
                                                            А объясните плиз тем, кто в танке, как прокси может врезаться в мой трафик, если при HTTPS браузер шлет HTTP CONNECT на 443, а прокси только поднимает TCP туннель? Много раз смотрел tcpdump'ом и не видел других сценариев работы. Как оно еще работать может?
                                                            • 0
                                                              А ты и не увидишь. Проксик внешне для приложения прикидывается шлангом, будто он работает прозрачно… все мутки происходят на другом уровне — уже внутри установленного канала SSL, а проксик является одной из первых точек входа в этот канал…
                                                              • 0
                                                                То есть по факту давно можно влезать в любое SSL соединение?
                                                                • +1
                                                                  Не в любое. Только если у клиента есть сертификат того кто производит инспекцию. Т.е. корпоративная среда где пользователь не волен в выборе рабочего софта под это определение подходит.
                                                                  • 0
                                                                    Это если винда, IE и руками поставленный левый сертификат. Если у меня другой браузер или линух, то левак мне уже просто так не посунуть. Получается, что это не чистый MITM, а административно настроенный. Я правильно понял?
                                                                    • +1
                                                                      Да. Даже если у вас руками поставленный левый сертификат, всегда можно проверить fingerprint. В большинстве случае достаточно простого захда из дома/с мобильника, запоминания пары первых-последних блоков fingerprint и проверки их на рабочем ПК.
                                                                      • 0
                                                                        Спасибо, значит все примерно так, как я и думал.
                                                                  • 0
                                                                    Ну как давно… примерно с момента разработки SSL соединений)
                                                                    • 0
                                                                      а можно тогда ссылочек на тулзы для SSL MITM?
                                                                      • 0
                                                                        А текст статьи внимательно читали?
                                                                        • 0
                                                                          Да, если правильно понял, там ссылка на HTTP прокси, который надо поставить и заставить клиента через него работать. А бывает именно MITM для SSL на роутере?
                                                                          • 0
                                                                            если роутер/firewall поддерживает подобную функциональность. Иначе — вряд ли.
                                                                • +2
                                                                  Браузер шлет CONNECT на mybank.com/443
                                                                  Пакет перехватывается TMITM прокси
                                                                  Прокси отвечает «я твой банк»
                                                                  Браузер строит сессию до прокси
                                                                  Прокси строит сессию до банка

                                                                  Но походу вместо одной сессии «браузер-банк» имеем ДВЕ сессии «браузер-прокси» и «прокси-банк». Что прокси делает с трафиком — известно лишь прокси.
                                                                  Аналогично, может оказаться, что сессия вообще выглядит как «браузер<->прокси<->CloudFlare CDN<->Back-End банка» — т.е. в наличии уже ТРИ сессии и два некотролируемых посредника.

                                                                  А юзверь всё думает, что он сидит напрямую в банке и всё очень приватно.
                                                                  • +1
                                                                    Только по идее браузер юзера должен завопить на сертификат
                                                                    • +1
                                                                      в том-то и дело, что не вопит, т.к. прокси подсовывает динамически выписанный доверенный сертификат
                                                                      • 0
                                                                        он доверенный только в случае ручной установки на клиента
                                                                        • +2
                                                                          Он доверенный в случае если подписан ЦС, который является доверенным у клиента (сертификат ЦС установлен в хранилище клиента). Откуда у клиента сертификат нашего ЦС — вопрос второй. Например, если клиент — компьютер домена, это можно сделать средствами самого домена.
                                                                          • 0
                                                                            Ну я это и имел в виду под «ручной» установкой. Надо как-то правдами или неправдами забить в клиента CA от MITMProxy, иначе ничего не получится.
                                                                            • 0
                                                                              вы точно статью полностью прочитали?
                                                                    • 0
                                                                      Только один нюанс — в случае с CloudFlare соединение «прокси->CloudFlare» контролируется банком.
                                                                      • 0
                                                                        Это соединение не может контролироваться банком, т.к. банк не в состоянии контролировать ни прокси моего работодателя/оператора (пользуемся лочеными телефонами с операторскими прошивками?), ни CloudFlare, ни Интернет между ними. Банк просто «подписывается» за сервер CloudFlare, разрешая тому выступать в роли HTTPS-фронтенда банка.

                                                                        Дальше вопрос выходит из технической плоскости в организационную: банк может заключить с CF некий контракт с SLA и компенсациями, но контролем я бы это не называл. Если что-то навернется или утечет по вине CF — банк этого предотвратить не сможет.
                                                                        • 0
                                                                          Каждое входящее соединение в CloudFlare передается в банк для подписи. Банк уже решает, что с ним делать. В какой-то степени это уже контроль.
                                                                          Т.е. банк своей подписью подверждает свою ответственность за контент.
                                                                          • +1
                                                                            Банк не может отказаться подписать подключение.
                                                                            Предположим, на сервере CloudFlare завёлся троян, который принимает подключение от пользователя, подписывает его на сервере банка. Банк не знает, какая информация передаётся между клиентом и CF, хотя клиент видит, что соединение авторизовано банком.
                                                                            • 0
                                                                              Дайте мне тот банк, что не глядя подписывает все бумаги! :)
                                                                              А если серьезно, в этом случае мне, как клиенту, глубоко фиолетово, троян это на CF, или подломили сам банк. Печать банка стоит? Стоит.
                                                                              Банк несет ответственность.

                                                                              А вообще, обезопасить связку CF <-> банк гораздо проще, чем общедоступный HTTPS сервер. Навскидку могу предложить статический реверс-прокси в read-only докере и VPN по бронированому кабелю до банка. Даже если удастся получить доступ к файловой системе контейнера, злоумышленнику это ничего не даст. Посадить трояна он не сможет, прикинуться сервером CF тоже не сможет. Приватного ключа банка на сервере тоже нет. Тупик.
                                                                              • +1
                                                                                А если серьезно, в этом случае мне, как клиенту, глубоко фиолетово, троян это на CF, или подломили сам банк.

                                                                                Тогда вам глубоко фиолетова темя обсуждения — увеличивается ли кол-во уязвимых точек.

                                                                                Печать банка стоит? Стоит. Банк несет ответственность.

                                                                                Юридически сертификат на SSL-соединении ничего не значит. Банк может компенсировать всё, чтобы не терять репутацию, но при желании может от вас отмахнуться. С чем вы пойдёте в суд? Со словами, что выходили на сайт с подписанным соединением? А банк скажет — я это соединение не видел со своей стороны. Потребуется расследование и если найдут виновника, он вам возместит ущерб, если сможет.

                                                                                Посадить трояна он не сможет, прикинуться сервером CF тоже не сможет. Приватного ключа банка на сервере тоже нет. Тупик.

                                                                                Если бы вы были админом, который управляет всеми этими контейнерами, тогда что — тоже тупик? А если его рабочее место взломают и будут полгода наблюдать, как он работает, где какие пароли, куда пишутся логи? Причём взломают не из сети, а аппаратными закладками на клавиатуру/дисплей.
                                                                                • +1
                                                                                  Юридически сертификат на SSL-соединении ничего не значит. Банк может компенсировать всё, чтобы не терять репутацию, но при желании может от вас отмахнуться. С чем вы пойдёте в суд? Со словами, что выходили на сайт с подписанным соединением? А банк скажет — я это соединение не видел со своей стороны. Потребуется расследование и если найдут виновника, он вам возместит ущерб, если сможет.

                                                                                  Т.е. вы считаете, что банк соединение подписал, но ответственности не несет? Это как? Я не специалист в юрисдикции, но здравый смысл подсказывает, что тут что-то не так.

                                                                                  А вообще, естественно, 100% надежных систем не бывает. Вопрос только в количестве усилий необходимых для преодоления защиты.
                                                                                  • +1
                                                                                    Я не специалист в юрисдикции, но здравый смысл подсказывает, что тут что-то не так.

                                                                                    Для юристов все эти SSL-и — непонятные гиковские игры. Есть федеральный закон 63 об ЭЦП, который определяет порядок работы с подписями. Всё должно быть сертифицировано (у вас система и браузер наверняка не сертифицированы по всем требованиям, поэтому заявления, что вы произвели проверку подписи, не внушают доверия).

                                                                                    И самое главное — статья 12 пункт 2.1:
                                                                                    При создании электронной подписи средства электронной подписи должны показывать лицу, подписывающему электронный документ, содержание информации, которую он подписывает

                                                                                    Это значит, что никакая штамповка подписей на автомате не признаётся юридически. Должно быть лицо, проверяющее каждый документ перед подписью, и несущее ответственность за содержимое.

                                                                                    Да и, по хорошему, ответственность несёт не только банк, но и вся цепочка сертификации. А если ответственность размыта (да ещё и между гос. организациями), но и ни с кого взыскать ничего нельзя, пока не будет доказана вина конкретной стороны.
                                                                                • +1
                                                                                  Печать банка стоит? Стоит.

                                                                                  Я бы посмотрел, как вы эту «печать» будете в суде предъявлять, и что вам ответят на это.
                                                                                  Особенно с учетом того, что ломать вас будут явно не во время вашего соединения с банком. Самый простой вариант — вашу сессию перехватили и мониторят, вы работу закончили, нажали «Logout», вам страничку Logout'а показали (но с прокси) — и понеслось… В следующий раз вы логинитесь через неделю и наблюдаете картину: на сбер счетах нули, на текущих минмальные остатки (чтобы жертва не получила алерт стразу после хака, а чуть позже) и три ипотеки :)
                                                                                  Что будете предъявлять? Подписанные и проштампованные распечатки скриншотов дампов всего трафика с прошлой недели?

                                                                                  А вообще, обезопасить связку CF <-> банк гораздо проще, чем общедоступный HTTPS сервер.

                                                                                  Конечно, но вы забываете, что «общедоступный HTTPS сервер» никуда не делся, и его всё еще необходимо защищать — просто теперь от стоит на площадке CloudFlare, а не банка. Так что теперь вместо одного элемента нужно защищать как минимум два. И как минимум над одним из них банк не имеет контроля и значит, скорее всего, «ответственности не несет».
                                                                                  • 0
                                                                                    Хорошо, а посмотрим на это с другой стороны.
                                                                                    Вот я пришёл в банк и положил 300.000 руб. Это зафиксировано на видеокамерах, есть свидетели, и у меня есть квитанция на руках.
                                                                                    Потом меня хакнули, деньги сняли. Как банк докажет, что денег на моём счету больше нет.
                                                                                    • 0
                                                                                      Всё будет не так: как вы докажете банку, что это вас хакнули по их вине/недосмотру, а не вы сами перевели куда-то деньги и теперь пытаетесь развести банк на бабло?
                                                                                      • 0
                                                                                        У меня есть квитанция на внос денег на счёт, но нет квитанции на вывод.
                                                                                        Чем банк докажет, что операция вывода вообще была проведена через браузер?
                                                                                        • 0
                                                                                          Своим логом, в котором написано, что пользователь Х, авторизованный согласно процедурам, и потому идентифицированный и аутентифицированный как клиент Вася Пупкин, через онлайн-банкинг попросил банк перевести Y денег на счет Z.
                                                                                          Проблема как раз будет на вашей стороне — доказать банку, что имел место, скажем, увод сессии, и это у них уязвимость, а не у вас преступный умысел.
                                                                                    • 0
                                                                                      Для определенности будем считать, что в нашем гипотетическом случае всё действует по законо «как оно должно быть», иначе смысл во всей этой возни с сертификатами теряется.
                                                                                      Особенно с учетом того, что ломать вас будут явно не во время вашего соединения с банком. Самый простой вариант — вашу сессию перехватили и мониторят, вы работу закончили, нажали «Logout», вам страничку Logout'а показали (но с прокси) — и понеслось…

                                                                                      Существует возможность перехвата активной SSL сессии? В чем тогда вообще смысл шифрования трафика? Ладно. Допустим.
                                                                                      Что будете предъявлять? Подписанные и проштампованные распечатки скриншотов дампов всего трафика с прошлой недели?

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

                                                                                      Т.е. банк открытым текстом говорит — «да, мы подписали вашу сессию с вот этим сервером, но мы не знаем, что там на сервере и знать не хотим»? И кто после этого останется в клиентах этого банка? Даже если юридически придраться невозможно.

                                                                                      А вообще, изначальный смысл моего комментария заключался в том, что я хотел акцентировать, что в предложенная CF схема лучше традиционной схемы фермы HTTPS-фронтендов, где каждый фронтенд имеет свою копию приватного ключа и сам пописывает все сессии. И тут, в случае взлома одного из фронтендов, получается полная свобода — есть приватный ключ и можно развлекаться. А здесь надо еще дополнительно обмануть и центральный подписывающий сервер.
                                                                                      • 0
                                                                                        Существует возможность перехвата активной SSL сессии

                                                                                        Вообще-то, статья о том, что можно в сессию вставить два TMITM-proxy да так, что рядовой юзер и не заметит…

                                                                                        Конечно, с точки зрения обеспечения безопасности ключей, схема хороша. Обманывать сервер не придется, если получится взломать прокси. Ведь сервер доверяет прокси. И юзер доверяет прокси. И не надо никаких сессий перехватывать — сессия заказчивается на прокси.

                                                                                        А вот с точки зрения возможных проблем с компенсацией ущерба — неоднозначно. Но вам, гипотетически, волноваться не о чем, пока всё работает «как оно должно быть». Надеюсь, ваше «как оно должно быть» совпадает с мнением банка :)
                                                                                        • 0
                                                                                          Вообще-то, статья о том, что можно в сессию вставить два TMITM-proxy да так, что рядовой юзер и не заметит…

                                                                                          Именно, и тут я полностью согласен. Вопрос только считать CF как TMITM или как end-point. СF декларирует свою услугу как end-point.
                                                                                          А уж доверять им или нет — каждый сам себе буратино.
                                                                                          • 0
                                                                                            Клиентов никто не спросит, доверяют ли они CF.
                                                                                            Просто однажды фронт-энд банка переедет в облако.
                                                                                            Адрес страницы не изменится, дизайн страницы тоже.
                                                                                            • 0
                                                                                              Вопрос доверяют ли они банку, который переводит свои фронтенды в CF
                                                                                              Или банк и этот процесс не контролирует?
                                                                                              • +1
                                                                                                Вы когда-нибудь получали письмо от банка «Уважаемый клиент, наш HTTPS-фронтенд переехал в облако CloudFlare. Если вы не знаете, что такое HTTPS, фронт-енд или Cloudflare — на сайте банка вы можете скачать небольшой учебник по проектированию, поддержке и обеспечению безопасности распределенных высоконагруженных систем клиент-банк с учетом последних веяний мод в законодательстве. Спасибо за внимание, с любовью...»

                                                                                                Скорее будет так: при следующем логике в клиент-банк попросят принять новые правила пользования, которые никто не читает (вы читаете?). А потом будет поздно :)
                                                                                                • 0
                                                                                                  Т.е. банк подтверждает, что несмотря на то, что сессии подписаны его сертификатом, он не гарантирует достоверность данных переданных в этой сессии?

                                                                                                  А зачем тогда вообще вся эта морока с сертификатами, если они _по определению_ не гарантируют достоверность и владелец ключа не отвечает за содержимое подписанных им сессий?
                                                                                                  • 0
                                                                                                    Сертификат нужен, чтобы скрипт-кидди не включился в разрыв LAN-кабеля на чердаке и не увёл деньги.
                                                                                                    Если у тебя триллионы миллиардов на счету, не подключай онлай-банкинг, управляй счётом более безопасно.
                                                                                                    Затем же обфусцируют код программ, шифруют. Хотя всё равно сломают. Просто стоимость взлома сильно увеличивается.
                                                                                                    • 0
                                                                                                      А зачем тогда вообще вся эта морока с сертификатами

                                                                                                      Я понимаю ваше искреннее недоумение и недовольство порядком вещей, но мир сложился именно так. Если вам не нравится — начинайте мир менять, только не надо жаловаться мне — от этого мир не изменится :)
                                                                                                      • 0
                                                                                                        «сам дурак» — лучший аргумент в любой дискуссии. ок. закончим на этом.

                                                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.