Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 57
Тема SNI не раскрыта
«Алгоритм Ди́ффи — Хе́ллмана» на пальцах
www.youtube.com/watch?feature=player_detailpage&v=VBDJ0ERjnD4
www.youtube.com/watch?feature=player_detailpage&v=VBDJ0ERjnD4
Супер! Добавлю это с вашего позволения! :)
Это видео переведено и озвученно Хабра-пользователем freetonik habrahabr.ru/users/freetonik/
Отличная статья, отличный перевод. Огромное человеческое спасибо Вам!
Всегда было интересно как могут клиент и сервер договориться о шифровании так, чтобы это не перехватили извне. Вполне доступно всё объяснили, хоть я и не связан с этой областью знаний вообще никак.
Всегда было интересно как могут клиент и сервер договориться о шифровании так, чтобы это не перехватили извне. Вполне доступно всё объяснили, хоть я и не связан с этой областью знаний вообще никак.
Это всё конечно прекрасно, но в статье не написано что обмен ключами по Диффи-Хэллману почти никогда не используется. В 99% случаев это обычный RSA, который можно расшифровать опосля имея приватный ключ сервера, хотябы уже невалидный. Старые ключи же гугл не выбрасывает?
security.stackexchange.com/questions/8343/what-key-exchange-mechanism-should-be-used-in-tls
security.stackexchange.com/questions/8343/what-key-exchange-mechanism-should-be-used-in-tls
Мне кажется, Вы не совсем внимательно прочитали ответ Томаса.
Там написано что в 99.9% случаях серверный открытый ключ — это RSA-ключ и никто не использует DH-ключи в сертификатах. То есть не используется статический обмен ключами по Диффи-Хеллману (static Diffie-Hellman, DH_RSA), когда DH-ключ хранится в сертификате.
Вместо этого применяется динамический обмен ключами по Диффи-Хеллману (ephemeral Diffie-Hellman, DHE_RSA), как раз и описанный в статье.
Там написано что в 99.9% случаях серверный открытый ключ — это RSA-ключ и никто не использует DH-ключи в сертификатах. То есть не используется статический обмен ключами по Диффи-Хеллману (static Diffie-Hellman, DH_RSA), когда DH-ключ хранится в сертификате.
Вместо этого применяется динамический обмен ключами по Диффи-Хеллману (ephemeral Diffie-Hellman, DHE_RSA), как раз и описанный в статье.
Я всё внимательно прочитал
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.
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.
В фразе
А на практике применяется:
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.
«use DHE_RSA» это лозунг, призыв использовать DHE_RSA.
В то время как в списке опций ещё стоит простой RSA. Речь о том что используется именно он.
В то время как в списке опций ещё стоит простой RSA. Речь о том что используется именно он.
99.9% of the time, this means RSA. Everybody does RSA
… So nobody really uses Diffie-Hellman in certificates.
Да он имеет в виду, что никто не использует сертификаты с фиксированными DH-ключами.
В сертификат можно зашить не RSA-ключ, а DH-ключ и использовать его вместо генерации каждый раз на сессию.
Вот другой пост об этом:
security.stackexchange.com/questions/12052/confusing-about-ephemeral-diffie-hellman
В сертификат можно зашить не RSA-ключ, а DH-ключ и использовать его вместо генерации каждый раз на сессию.
Вот другой пост об этом:
security.stackexchange.com/questions/12052/confusing-about-ephemeral-diffie-hellman
Не уводите в сторону. Речь не о том кто там что пишет, а о том как это всё работает. Есть несколько алгоритмов обмена ключами: RSA, Diffie-Hellman, Elliptic Curve Diffie-Hellman и так далее. Клиент и сервер договариваются о том алгоритме который они оба понимают и предпочитают. Так вот, я говорю о том, что в большинстве случаев это не Diffie-Hellman (ни статический ни динамический). И не цепляйтесь за один текст по ссылке, погуглите ещё.
Так же всю жизнь считал, что обмен ключами происходит по алгоритму RSA в SSL, в статье же говорится почему то только о DH. Может быть найдется эксперт могущий внести ясность в этот вопрос?
На Hacker News в обсуждении это тоже заметили: news.ycombinator.com/item?id=6101646
DH это важно и интересно, но не все понимают что он в реальности применяется не так часто. В большинстве сеансов SSL и TLS действительно обмен ключей происходит путем их шифрования с помощью RSA. Подробнее про оба варианта — в wiki или упомянутом RFC 5246:
* 7.4.7.1. RSA-Encrypted Premaster Secret Message
* 8.1.1. Computing the Master Secret -> RSA
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
По данным 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 алгоритмы, то впоследствии они смогут расшифровать поток, получив приватные ключи.
Особенно ситуация плоха в случае с IE (даже 10 версии), который поддерживает Диффи-Хеллмана только на эллиптических кривых (RSA и ECDSA сертификаты), либо классический Диффи-Хеллман с более редкими сертификатами DSS (DSA).
По подсчетам netcraft 99,7 % соединений с IE и по 66% — с Chrome, Opera и Firefox не будут использовать Диффи-Хеллмана.
Еще они вспомнили PRISM, и пояснили, что если операторы PRISM записывали шифрованный SSL/TLS трафик, который не использовал perfect forward secrecy алгоритмы, то впоследствии они смогут расшифровать поток, получив приватные ключи.
Зачем нужен root, если две стороны могут просто открыто обменяться открытыми ключами, которыми будут шифроваться входящие сообщения, а декриптоваться не переданными закрытыми?
Как они узнают закрытые ключи друг друга, если видят друг друга первый раз?
А зачем им закрытый ключ другого собеседника? Это же просто: участник А шифрует свое послание открытым ключом Б, и только Б может его расшифровать, поскольку знает свой закрытый ключ (ну и наоборот).
Как я понял, в данном случае утверждается только то, что данный алгоритм установления соединения используют для того, чтобы использовать симметричное шифрование (для шифровки и декодирования — один и тот же ключ), мотивируя это тем, что в этом случае кодировка/декодировка занимают меньше ресурсов.
Как я понял, в данном случае утверждается только то, что данный алгоритм установления соединения используют для того, чтобы использовать симметричное шифрование (для шифровки и декодирования — один и тот же ключ), мотивируя это тем, что в этом случае кодировка/декодировка занимают меньше ресурсов.
Все дело в том, что для шифрования данных используется открытый ключ сервера, защищенный сертификатом безопасности.
Прошу не пинать, говорю как я это себе понял, когда разбирался в этом вопросе.
Итак, ассимитричные алгоритмы — весьма ресурсоёмкие алгоритмы, и они не используются для обработки больших объёмов данных. Взять ту же ЭЦП (пардон, теперь это ЭП зовётся). Там ведь не шифруется весь документ открытым ключём и не расшифровывается закрытым, там по документу вычисляется hash и вот уже hash сторона А шифрует открытым ключом стороны Б. А сторона Б, получив документ, сама вычисляется hash, потом расшифровывает ЭП своим закрытым ключом и сравнивает полученные hash.
Так и при шифровании, шифрование не производится на ассиметричных ключах (зачастую), а с помощью ассимитричных ключей передаётся общий закрытый ключ, который генерится, и который используется уже в симметричном алгоритме шифрования. Симметричные алгоритмы, соответственно, на порядок менее ресурсоёмки. Как то так!
Итак, ассимитричные алгоритмы — весьма ресурсоёмкие алгоритмы, и они не используются для обработки больших объёмов данных. Взять ту же ЭЦП (пардон, теперь это ЭП зовётся). Там ведь не шифруется весь документ открытым ключём и не расшифровывается закрытым, там по документу вычисляется hash и вот уже hash сторона А шифрует открытым ключом стороны Б. А сторона Б, получив документ, сама вычисляется hash, потом расшифровывает ЭП своим закрытым ключом и сравнивает полученные hash.
Так и при шифровании, шифрование не производится на ассиметричных ключах (зачастую), а с помощью ассимитричных ключей передаётся общий закрытый ключ, который генерится, и который используется уже в симметричном алгоритме шифрования. Симметричные алгоритмы, соответственно, на порядок менее ресурсоёмки. Как то так!
сторона А шифрует открытым ключом стороны Б. Затем сторона Б, получив документ, сама вычисляется hash, потом расшифровывает ЭП своим закрытым ключом и сравнивает полученные hash.
Может быть все таки сторона А подписывает hash своего документа своим закрытым ключем, а затем сторона Б вычисляет hash и проверяет его открытым ключем стороны А? По тому как написано у вас, получается, что сторона А подписывает документ специально для стороны Б, а не для всех желающих удостовериться в подлинности.
Подскажите, если я ошибаюсь.
Ой да, Вы правы, в отношении ЭП шифрование hash осуществляется на закрытом ключе стороны А, и тогда любая стороная получив документ, может вычислить hash и расшифровать hash из ЭП на открытом ключе стороны А.
Та схему которую я ранее описал, похоже актуальна для шифрования.
Спасибо что поправили, а то так бы и зафиксировалось у меня ошибочное понимаени! :)
Кстати, вот тут очень неплохо описана схема ЭП при использовании асимметричной схемы.
Та схему которую я ранее описал, похоже актуальна для шифрования.
Спасибо что поправили, а то так бы и зафиксировалось у меня ошибочное понимаени! :)
Кстати, вот тут очень неплохо описана схема ЭП при использовании асимметричной схемы.
del
Нотариально заверенный открытый ключ. :) Иначе Ева может передать Бобу и Алисе свои открытые ключи (MITM attack), а они ничего не заметят.
Собственно говоря, нотариальным заверением открытых ключей и занимаются центры сертификации :)
ОК, то есть Ева берёт контроль над соединением, «отцепляет» Алису от Боба (так что они не могут поднять шухер, не сумев расшифровать сообщения друг друга) и начинает общаться с каждым по отдельности? Расшифровывая сообщения своим закрытым ключом, и шифруя снова оригинальным открытым ключом Алисы и Боба для последующей передачи?
Я правильно понимаю суть атаки?
Я правильно понимаю суть атаки?
Да, абсолютно верно.
Да. Сие зовётся «Man in the middle». Вы описали его во всей красе.
Объясните, пожалуйста, если Ева взяла полный контроль над соединением, то что ей мешает по описанной вами схеме создать два шифрованных соединения по DH-алгоритму. Т.е. какое преимущество дает DH-алгоритм перед простым шифрованием открытым ключем/дешифровкой закрытым ключем в плане атаки MITM
В плане MITM они идентичны. Точнее, они идентично уязвимы. Для того, чтобы закрыть эту уязвимость и придумали сертификаты и центры сертификации.
Если соединение не «прослушивается», то мы создаём пару ключей DH, отправляем открытый, в ответ получаем ключ сервера, подписанный центром сертификации, который заверяет, что этот ключ принадлежит именно тому серверу, к которому мы соединяемся. После проверки подписи центра мы получаем зелёную плашечку в браузере.
А если Ева перехватила соединение, то ей придётся создать две пары DH-ключей: который используется для соединения с нами, и который используется для соединения с удалённым сервером. Но ключ Евы не будет подписан авторизованным центром сертификации, поэтому браузер сообщит нам о том, что что-то не так.
Но даже с HTTPS (SSL) есть целый ряд проблем. На этот счёт есть замечательная статья. Возможно, zavg стоит добавить эту ссылку в статью.
Если соединение не «прослушивается», то мы создаём пару ключей DH, отправляем открытый, в ответ получаем ключ сервера, подписанный центром сертификации, который заверяет, что этот ключ принадлежит именно тому серверу, к которому мы соединяемся. После проверки подписи центра мы получаем зелёную плашечку в браузере.
А если Ева перехватила соединение, то ей придётся создать две пары DH-ключей: который используется для соединения с нами, и который используется для соединения с удалённым сервером. Но ключ Евы не будет подписан авторизованным центром сертификации, поэтому браузер сообщит нам о том, что что-то не так.
Но даже с HTTPS (SSL) есть целый ряд проблем. На этот счёт есть замечательная статья. Возможно, zavg стоит добавить эту ссылку в статью.
На каждую хитрую гайку найдется свой болт с резьбой. В указанной вами статье описывается «принуждение» клиента к соединению по HTTP, на что уже есть ответная мера — HTTP Strict Transport Security (HSTS):
en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
Потому что между двумя сторонами может находиться третья. Атака «Человек посередине» называется.
Асимметричная крипта медленная
Отличная статья, для меня HTTPS всегда был в виде «weird black box», а алгоритм передачи ключей вызывал сомнения и непонимание, а теперь я все понял и смогу начать жить полной жизнью!
Извините, я тоже в этой теме профан.
Как верифицируются ключи CA, вернее как убедиться, что сертификат — настоящий, и CA именно тот, за кого себя выдаёт?
Как верифицируются ключи CA, вернее как убедиться, что сертификат — настоящий, и CA именно тот, за кого себя выдаёт?
В каждой ОС или браузере хранятся открытые ключи доверенных центров сертификации. Сверяются по списку.
То есть, теоретически это можно обойти, если «хакнуть» или подсунуть мне левое обновление ОС или браузера? Так бывает вообще?
Да, можно.
Подсовывать обновление не обязательно. В случае Windows можно сделать свой CA-сертификат и установить его в хранилище доверенных сертификатов (certmgr.exe/certmgr.msc).
Но зелёные полоски так делать не получится — нужно уже делать левое обновление для браузера.
Подсовывать обновление не обязательно. В случае Windows можно сделать свой CA-сертификат и установить его в хранилище доверенных сертификатов (certmgr.exe/certmgr.msc).
Но зелёные полоски так делать не получится — нужно уже делать левое обновление для браузера.
А в случае с PRISM, как я понимаю, спецслужбам ничто не мешает договориться с одним из доверенных CA, находящимися в Америке, чтобы сделать валидные сертификаты для интересующих сервисов и использовать их в атаках типа man-in-middle? Ну кроме авторитета СА, которым он дорожит, конечно.
В целом, да.
Но если такой CA подпишет запрос на сертификат от недостаточно проверенной стороны, то откреститься от него не получится, так как получившийся сертификат можно будет скачать и предъявить общественности. Это будет равносильно концу бизнеса для CA, поэтому никто так не делает :)
Хотя по интернету ходят слухи, что CA подписывает направо и налево промежуточные сертификаты для того, чтобы американские компании могли проксировать https-трафик своих сотрудников, я в это не верю и ни разу доказательств не видел.
Но если такой CA подпишет запрос на сертификат от недостаточно проверенной стороны, то откреститься от него не получится, так как получившийся сертификат можно будет скачать и предъявить общественности. Это будет равносильно концу бизнеса для CA, поэтому никто так не делает :)
Хотя по интернету ходят слухи, что CA подписывает направо и налево промежуточные сертификаты для того, чтобы американские компании могли проксировать https-трафик своих сотрудников, я в это не верю и ни разу доказательств не видел.
NSA имело прямой доступ к данным Google, Facebook, Apple. Несмотря на это, почти никто не отказался от их услуг после скандала. Так что повозмущаются люди в Интернетиках, петиции соберут и стерпят. А тем временем законы примут нужные.
Фраза «NSA имело прямой доступ» должна быть заменена на «где-то утекли картинки и графики схемы, по которой NSA могло иметь доступ». С сертификатом всё намного проще — либо есть подписанный промежуточный CA у шпиёнов, либо его нет.
Да у не нужен он им — например, у FBCA, ECA, полиции и DoD есть свои CA [хомячки срочно побежали удалять их из списка доверенных].
Да у не нужен он им — например, у FBCA, ECA, полиции и DoD есть свои CA [хомячки срочно побежали удалять их из списка доверенных].
Службам проще ковыряться в «data at rest» нежели в «data in transit».
Злоумышленник, подключившийся каналу, будет видеть лишь “мусор”, гуляющий по сети взад-вперед.
Мало того что он будет видеть лишь «мусор» (в криптографии это называется semantic security), он также никоим образом не сможет изменить данные незаметно для другой стороны (data integrity). При чем, очевидно, что первое условие само по себе никакой безопасности не гарантирует.
Тема
До двоеточия хорошо и качественно раскрыто.
Но «что должен знать каждый Web-разработчик» слабо. Много раз сталкивался с тем, что люди не понимают от чего именно засчищает https.
https позволяет защитится от man-in middle класса атак. (чтения трафика, подмена трафика, представление себя за другого).
Однако https не защищает от любых других атак. То есть различные cross-scripting и еще множество типов атак как работали так и будут работать.
Как HTTPS обеспечивает безопасность соединения: что должен знать каждый Web-разработчик
До двоеточия хорошо и качественно раскрыто.
Но «что должен знать каждый Web-разработчик» слабо. Много раз сталкивался с тем, что люди не понимают от чего именно засчищает https.
https позволяет защитится от man-in middle класса атак. (чтения трафика, подмена трафика, представление себя за другого).
Однако https не защищает от любых других атак. То есть различные cross-scripting и еще множество типов атак как работали так и будут работать.
zavg Статья отличная спасибо.
А я оставлю для интересующихся вот эту ссылку: en.wikipedia.org/wiki/Server_Name_Indication
Здесь описано, что было добавлено в TSL, чтобы стала возможной ситуация «каждый домен на одном и том же IP-адресе использует свой собственный сертификат».
Узнал про эту технологию, когда бодался, почему у меня подхватывается не так строится цепочка сертификатов в Java 1.6 при обращении к подобному мультихост-домену. Выяснилось, что поддержка SNI была добавлена лишь начиная с версии Java 1.7.
А я оставлю для интересующихся вот эту ссылку: en.wikipedia.org/wiki/Server_Name_Indication
Здесь описано, что было добавлено в TSL, чтобы стала возможной ситуация «каждый домен на одном и том же IP-адресе использует свой собственный сертификат».
Узнал про эту технологию, когда бодался, почему у меня подхватывается не так строится цепочка сертификатов в Java 1.6 при обращении к подобному мультихост-домену. Выяснилось, что поддержка SNI была добавлена лишь начиная с версии Java 1.7.
Что значит нельзя использовать кеширование при HTTPS? Если первый запрос в гугле даёт ответ, что можно? Либо я неправильно читаю\думаю?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как HTTPS обеспечивает безопасность соединения: что должен знать каждый Web-разработчик