29 июля 2013 в 11:51

Как HTTPS обеспечивает безопасность соединения: что должен знать каждый Web-разработчик перевод



Как же все-таки работает HTTPS? Это вопрос, над которым я бился несколько дней в своем рабочем проекте.

Будучи Web-разработчиком, я понимал, что использование HTTPS для защиты пользовательских данных – это очень и очень хорошая идея, но у меня никогда не было кристального понимания, как HTTPS на самом деле устроен.

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

Трубопровод


Перед тем как мы погрузимся в то, как это работает, давайте коротко поговорим о том, почему так важно защищать Интернет-соединения и от чего защищает HTTPS.

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



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

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

• Для этого требуется больше вычислительных мощностей
• Передается больше данных
• Нельзя использовать кеширование

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

Transport Layer Security (TLS)


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

TLS — наследник SSL — это такой протокол, наиболее часто применяемый для обеспечения безопасного HTTP соединения (так называемого HTTPS). TLS расположен на уровень ниже протокола HTTP в модели OSI. Объясняя на пальцах, это означает, что в процессе выполнения запроса сперва происходят все “вещи”, связанные с TLS-соединением и уже потом, все что связано с HTTP-соединением.

TLS – гибридная криптографическая система. Это означает, что она использует несколько криптографических подходов, которые мы и рассмотрим далее:

1) Асиметричное шифрование (криптосистема с открытым ключом) для генерации общего секретного ключа и аутентификации (то есть удостоверения в том, что вы – тот за кого себя выдаете).
2) Симметричное шифрование, использующее секретный ключ для дальнейшего шифрования запросов и ответов.

Криптосистема с открытым ключом


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

С тех пор как сообщение было зашифровано с помощью открытого ключа, оно может быть расшифровано только соответствующим ему закрытым ключом. Ни один из ключей не может выполнять обе функции. Открытый ключ публикуется в открытом доступе без риска подвергнуть систему угрозам, но закрытый ключ не должен попасть к кому-либо, не имеющему прав на дешифровку данных. Итак, мы имеем ключи – открытый и закрытый. Одним из наиболее впечатляющих достоинств ассиметричного шифрования является то, что две стороны, ранее совершенно не знающие друг друга, могут установить защищенное соединение, изначально обмениваясь данными по открытому, незащищенному соединению.
Клиент и сервер используют свои собственные закрытые ключи (каждый – свой) и опубликованный открытый ключ для создания общего секретного ключа на сессию.

Это означает, что если кто-нибудь находится между клиентом и сервером и наблюдает за соединением – он все равно не сможет узнать ни закрытый ключ клиента, ни закрытый ключ сервера, ни секретный ключ сессии.

Как это возможно? Математика!

Алгоритм Ди́ффи — Хе́ллмана


Одним из наиболее распространенных подходов является алгоритм обмена ключами Ди́ффи — Хе́ллмана (DH). Этот алгоритм позволяет клиенту и серверу договориться по поводу общего секретного ключа, без необходимости передачи секретного ключа по соединению. Таким образом, злоумышленники, прослушивающие канал, не смогу определить секретный ключ, даже если они будут перехватывать все пакеты данных без исключения.

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

Немного математики…


Математические функции, лежащие в основе этого алгоритма, имею важную отличительную особенность — они относительно просто вычисляются в прямом направлении, но практически не вычисляются в обратном. Это именно та область, где в игру вступают очень большие простые числа.

Пусть Алиса и Боб – две стороны, осуществляющие обмен ключами по DH-алгоритму. Сперва они договариваются о некотором основании root (обычно маленьком числе, таком как 2,3 или 5 ) и об очень большом простом числе prime (больше чем 300 цифр). Оба значения пересылаются в открытом виде по каналу связи, без угрозы компрометировать соединение.

Напомним, что и у Алисы, и у Боба есть собственные закрытые ключи (из более чем 100 цифр), которые никогда не передаются по каналам связи.

По каналу связи же передается смесь mixture, полученная из закрытых ключей, а также значений prime и root.

Таким образом:
Alice’s mixture = (root ^ Alice’s Secret) % prime
Bob’s mixture = (root ^ Bob’s Secret) % prime
где % — остаток от деления

Таким образом, Алиса создает свою смесь mixture на основе утвержденных значений констант (root и prime), Боб делает то же самое. Как только они получили значения mixture друг друга, они производят дополнительные математические операции для получения закрытого ключа сессии. А именно:

