Безопасность (шифрование) трафика

    SSLПараллельно с развитием технологий защиты интернет-трафика от несанкционированного доступа развиваются и технологии перехвата защищенного трафика. Перехватить и изучить незашифрованный трафик пользователя уже давно не составляет труда даже для рядового юзера. Практически каждому известно слово «сниффер». Теоретически, защищенные SSL/TSL-соединения перехватить обычными средствами невозможно. Но так ли это?

    На самом деле — не совсем так. Да, зашифрованный трафик теоретически невозможно расшифровать, хотя опять таки теоретически при очень большой необходимости и желании, и такой трафик можно расшифровать, подобрав ключ. Однако для этого нужны такие затраты ресурсов, что актуальность взлома сохраняется только, наверное, на правительственном или военном уровне :)

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

    А как они это делают? Обычно — по тому же каналу, по которому далее будет идти защищенный трафик. Причем обмен ключами происходит в открытом режиме. В случае HTTPS ключ сервера связан с сертификатом, который пользователю предлагается просмотреть и принять. И вот этот сертификат как раз и может перехватить любой промежуточный сервер, на пути которого идет сертификат в открытом виде (прокси, роутер).

    Чтобы далее «читать» весь трафик пользователя, промежуточный сервер подменяет сертификат на свой. Т.е. он просто сам подключается к клиенту со своим сертификатом, и в то же время подключается к удаленному серверу. Клиенту приходит «левый» сертификат от сервера-злоумышленника, а браузер сообщает пользователю об опасности (такие сертификаты всегда не подписаны). У пользователя остается выбор: принять сертификат и работать с сайтом, либо отказаться его принимать, но и работать с сайтом тогда уже не получится. Иногда пользователи вообще игнорируют содержимое сертификатов и машинально принимают любые переданные им.

    Если пользователь принимает сертификат-подделку, то трафик будет идти по следующей схеме:

    клиент <= SSL-соединение => сервер-прослушка <= SSL-соединение => сервер назначения

    Т.е. промежуточный сервер будет получать весь ваш «защищенный» трафик в открытом виде. Стоит также заметить, что передача сертификата происходит в начале каждой сессии HTTPS.

    В случае защищенного SSH при первом соединении с сервером на клиенте сохраняется ключ сервера, а на сервере — ключ клиента. Эти ключи передаются между данными клиентом-сервером только один раз, при первом подключении. Если в этом случае SSH-трафик попытаются перехватить, то и клиент, и сервер откажут в соединении из-за несоответствия ключей. Так как ключи можно перенести между клиентом и сервером обходным путем (по защищенному каналу или на внешнем носителе), этот способ соединения является относительно безопасным. Его могут лишь заблокировать, заставив пользователя работать в открытую.

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

    Но пути спасения от тотальной слежки есть. Через установленное SSH-соединение можно направлять любой нужный трафик, который с SSH-сервера будет уже в открытом виде идти на конечную точку. Этот способ называется SSH-туннелинг (tunneling). Так можно обезопасить прохождение трафика по незащищенному каналу, но имеет смысл такой подход только при наличии доверенного сервера с поднятым и настроенным на туннелинг SSH-демоном. Причем организовать это достаточно просто. SSH-клиент подключается к серверу, настраивается на прослушку любого данного порта на локальной машине. Этот клиент будет предоставлять услугу SOCKS5-прокси, т.е. его использование можно настроить в любом браузере, почтовых программах, IM-ах и т.д. Через SSH-туннель пакеты попадают на сервер, а с него уходят на целевой сервер. Схема получается следующая:

    [localhost: клиент <=> proxy] <== SSH-соединение ==> сервер <=> целевой сервер

    Другой способ защиты трафика — VPN-канал. В использовании он проще и удобнее SSH-туннелинга, но в первичной установке и настройке сложнее. Основное удобство этого способа в том, что в программах не нужно прописывать прокси. А некоторый софт и вовсе прокси не поддерживает, следовательно только VPN и подойдет.

    На практике есть два варианта работы. Первый — покупка VPN-акканута, который продается специально для этих целей (шифрование трафика по небезопасному каналу). В этом случае продаются обычно аккаунты, соединяться с которыми надо по протоколам PPTP (обычный VPN, который реализован, например, в Windows) или L2TP.

    Второй вариант — покупка VDS-сервера (виртуальный выделенный сервер) с любым дистрибутивом линукса на борту и поднятие на нем VPN-сервера. VDS может быть российским или американским (только не забывайте про заокеанские пинги), дешевым (от $5) и слабым или дорогим и помощнее. На VDS ставят OpenVPN-сервер, а на компьютере поднимается OpenVPN-клиент. Для Windows есть даже гуишная версия клиента.

    Если вы решите использовать вариант с OpenVPN, то есть например эта простая пошаговая инструкция по поднятию сервера (Debian). Установить клиента еще проще, особенно под Windows. Отметить стоит только один нюанс. Если весь трафик требуется пустить по созданному VPN-соединению, то требуется прописать default gateway на шлюз VPN (параметр redirect-gateway в конфиге клиента), а если только часть трафика (на определенные хосты), то можно прописать обычные статические маршруты на данные хосты (по IP; например, route add -p 81.25.32.25 10.7.0.1).

    Для соединения OpenVPN обмен ключами происходит в ручном режиме, т.е. транспортировать их от сервера на клиент можно абсолютно безопасно.

    Таким образом, SSH- и VPN-соединения могут практически полностью гарантировать безопасность вашего трафика при перемещении по незащищенному каналу. Единственная проблема, которая может возникнуть в этом случае, — это запрет на SSL-трафик на корпоративном файрволе. Если SSL-трафик разрешен хотябы на один любой порт (обычно дефолтный 443), то вы уже потенциально можете поднять и SSH-тонель, и VPN-соединение, настроив соответствующего демона на вашем VDS на этот порт.
    Share post

    Comments 83

      +6
      По TLS и SSL.
      описанная атака человек по середине по мне так сомнительна, в случае подмены сертификата PKI X.509 атакующий ничего не добьется. Т.к. сам сертификат уже будет выдан другой организацией. А получить такой же DN-идентификатор он не сможет.
      И вообще в стандарте используется протокол обмена ключами Диффи-Хелмана, который как раз и создан для обмена сессиоными ключами в открытом эфире.
        +3
        > принять сертификат и работать с сайтом, либо отказаться его принимать, но и работать с сайтом тогда уже не получится

        если пользователь, пардон, дурак, то его надо либо уволить, за служебное не соответствие, либо отправить на переобучение.
          +1
          Забываете, что пользователь может хотеть скрыть свой личный траф от начальства. Т.е. третья сторона («человек по средине») в этом случае как раз начальство и их «защитное» ПО.
            0
            сколько по вашему мнению клиентов интернет-банков или любого биллинга читают сертификаты?
            +1
            Вот в том-то и дело, что сертификат будет подложный, это будет видно, НО у вас останется два варианта: либо принять подложный (согласиться, что вас будут прослушивать), либо не работать с этим сайтом вообще. Только одно из двух.

            Если же HTTPS будет идти внутри VPN-тоннеля, то тут уже подложить левый сертификать просто не выйдет. А ключи для VPN можно принести безопасными путями. Главное чтобы бинарный SSL-трафик не был закрыт на файрволе как таковой, хотябы на одном порте (а обычно именно так и происходит — по 443 порту разрешают гонять SSL-трафик всем юзерам корпоративного файрвола).
              +1
              так это проблема не SSL! Сам по себе протокол достаточно продуманный, стандартизованный, в нем уже не определен RSA как основной криптоалгоритм. Такой себе хороший констуркор под свои нужды :)

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

              А в вышем случае я смотрю начальство желает смотреть все SSL-соединения, но VPN открыто для всех и все. Т.е. вопрос стоит сомнительно. И это проблема не _безопасности_, а организационных мер, не связанных с безопасностью.
                0
                Ну во-первых, у меня лично пока вообще таких проблем (с прослушкой) нет :)
                Во-вторых, на множестве корпоративных файрволов открыт не-HTTP-трафик по порту 443 (по вполне понятным причинам), чего вполне достаточно (просто VPN-сервер надо настроить на прослушку именно этого порта).
                В-третьих, речь не идет о «проблемах SSL». Я к этому протоколу тоже претензий не имею :) Речь идет о том, с какими проблемами могут сталкнуться пользователи, даже при использовании HTTPS :)
                  +2
                  Описаные проблемы связаны не с протоколом SSL, а с дисфункцией головного мозга пользователя. Принятие неверного сертификата однозначно перечеркивает всю предоставляемую протоколом защиту.
                0
                В корпоративной среде должен быть только один вариант. Работа через TLS/SSL-соединения, использующие подложные сертификаты, должна быть запрещена политиками безопасности.
                  0
                  >Вот в том-то и дело, что сертификат будет подложный, это будет видно, НО у вас останется два варианта: либо принять подложный (согласиться, что вас будут прослушивать), либо не работать с этим сайтом вообще. Только одно из двух.

                  Не обязательно. Есть, по крайней мере, два варианта оставить корпоративного пользователя в неведении.
                  Первый, наиболее просто реализуемый:
                  Сертификат, который использует «сервер-прослушка» самоподписанный, добавляется к доверенным сертификатам браузера и убирается галочка «Предупреждать о недействительных серфитикатах узлов» в настройках браузера, что бы не ругался на несовпадения имен узлов.

                  Второй, более правильный, реализованный в SSL Mitm proxy:
                  СА сертификат «сервера-прослушки» добавляется к доверенным сертификатам браузера. Когда пользователь подключается куда-либо через SSL, прокси получив сертификат сервера генерирует аналогичный сертификат, подписанный собственным СА. Поскольку данный СА прописан у пользователя никаких предупреждений пользователь не получит.
                    0
                    Часто пользователи все же имеют админские права (в виду специальности у программистов, например) и могут менять настройки браузеров. Впрочем, если админ очень захочет — сделает что угодно. Однако на практике в большенстве случаев так не делают.
                      +2
                      Они могут иметь сколько угодно админских прав. Сколько их них полезет смотреть, какие сертификаты в его браузере установлены как доверенные? А главное сколько из тех кто полезет знает какие сертификаты стояли «с рождения», какие установились при очередном апдейте, а какие злобный админ добавил?
                        0
                        Я думаю, что большество хабраледей сделали бы это, хотя бы потому что в строке адреса есть иконка SSL и она показывает уровень защищенности. Если уровень нулевой, а вопроса о принятии сертефиката нет, то это наводит на странные мысли.
                  0
                  Там не только диффи хелман используется, впрочем это в данном случае неважно.
                    0
                    атакующий ничего не добьется. Т.к. сам сертификат уже будет выдан другой организацией.


                    KIS так HTTPS-тафик проверяет, но он об этом честно предупреждает и оставляет выбор пользователю соглашаться на подмену сертификатов и читать предупреждения или не проверять шифрованный трафик.
                    0
                    Насчёт покупки VPN аккаунта. Есть же бесплатная альтернатива — Hamachi. Или это не то?
                      +1
                      Они используют UDP, а внешний UDP-трафик открыт на корпоративных файрволах редко. И бесплатно оно только для некоммерческого использования.
                      • UFO just landed and posted this here
                        • UFO just landed and posted this here
                          0
                          подозреваю, pptp (GRE и нужный tcp порт) наружу открыто еще реже :)
                            0
                            Так PPTP вообще почти не вариант. Это удобное наверное только для соеденения корпоративных сетей под виндой. А вот для OpenVPS не надо ни GRE, и порт быть любой может (как настроите на сервере).
                      • UFO just landed and posted this here
                          0
                          Да, для нее что-то нужно. Я не стал с этим разбираться за ненадобностью, но мой товарищ это сделал, название проги я у него не спрашивал.
                          • UFO just landed and posted this here
                          +6
                          В статье написано очень много умных слов, но по большому счёту она ниочём :(

                          В начале описана классическая схема man-in-the-middle. Да, криптография с открытым ключём уязвима к этой атаке. Это никто не скрывает — и именно для этого придуманы сеть доверия PGP и X.509, а браузеры кричат если не могут проверить подлинность сертификата сайта.

                          Такое вот имхо.
                          • UFO just landed and posted this here
                              +1
                              Кстати еще неверно:
                              «Приватный ключ служит для зашифрования и находится у отправителя данных, а публичный — для дешифрования, он передается получателю.»
                              На самом деле открытый ключ служит для шифрования информации, а закрытый (приватный) для ее дешифрации.
                                0
                                Назначение ключей я действительно перепутал. Исправил.
                                • UFO just landed and posted this here
                                    0
                                    Подправьте еще то, что отправителю передается открытый ключ (на то он и открытый), а приватный остается у получателя. Иначе никакого бы смысла в таких ключах небыло бы, так как перехватив ключ для дешифрации (приватный), никаких промежуточных серверов уже не надо — бери и дешифровывай. А так как передается только ключ, с помощью которого информация шифруется, но ее невозможно раскрыть, становится необходима атака с подменой источника отправления, которая и описана у вас ниже.
                                      0
                                      Подправьте еще то, что отправителю передается открытый ключ (на то он и открытый), а приватный остается у получателя. Иначе никакого бы смысла в таких ключах небыло бы, так как перехватив ключ для дешифрации (приватный), никаких промежуточных серверов уже не надо — бери и дешифровывай. А так как передается только ключ, с помощью которого информация шифруется, но ее невозможно раскрыть, становится необходима атака с подменой источника отправления, которая и описана у вас ниже.
                                    0
                                    Давайте разберемся. Когда я изучал этот вопрос, пользовался Википедией. В статье про HTTPS написано «Данные, передаваемые по протоколу HTTP, «упаковываются» в криптографический протокол SSL или TLS, тем самым обеспечивается защита этих данных». Ну это конечно и так понятно, приведено для целостности цепочки.

                                    Теперь идем на страничку про SSL. Там сказано: «Использует шифрование с открытым ключом для подтверждения подлинности передатчика и получателя».

                                    Кликаем на шифрование_с_открытым_ключом и там видим:

                                    Криптографическая система с открытым ключом (или Асимметричное шифрование, Асимметричный шифр) — система шифрования и/или электронной цифровой подписи (ЭЦП), при которой открытый ключ передаётся по открытому (то есть незащищённому, доступному для наблюдения) каналу, и используется для проверки ЭЦП и для шифрования сообщения. Для генерации ЭЦП и для расшифрования сообщения используется секретный ключ.

                                    Где ошибка, что я пропустил?
                                    • UFO just landed and posted this here
                                      • UFO just landed and posted this here
                                          0
                                          Нашел информацию, подтверждающую вашу правоту. Вношу изменения в статью. Спасибо.
                                        0
                                        Кстати еще неверно:
                                        «Приватный ключ служит для зашифрования и находится у отправителя данных, а публичный — для дешифрования, он передается получателю.»
                                        На самом деле открытый ключ служит для шифрования информации, а закрытый (приватный) для ее дешифрации.
                                        0
                                        В большинстве случаев хостинг компании запрещают поднимать любые vpn и прокси.
                                        Правда я на своем выделеном сервере поднял OpenVPN, сижу через него пока не заметили :)

                                        В моем случаи очень классная схема получилась.
                                        Живу я в общаге, там где злые админы-студенты частенько смотрят трафик. Интернет у меня UA-IX 10 мбит/сек а на МИР 128 кбит/сек.
                                        При помощи OpenVPN я убиваю 2 зайца:
                                        1. Мой трафик шифруется при помощи OpenVPN
                                        2. У меня мировой канал поднимается до скорости равной скорости UA-IX (мой сервер входит в эту зону + подключен к мировым точкам обмена траффика)
                                          0
                                          Будьте добры, ссылочку на типовой договор с хостинговой компанией, в котором будет прописан пункт запрещающий поднимать что либо. Арендуем vds,vps, ставим свои дедики в Росиии и штатах, соединяем их различными видами шифрованых каналов (mysql+ssl, postgres+ssl, openvpn туннели, ldaps, ssh) и единственное ограничение — запрет на спам и действия противоречащие законодательству страны.
                                          Ограничивающий фактор — платный входящий трафик при превышении соотношения входящий/исходящей > X
                                        0
                                        Интересно для общего кругозора, спасибо :)
                                          0
                                          Ерунда все это. Человеку даны глаза чтобы смотреть на сертификат сайта (в чем помогает браузер) и мозг, чтобы оценивать эту информацию. Тоже самое с SSH — идентификатор ключа, при первом подключении, весьма разумно проверить другим путем. Оба протокола весьма разумно защищены от атаки man-in-the-middle, вопрос только в исползовании их.
                                          И никакой прокси не расшифрует трафик.
                                          • UFO just landed and posted this here
                                              0
                                              Такое сплошь и рядом. Есть примеры покруче: https://ibank.bpsb.by
                                                0
                                                  0
                                                  Даа, это действительно позорище…
                                                  За 200 долларов в год можно приобрести нормальную лицензию от верисигна или тавте.
                                                  Экономят, либо не умеют…
                                                    0
                                                    200$ — это за сертификат со звездой (CN аля *.example.com).
                                                    На один домен он 30 стоит, да еще и спец предложения бывают типа 5 доменов за 80. Короче, позорище полное
                                                  0
                                                  Зачем ходить далеко. Webmoney. Да, это весьма порочная практика, но при доступе на серьезные ресурсы стоит хорошенько подумать прежде чем проверять сертификат.
                                                  • UFO just landed and posted this here
                                                      0
                                                      https://light.webmoney.ru/
                                                0
                                                Объясните, пожалуйста, как действовать в следующей ситуации: вы работаете из офиса, при любом https-соединении вам суют фальшивый сертификат. Вы хотите периодически проводить операции, которые требует строгой приватности, даже от начальства и IT-отдела. На корпоративном файрволе открыт исходящий SSL-трафик на порт 443. Уволится? Или поднять SSH, VPN?
                                                • UFO just landed and posted this here
                                                    0
                                                    Уволится, или как минимум серьезно поговорит с начальством.
                                                    Ну или всячески изголяться, игнорируя то, что по сути на предприятии установлен режим тотальной слежки.
                                                      0
                                                      Зачастую, тотальная слежка имеет лишь функцию психологического давления.
                                                      Скажите юзерам, что вы можете следить за их мониторами в рабочее время и увидите, как поднимется производительность труда.
                                                        0
                                                        Кроме производительности труда есть еще личная жизнь.
                                                        Да, кто-то испугается и начнет меньше торчать на фишках и удавах всякообразных.
                                                        А кто-то пошлет куда подальше и найдет другую работу.
                                                      0
                                                      Объясните, пожалуйста, зачем вы пользуетесь в рабочее время вычислительной техникой в личных целях?
                                                        0
                                                        Потому что не жизнь ради работы, а работа ради жизни… Наверное я еще не стал совсем роботом и позволяю себе жить как человек даже в рабочее время. Ну а, когда надо, позволяю себе работать в нерабочее. Короче, мы с работой в дружеских отношениях и бюрократией не страдаем.

                                                        Я считаю, что так должно быть у всех.
                                                    0
                                                    OpenVPN классная штука. Пользовался несколько раз.

                                                    А вообще конечно удобно, если сервак есть, если висишь где-то в незащищенной сети или потенциально прослушиваемой сети, то можно через свой впн шифровать трафик. :)
                                                      +1
                                                      Проблема в том, что многие (криворукие) https:// сайты и спользуют неподписанный сертификат, просто привыкаешь к этому, хотя как я понял, в этом случае https эквивалентен http((
                                                      • UFO just landed and posted this here
                                                          0
                                                          Нет, это скорее делается для того, чтобы передавать пароль в зашифрованном виде.
                                                          +1
                                                          Гмм… Хронической дисфункцией головного мозга должны обладать IT-шники той конторы, которая снифает на проксе проходящий трафик путем дешифрования SSL-сессий. Надо же, как они повышают безопасность, расшифровывая секьюрные соединения банк-клиентских приложений. Любой тривиальный руткит, будучи без проблем установленным на проксе (которая, как правило является машиной с торчащей в Интернет жопой), будет собирать массу полезной для третих лиц информации и банковских проводках, не говоря о формировании фальсифицированных платежей.
                                                          И любая служба безопасности банка пошлет лесом ту контору, которая заявит о пропаже средств с банковского счета, если узнает, что у них такая схема SSL-снифинга.
                                                            0
                                                            Такие системы стоят навернео во всех банках и компаниях, чья деятельность связана с финансами и банковским ПО. Как написано в статье, я сталкивался с этим не по наслышке.

                                                            Так что все успешно работает и никто никого не посылает.
                                                              0
                                                              Я говорю про систему, которая установлена в офисе у клиента банка.
                                                            0
                                                            «У пользователя остается выбор: принять сертификат и работать с сайтом, либо отказаться его принимать, но и работать с сайтом тогда уже не получится. Иногда пользователи вообще игнорируют содержимое сертификатов и машинально принимают любые переданные им.» Не принимать сертификат, если не уверен. На этом можно было бы закончить статью.
                                                              0
                                                              почему на тот же banking.webmoney.ru FF 3.04 ругается на непописанный сертификат?
                                                                0
                                                                *неподписанный
                                                                  0
                                                                  У меня — не ругается, говорит — все ОК. FF 3.04.
                                                                    0
                                                                    У вас noscript наверное стоит — там тягается скрипт с https://dynamic.exaccess.ru/, а их сертификат подписан самими вебманями.
                                                                      0
                                                                      Нет у меня NoScript-a. Да и зачем, по-вашему, носкрипту пользоваться сертификатами, которые подписаны недоверенным ЦС?
                                                                        0
                                                                        Вы не поняли. У них в самом низу страницы вот такой код:
                                                                        <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, то, конечно, Вы предупреждений не увидите.
                                                                          0
                                                                          На banking.webmoney.ru у меня вход без предупреждений, на dynamic.exaccess.ru — действительно недоверенный ЦС. Только, опять-таки, на работе banking это никак не сказывается. в моей конфигурации чистого ФФ. прочих телодвижений тоже не делал…
                                                                  • UFO just landed and posted this here
                                                                    0
                                                                    Вы не поверите, но в общем случае (и конкретно в вашем описании) SSH соединение менее безопасно, чем HTTPS(SSL) :]

                                                                    > Чтобы далее «читать» весь трафик пользователя, промежуточный сервер подменяет сертификат на свой. Т.е. он просто сам подключается к клиенту со своим сертификатом, и в то же время подключается к удаленному серверу. Клиенту приходит «левый» сертификат от сервера-злоумышленника, а браузер сообщает пользователю об опасности (такие сертификаты всегда не подписаны). У пользователя остается выбор: принять сертификат и работать с сайтом, либо отказаться его принимать, но и работать с сайтом тогда уже не получится. Иногда пользователи вообще игнорируют содержимое сертификатов и машинально принимают любые переданные им.

                                                                    Собственно говоря вся эта инфраструктура PKI назначена как раз для защиты именно от такой атаки. )
                                                                    А если надо работать «без вариантов» — то простите, о какой безопасности может идти речь?
                                                                      0
                                                                      Конечно не поверю. Потому что вы ничего не аргументировали.

                                                                      А еще замечу, что здесь не сравнивается безопасность HTTPS и SSH. Они предназначены для разных задач и работают по-разному.
                                                                        0
                                                                        Да, действительно не сравниваются ^_^
                                                                        В этом сучае весь мой пост можно не учитывать
                                                                      0
                                                                      Поясните такой момент. При https соединении сервер присылает браузеру свой сертификат, так? После чего браузер должен проверить его подпись, так? Как он это делает — посылает запрос в центр сертификации (не знаю как правильно — ну то есть VeriSign)? Тогда что мешает также вклинится между браузером и верисигном и прислать ответ — все окей, сервак правильный?
                                                                        0
                                                                        Нет, запросов в центр сертификации нет. Подлинность сертификата подтверждает цифровая подпись, которая идет вместе с сертификатом.
                                                                          0
                                                                          Угу. А список центров сертификации жестко где-то прописан? Просто что мешает полностью эмулировать центр сертификации — сгенерить пару ключей, подписать приватным сертификат псевдосерверу, отдать пользователю, когда тот запросит публичный для проверки подписи — выдать?
                                                                            0
                                                                            Тут я уже точно не знаю, но могу сказать вот что. Для проверки подписи нужен ключ (подпись — это ассиметричный шифр, один ключ шифрует — он остается у того, кто выдал сертификат, второй видимо отдается всем, кто хочет сертификат проверить). Так как количество авторизированных раздатчиков сертификатов ограничено, предполагаю, что их ключи проверки встроены в браузеры. Подделать в этом случае ничего не удастся.

                                                                            Повторю — информация основана на догадках и не точна, если кто-то может ее подтвердить или апровергнуть — милости прошу. А саму уточнять все это сейчас нет времени.
                                                                            • UFO just landed and posted this here
                                                                            0
                                                                            Операционная система (и сами браузеры, кстати, тоже) содержит корневые сертификаты многих центров сертификации. В Windows их можно посмотреть выполнив certmgr.msc
                                                                            С помощью корневых сертификатов в системе, собственно, и проверяется, был ли сертификат сервера подписан у доверенного центра или нет. Это еще одна дырка — имея доступ к компьютеру, можно подменить корневой сертификат или добавить свой корневой сертификат в список доверенных, тогда браузер уже не будет ругаться при атаке Man-in-the-Middle.

                                                                          Only users with full accounts can post comments. Log in, please.