Вычисления Алисы
(Bob’s mixture ^ Alice’s Secret) % prime

Вычисления Боба
(Alice’s mixture ^ Bob’s Secret) % prime

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

Для тех, кто меньше подкован в математическом плане, Wikipedia дает прекрасную картинку, объясняющую данный процесс на примере смешивания цветов:

image

Обратите внимание как начальный цвет (желтый) в итоге превращается в один и тот же “смешанный” цвет и у Боба, и у Алисы. Единственное, что передается по открытому каналу связи так это наполовину смешанные цвета, на самом деле бессмысленные для любого прослушивающего канал связи.

Симметричное шифрование


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

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

Аутентификация


Алгоритм Диффи-Хеллмана позволяет двум сторонам получить закрытый секретный ключ. Но откуда обе стороны могут уверены, что разговаривают действительно друг с другом? Мы еще не говорили об аутентификации.

Что если я позвоню своему приятелю, мы осуществим DH-обмен ключами, но вдруг окажется, что мой звонок был перехвачен и на самом деле я общался с кем-то другим?! Я по прежнему смогу безопасно общаться с этим человеком – никто больше не сможет нас прослушать – но это будет совсем не тот, с кем я думаю, что общаюсь. Это не слишком безопасно!

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

Но, на самом деле, что это за сертификат, и как он предоставляет нам безопасность?

Сертификаты


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

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

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

Чтобы сертификату доверял любой веб-браузер, он должен быть подписан аккредитованным удостоверяющим центром (центром сертификации, Certificate Authority, CA). CA – это компании, выполняющие ручную проверку, того что лицо, пытающееся получить сертификат, удовлетворяет следующим двум условиям:

1. является реально существующим;
2. имеет доступ к домену, сертификат для которого оно пытается получить.

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

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

image

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

Прочие вещи которые нужно знать о сертификатах


Расширенная валидация

В дополнение к обычным X.509 сертификатам, существуют Extended validation сертификаты, обеспечивающие более высокий уровень доверия. Выдавая такой сертификат, CA совершает еще больше проверок в отношении лица, получающего сертификат (обычно используя паспортные данные или счета).

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

Обслуживание множества веб-сайтов на одном сервере

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

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

По этой теме много данных есть в википедии, есть курс на Coursera. Отдельное спасибо ребятам из чата на security.stackexchange.com, которые отвечали на мои вопросы сегодня утром.

Примечания переводчика:

1)Спасибо хабраюзеру wowkin за отличную ссылку по теме (видео переведено и озвученно хабраюзером freetonik):



2) По результатам развернувшейся в коменатариях дискуссии (спасибо за участие хабраюзерам a5b, Foggy4 и Allen) дополняю основную статью следующей информацией:

По данным netcraft на базе свежего SSL survey (2.4 млн SSL сайтов, июнь 2013), большинство SSL соединений не используют Perfect forward secrecy алгоритмы: news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html

Особенно ситуация плоха в случае с IE (даже 10 версии), который поддерживает Диффи-Хеллмана только на эллиптических кривых (RSA и ECDSA сертификаты), либо классический Диффи-Хеллман с более редкими сертификатами DSS (DSA).
По подсчетам netcraft 99,7 % соединений с IE и по 66% — с Chrome, Opera и Firefox не будут использовать Диффи-Хеллмана.

На Hacker News в обсуждении это тоже заметили.

Also (and I made the same mistake in my talk...), yes, explaining DH is important, but now it kind of sounds like in TLS both sides figure out the master secret using DH (and, in your talk, specifically, regular DH, not EC-based DH), when in reality that depends on the ciphersuite, and the vast majority of TLS connections don't work that way. From what I understand to be most TLS configurations in the wild, the pre-master secret is encrypted using the server's public key. (RFC 5246: 7.4.7.1, 8.1.1)
это важно и интересно, но не все понимают что он в реальности применяется не так часто. В большинстве сеансов SSL и TLS действительно обмен ключей происходит путем их шифрования с помощью RSA.
Перевод: Hartley Brody
Сергей @zavg
карма
42,0
рейтинг 0,0
Похожие публикации
Самое читаемое Разработка

Комментарии (56)

  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      С этим согласен, поэтому сперва даже хотел выкинуть этот кусок из перевода :)
    • +4
      Там же не раскрыта тема Wildcard/SAN. А ещё мало раскрыта тема EV и не раскрыта SGC :)
  • +18
    «Алгоритм Ди́ффи — Хе́ллмана» на пальцах
    www.youtube.com/watch?feature=player_detailpage&v=VBDJ0ERjnD4
    • 0
      Супер! Добавлю это с вашего позволения! :)
      • +1
        Это видео переведено и озвученно Хабра-пользователем freetonik habrahabr.ru/users/freetonik/
        • 0
          zavg, спасибо за статью.
          freetonik, спасибо за перевод очень полезного ролика.
  • +3
    Отличная статья, отличный перевод. Огромное человеческое спасибо Вам!
    Всегда было интересно как могут клиент и сервер договориться о шифровании так, чтобы это не перехватили извне. Вполне доступно всё объяснили, хоть я и не связан с этой областью знаний вообще никак.
    • 0
      Спасибо!)) Да, статья классная и именно потому, что небольшая и очень популярно излагающая суть вопроса. Возглавляла топ реддита пару дней назад.
  • +2
    Это всё конечно прекрасно, но в статье не написано что обмен ключами по Диффи-Хэллману почти никогда не используется. В 99% случаев это обычный RSA, который можно расшифровать опосля имея приватный ключ сервера, хотябы уже невалидный. Старые ключи же гугл не выбрасывает?

    security.stackexchange.com/questions/8343/what-key-exchange-mechanism-should-be-used-in-tls
    • +3
      Мне кажется, Вы не совсем внимательно прочитали ответ Томаса.

      Там написано что в 99.9% случаях серверный открытый ключ — это RSA-ключ и никто не использует DH-ключи в сертификатах. То есть не используется статический обмен ключами по Диффи-Хеллману (static Diffie-Hellman, DH_RSA), когда DH-ключ хранится в сертификате.

      Вместо этого применяется динамический обмен ключами по Диффи-Хеллману (ephemeral Diffie-Hellman, DHE_RSA), как раз и описанный в статье.
      • –1
        Я всё внимательно прочитал

        You want a cipher suite which is compatible with your server key type and certificate. This, in turn, depends on what the CA accepts (the CA which sold you the certificate). 99.9% of the time, this means RSA. Everybody does RSA. Diffie-Hellman keys in certificates, and DSA signatures, used to be promoted by NIST (the US federal agency which deals with such matters) because there was a patent on RSA; but that patent expired in 2000. Diffie-Hellman (as part of certificates) is specified by ANSI X9.42, a standard which is not free (so opensource free-time developers are reluctant to implement it) and not all that clear either. So nobody really uses Diffie-Hellman in certificates. DSA is more widely supported (its defining standard is free and quite readable) but not to the point of being non-anecdotic when compared to RSA.
        • +1
          В фразе
          So nobody really uses Diffie-Hellman in certificates.
          имеется в виду:
          DH_RSA: the key exchange is a static Diffie-Hellman: the server public key must be a Diffie-Hellman key; moreover, that certificate must have been issued by a Certification Authority which itself was using a RSA key (the CA key is the key which was used to sign the server certificate).

          А на практике применяется:
          DHE_RSA: the key exchange is an ephemeral Diffie-Hellman: the server dynamically generates a DH public key and sends it to the client; the server also signs what it sends. For DHE_RSA, the server public key must be of type RSA, and its certificate must be appropriate for signatures (the Key Usage extension, if present, must include the digitalSignature flag).
          Обратите внимание на последнюю строчку в посте:
          Summary: use DHE_RSA.
          • 0
            «use DHE_RSA» это лозунг, призыв использовать DHE_RSA.
            В то время как в списке опций ещё стоит простой RSA. Речь о том что используется именно он.

            99.9% of the time, this means RSA. Everybody does RSA
            … So nobody really uses Diffie-Hellman in certificates.
            • +1
              Да он имеет в виду, что никто не использует сертификаты с фиксированными DH-ключами.
              В сертификат можно зашить не RSA-ключ, а DH-ключ и использовать его вместо генерации каждый раз на сессию.

              Вот другой пост об этом:
              security.stackexchange.com/questions/12052/confusing-about-ephemeral-diffie-hellman
              • +1
                Не уводите в сторону. Речь не о том кто там что пишет, а о том как это всё работает. Есть несколько алгоритмов обмена ключами: RSA, Diffie-Hellman, Elliptic Curve Diffie-Hellman и так далее. Клиент и сервер договариваются о том алгоритме который они оба понимают и предпочитают. Так вот, я говорю о том, что в большинстве случаев это не Diffie-Hellman (ни статический ни динамический). И не цепляйтесь за один текст по ссылке, погуглите ещё.
                • +1
                  Так же всю жизнь считал, что обмен ключами происходит по алгоритму RSA в SSL, в статье же говорится почему то только о DH. Может быть найдется эксперт могущий внести ясность в этот вопрос?
                  • +1
                    На Hacker News в обсуждении это тоже заметили: news.ycombinator.com/item?id=6101646

                    Also (and I made the same mistake in my talk...), yes, explaining DH is important, but now it kind of sounds like in TLS both sides figure out the master secret using DH (and, in your talk, specifically, regular DH, not EC-based DH), when in reality that depends on the ciphersuite, and the vast majority of TLS connections don't work that way. From what I understand to be most TLS configurations in the wild, the pre-master secret is encrypted using the server's public key. (RFC 5246: 7.4.7.1, 8.1.1)

                    Finally, a bit of a plug, but… If you're interested in the build up, my PyCon 2013 talk «Crypto 101» ( www.youtube.com/watch?v=3rmCGsCYJF8 ) starts from XOR and ends with TLS in 45 minutes. It mostly goes into a bit more detail about thinks like block and stream ciphers. I'm hoping to eventually turn this into a book. (If you're interested, my e-mail's in my profile.)


                    DH это важно и интересно, но не все понимают что он в реальности применяется не так часто. В большинстве сеансов SSL и TLS действительно обмен ключей происходит путем их шифрования с помощью RSA. Подробнее про оба варианта — в wiki или упомянутом RFC 5246:
                    * 7.4.7.1. RSA-Encrypted Premaster Secret Message
                    * 8.1.1. Computing the Master Secret -> RSA
    • +2
      По данным netcraft на базе свежего SSL survey (2.4 млн SSL сайтов, июнь 2013), большинство SSL соединений не используют perfect forward secrecy алгоритмы: news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html

      Особенно ситуация плоха в случае с IE (даже 10 версии), который поддерживает Диффи-Хеллмана только на эллиптических кривых (RSA и ECDSA сертификаты), либо классический Диффи-Хеллман с более редкими сертификатами DSS (DSA).
      По подсчетам netcraft 99,7 % соединений с IE и по 66% — с Chrome, Opera и Firefox не будут использовать Диффи-Хеллмана.

      Еще они вспомнили PRISM, и пояснили, что если операторы PRISM записывали шифрованный SSL/TLS трафик, который не использовал perfect forward secrecy алгоритмы, то впоследствии они смогут расшифровать поток, получив приватные ключи.
  • +1
    Зачем нужен root, если две стороны могут просто открыто обменяться открытыми ключами, которыми будут шифроваться входящие сообщения, а декриптоваться не переданными закрытыми?
    • –1
      Как они узнают закрытые ключи друг друга, если видят друг друга первый раз?
      • 0
        А зачем им закрытый ключ другого собеседника? Это же просто: участник А шифрует свое послание открытым ключом Б, и только Б может его расшифровать, поскольку знает свой закрытый ключ (ну и наоборот).
        Как я понял, в данном случае утверждается только то, что данный алгоритм установления соединения используют для того, чтобы использовать симметричное шифрование (для шифровки и декодирования — один и тот же ключ), мотивируя это тем, что в этом случае кодировка/декодировка занимают меньше ресурсов.
        • 0
          Все дело в том, что для шифрования данных используется открытый ключ сервера, защищенный сертификатом безопасности.
        • +2
          Прошу не пинать, говорю как я это себе понял, когда разбирался в этом вопросе.
          Итак, ассимитричные алгоритмы — весьма ресурсоёмкие алгоритмы, и они не используются для обработки больших объёмов данных. Взять ту же ЭЦП (пардон, теперь это ЭП зовётся). Там ведь не шифруется весь документ открытым ключём и не расшифровывается закрытым, там по документу вычисляется hash и вот уже hash сторона А шифрует открытым ключом стороны Б. А сторона Б, получив документ, сама вычисляется hash, потом расшифровывает ЭП своим закрытым ключом и сравнивает полученные hash.
          Так и при шифровании, шифрование не производится на ассиметричных ключах (зачастую), а с помощью ассимитричных ключей передаётся общий закрытый ключ, который генерится, и который используется уже в симметричном алгоритме шифрования. Симметричные алгоритмы, соответственно, на порядок менее ресурсоёмки. Как то так!
          • +1
            сторона А шифрует открытым ключом стороны Б. Затем сторона Б, получив документ, сама вычисляется hash, потом расшифровывает ЭП своим закрытым ключом и сравнивает полученные hash.

            Может быть все таки сторона А подписывает hash своего документа своим закрытым ключем, а затем сторона Б вычисляет hash и проверяет его открытым ключем стороны А? По тому как написано у вас, получается, что сторона А подписывает документ специально для стороны Б, а не для всех желающих удостовериться в подлинности.
            Подскажите, если я ошибаюсь.
            • 0
              Ой да, Вы правы, в отношении ЭП шифрование hash осуществляется на закрытом ключе стороны А, и тогда любая стороная получив документ, может вычислить hash и расшифровать hash из ЭП на открытом ключе стороны А.

              Та схему которую я ранее описал, похоже актуальна для шифрования.

              Спасибо что поправили, а то так бы и зафиксировалось у меня ошибочное понимаени! :)

              Кстати, вот тут очень неплохо описана схема ЭП при использовании асимметричной схемы.
        • 0
          del
    • +3
      Нотариально заверенный открытый ключ. :) Иначе Ева может передать Бобу и Алисе свои открытые ключи (MITM attack), а они ничего не заметят.
      • +3
        Собственно говоря, нотариальным заверением открытых ключей и занимаются центры сертификации :)
        • 0
          Так а я о чем.
      • 0
        ОК, то есть Ева берёт контроль над соединением, «отцепляет» Алису от Боба (так что они не могут поднять шухер, не сумев расшифровать сообщения друг друга) и начинает общаться с каждым по отдельности? Расшифровывая сообщения своим закрытым ключом, и шифруя снова оригинальным открытым ключом Алисы и Боба для последующей передачи?

        Я правильно понимаю суть атаки?
        • +1
          Да, абсолютно верно.
        • 0
          Да. Сие зовётся «Man in the middle». Вы описали его во всей красе.
        • 0
          Объясните, пожалуйста, если Ева взяла полный контроль над соединением, то что ей мешает по описанной вами схеме создать два шифрованных соединения по DH-алгоритму. Т.е. какое преимущество дает DH-алгоритм перед простым шифрованием открытым ключем/дешифровкой закрытым ключем в плане атаки MITM
          • +2
            В плане MITM они идентичны. Точнее, они идентично уязвимы. Для того, чтобы закрыть эту уязвимость и придумали сертификаты и центры сертификации.

            Если соединение не «прослушивается», то мы создаём пару ключей DH, отправляем открытый, в ответ получаем ключ сервера, подписанный центром сертификации, который заверяет, что этот ключ принадлежит именно тому серверу, к которому мы соединяемся. После проверки подписи центра мы получаем зелёную плашечку в браузере.

            А если Ева перехватила соединение, то ей придётся создать две пары DH-ключей: который используется для соединения с нами, и который используется для соединения с удалённым сервером. Но ключ Евы не будет подписан авторизованным центром сертификации, поэтому браузер сообщит нам о том, что что-то не так.

            Но даже с HTTPS (SSL) есть целый ряд проблем. На этот счёт есть замечательная статья. Возможно, zavg стоит добавить эту ссылку в статью.
            • +2
              На каждую хитрую гайку найдется свой болт с резьбой. В указанной вами статье описывается «принуждение» клиента к соединению по HTTP, на что уже есть ответная мера — HTTP Strict Transport Security (HSTS):
              en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
    • +2
      Потому что между двумя сторонами может находиться третья. Атака «Человек посередине» называется.
    • 0
      Асимметричная крипта медленная
      • 0
        Что б не влиять на нагрузку основных процессовров серверов, для этого ставять отдельные ssl ofload карты, которые занимаются только криптованием.
        • –3
          В новые процессоры встроена аксельрация.
  • НЛО прилетело и опубликовало эту надпись здесь
  • +7
    Отличная статья, для меня HTTPS всегда был в виде «weird black box», а алгоритм передачи ключей вызывал сомнения и непонимание, а теперь я все понял и смогу начать жить полной жизнью!
  • 0
    Извините, я тоже в этой теме профан.
    Как верифицируются ключи CA, вернее как убедиться, что сертификат — настоящий, и CA именно тот, за кого себя выдаёт?
    • +1
      В каждой ОС или браузере хранятся открытые ключи доверенных центров сертификации. Сверяются по списку.
      • 0
        То есть, теоретически это можно обойти, если «хакнуть» или подсунуть мне левое обновление ОС или браузера? Так бывает вообще?
        • +3
          Да, можно.
          Подсовывать обновление не обязательно. В случае Windows можно сделать свой CA-сертификат и установить его в хранилище доверенных сертификатов (certmgr.exe/certmgr.msc).
          Но зелёные полоски так делать не получится — нужно уже делать левое обновление для браузера.
          • 0
            А в случае с PRISM, как я понимаю, спецслужбам ничто не мешает договориться с одним из доверенных CA, находящимися в Америке, чтобы сделать валидные сертификаты для интересующих сервисов и использовать их в атаках типа man-in-middle? Ну кроме авторитета СА, которым он дорожит, конечно.
            • +1
              В целом, да.
              Но если такой CA подпишет запрос на сертификат от недостаточно проверенной стороны, то откреститься от него не получится, так как получившийся сертификат можно будет скачать и предъявить общественности. Это будет равносильно концу бизнеса для CA, поэтому никто так не делает :)
              Хотя по интернету ходят слухи, что CA подписывает направо и налево промежуточные сертификаты для того, чтобы американские компании могли проксировать https-трафик своих сотрудников, я в это не верю и ни разу доказательств не видел.
              • 0
                NSA имело прямой доступ к данным Google, Facebook, Apple. Несмотря на это, почти никто не отказался от их услуг после скандала. Так что повозмущаются люди в Интернетиках, петиции соберут и стерпят. А тем временем законы примут нужные.
                • +1
                  Фраза «NSA имело прямой доступ» должна быть заменена на «где-то утекли картинки и графики схемы, по которой NSA могло иметь доступ». С сертификатом всё намного проще — либо есть подписанный промежуточный CA у шпиёнов, либо его нет.

                  Да у не нужен он им — например, у FBCA, ECA, полиции и DoD есть свои CA [хомячки срочно побежали удалять их из списка доверенных].
                  • 0
                    Заявляется, что «The Guardian has verified the authenticity of the document».

                    Все же, Guardian это не желтушное издание типа «Комсомолки».

            • 0
              Службам проще ковыряться в «data at rest» нежели в «data in transit».
  • 0
    Злоумышленник, подключившийся каналу, будет видеть лишь “мусор”, гуляющий по сети взад-вперед.

    Мало того что он будет видеть лишь «мусор» (в криптографии это называется semantic security), он также никоим образом не сможет изменить данные незаметно для другой стороны (data integrity). При чем, очевидно, что первое условие само по себе никакой безопасности не гарантирует.
  • +1
    Тема
    Как HTTPS обеспечивает безопасность соединения: что должен знать каждый Web-разработчик

    До двоеточия хорошо и качественно раскрыто.

    Но «что должен знать каждый Web-разработчик» слабо. Много раз сталкивался с тем, что люди не понимают от чего именно засчищает https.
    https позволяет защитится от man-in middle класса атак. (чтения трафика, подмена трафика, представление себя за другого).
    Однако https не защищает от любых других атак. То есть различные cross-scripting и еще множество типов атак как работали так и будут работать.
    • 0
      s/что/это/?
  • 0
    zavg Статья отличная спасибо.
    А я оставлю для интересующихся вот эту ссылку: en.wikipedia.org/wiki/Server_Name_Indication
    Здесь описано, что было добавлено в TSL, чтобы стала возможной ситуация «каждый домен на одном и том же IP-адресе использует свой собственный сертификат».
    Узнал про эту технологию, когда бодался, почему у меня подхватывается не так строится цепочка сертификатов в Java 1.6 при обращении к подобному мультихост-домену. Выяснилось, что поддержка SNI была добавлена лишь начиная с версии Java 1.7.

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