Comments 36
Спасибо за перевод интересной статьи.
P.S. Некоторые люди все же читают теги :)
P.S. Некоторые люди все же читают теги :)
UFO just landed and posted this here
Имени Боб в России, как бы, нет ;)
Если не ошибаюсь, в России для таких примеров используют Бориса :)
Боб — негласный общепринятый мировой стандарт)
Боб — негласный общепринятый мировой стандарт)
Пруф в студию.
UFO just landed and posted this here
UFO just landed and posted this here
Предлагаете Алису и Боба называть Чук и Гек?
Разумеется нет. Полностью SSL handshake за 220 мс мог пройти только где-нибудь в Калифорнии, с местным же сервером, но никак не в России.
> На этом всё!
А дальше началось самое интересное.
Где-то глубоко, в самых глубинах оперативной памяти впыхнул бит, потом еще один и еще. Это просыпались тулбары. Почувствовав вкусную добычу они ломанулись парсить содержимое страницы: «что, что же ему нужно?» — бешено полыхало в их электронных мозгах. «Может он хочет купить слона?» — думал яндекс.бар. Через несколько миллисекунд его анализатор изображений завершил работу и выдал результат: пользователь ищет слона! Вновь полетели биты по проводам — тулбар докладывал в контору, что Бобу срочно нужен слон. Через несколько секунд главный сервер директа уже обладал всей необходимой информацией и подобрал десятки объявлений о продаже слонов всех пород и расцветок. Теперь на всех сайтах Боб увидит желанное объявление, к которому он стремился всю жизнь. Слоны будут окружать его повсюду. С чувством глубокого удовлетворения Яндекс.бар засыпал, он выполнил свою работу, он сделал еще одного человека счастливым.
Боб ненавидел слонов, с тех самых пор, как в далеком детстве в зоопарке, большой африканский слон спер у него, у маленького мальчика, мороженное, которое он купил вместо школьного завтрака. Почему-то именно тогда он захотел стать программистом баз данных. На экране компьютера была книга по PostgreSQL.
Боб сделал заказ. Открылось окно подтверждения платежа.
В глубина компьютера что-то снова проснулось.
А дальше началось самое интересное.
Где-то глубоко, в самых глубинах оперативной памяти впыхнул бит, потом еще один и еще. Это просыпались тулбары. Почувствовав вкусную добычу они ломанулись парсить содержимое страницы: «что, что же ему нужно?» — бешено полыхало в их электронных мозгах. «Может он хочет купить слона?» — думал яндекс.бар. Через несколько миллисекунд его анализатор изображений завершил работу и выдал результат: пользователь ищет слона! Вновь полетели биты по проводам — тулбар докладывал в контору, что Бобу срочно нужен слон. Через несколько секунд главный сервер директа уже обладал всей необходимой информацией и подобрал десятки объявлений о продаже слонов всех пород и расцветок. Теперь на всех сайтах Боб увидит желанное объявление, к которому он стремился всю жизнь. Слоны будут окружать его повсюду. С чувством глубокого удовлетворения Яндекс.бар засыпал, он выполнил свою работу, он сделал еще одного человека счастливым.
Боб ненавидел слонов, с тех самых пор, как в далеком детстве в зоопарке, большой африканский слон спер у него, у маленького мальчика, мороженное, которое он купил вместо школьного завтрака. Почему-то именно тогда он захотел стать программистом баз данных. На экране компьютера была книга по PostgreSQL.
Боб сделал заказ. Открылось окно подтверждения платежа.
В глубина компьютера что-то снова проснулось.
наблюдение: первый комментатор всегда читает теги.
>>Четыре байта Unix time и 28 случайных байт.
А что произойдет c этими 4 байтами 19 января 2038 года с 03:14:08?
А что произойдет c этими 4 байтами 19 января 2038 года с 03:14:08?
Возможно, подправят код, и будет 5 байт юникстайм и 27 байт рандома.
UFO just landed and posted this here
Ничего страшного — они тут нужны как дополнительная гарантия уникальности сообщений, никто их не сравнивает — а значит, и проблема знака отсутствует.
Есть также проблема возможного повтора, но, во-первых, она наступит на 40 лет позже, а во-вторых, за полную Unix-эпоху либо алгоритмы шифрования сменятся, либо ключевая пара сервера, либо сайт исчезнет. Не говоря уже об остальных 28ми байтах.
Есть также проблема возможного повтора, но, во-первых, она наступит на 40 лет позже, а во-вторых, за полную Unix-эпоху либо алгоритмы шифрования сменятся, либо ключевая пара сервера, либо сайт исчезнет. Не говоря уже об остальных 28ми байтах.
Сертификат Амазона уже давно просрочен, а браузер до сих пор говорит «Всё ок». Да и RC4 уже взломали. Как же быстро время летит.
UFO just landed and posted this here
так и не понял, что за модуль — прим. перев.
модуль n же.
Вы выбираете два простых числа, p и q. Умножаете их и получаете n. Далее, вы выбираете простую публичную экспоненту e, которая будет шифрующей экспонентой, и специально подобранную обратную e, d, которая будет дешифрующей. Затем вы делаете n и e публичными и храните d в секрете. Про p и q можно забыть, или же хранить вместе с d.
Как мы уже убедились ранее, d получается из факторизации n обратно к p и q, что довольно-таки сложно.
Если быть точным, то пропущен немаловажный для RSA шаг (ну или 2):
1) выбираем 2 достаточно больших, примерно одного размера простых числа p и q.
2) перемножаем их, получаем n.
3) вычисляем функцию Эйлера для числа n, которая будет равна: Φ(n) = (p-1)(q-1), так как p и q — простые числа.
4) выбираем открытый ключ для шифрования e, который меньше Φ(n).
5) находим секретный ключ d для расшифрования, как обратный элемент e по модулю Φ(n), т.е. d = e^-1 (mod Φ(n)).
6) теперь можно забыть p,q, Φ(n), у нас есть все для дальнейшей работы.
Эх, напомнило курс «Введение в криптографию»! Интересные были темы…
А квантовые протоколы вообще где нибудь используются в быту?
А квантовые протоколы вообще где нибудь используются в быту?
UFO just landed and posted this here
Если я правильно понял, то ж только если SNI на сервере и клиенте поддерживается, что (как минимум в теории) не всегда верно.
А при условии, что все пакеты такого общения перехвачены, расшифровать получится?
Часто компании избегают обычного DH из-за того, что он требует значительных вычислительных ресурсов со стороны сервера для того, чтобы сгенерировать начальные параметры DH при установке соединения. В этом смысле ECDH лучше. Например, на серверах google и facebook DH явно выключен, а ECDH — используется.
Эта статья хорошо сэкономила бы мне время две недели назад, когда я заинтересовался этой темой настолько, что написал «игрушечного» tls — клиента на Питоне, чтобы ответить на множество возникших у меня при чтении спецификаций вопросов «А что если...?». В rfc было недостаточно информации, поэтому пришлось много читать исходники openssl.
Написанный код доступен под свободной лицензией MIT по адресу github.com/alexbers/manual-tls. Он делает всё то, о чём написано в статье, выводя на экран детальный лог действий, только обмен ключами производится с помощью алгоритма Диффи-Хэллмана. Почему именно этот алгоритм?
1) Он мало где реализован в игрушечных реализациях ssl.
2) Он обеспечивает Perfect forward secrecy, «совершенную прямую секретность». Это значит, что если закрытый ключ с вашего сервера утечёт, например, его достанут ФБР, полиция или хакеры, то содержимое предыдущих записанных tls-сессий расшифровать все равно не получится. Ещё таким свойством обладает Elliptic curve Diffie–Hellman, который использует эллиптические кривые, нынче так модные на хабре.
Ещё реализации ssl/tls на Питоне:
— Toytls: github.com/bjornedstrom/toytls
— Tlslite: trevp.net/tlslite/
Бесплатный сервис, выводящий информацию о настройках https на узле и о возможных слабостях настройки:
— www.ssllabs.com/ssltest/index.html
Самое полное, из встретившихся мне описаний современных атак на https, собранных в одном англоязычном документе(BEAST, CRIME, BREACH, LUCKY 13, слабости RC4 и.т.д):
— www.isecpartners.com/media/106031/ssl_attacks_survey.pdf
P.S. спасибо thevar1able за приглашение
Написанный код доступен под свободной лицензией MIT по адресу github.com/alexbers/manual-tls. Он делает всё то, о чём написано в статье, выводя на экран детальный лог действий, только обмен ключами производится с помощью алгоритма Диффи-Хэллмана. Почему именно этот алгоритм?
1) Он мало где реализован в игрушечных реализациях ssl.
2) Он обеспечивает Perfect forward secrecy, «совершенную прямую секретность». Это значит, что если закрытый ключ с вашего сервера утечёт, например, его достанут ФБР, полиция или хакеры, то содержимое предыдущих записанных tls-сессий расшифровать все равно не получится. Ещё таким свойством обладает Elliptic curve Diffie–Hellman, который использует эллиптические кривые, нынче так модные на хабре.
Ещё реализации ssl/tls на Питоне:
— Toytls: github.com/bjornedstrom/toytls
— Tlslite: trevp.net/tlslite/
Бесплатный сервис, выводящий информацию о настройках https на узле и о возможных слабостях настройки:
— www.ssllabs.com/ssltest/index.html
Самое полное, из встретившихся мне описаний современных атак на https, собранных в одном англоязычном документе(BEAST, CRIME, BREACH, LUCKY 13, слабости RC4 и.т.д):
— www.isecpartners.com/media/106031/ssl_attacks_survey.pdf
P.S. спасибо thevar1able за приглашение
Ух ты! Очень здорово. Не хотите статью написать? :)
У меня есть идея статьи про использование tls для защищённой коммуникации между людьми(в простонародии — крипточат).
Такая тема появилась потому, что во всех продуктах, которые я видел, возникает проблема доверия — я должен доверять их разработчикам. Даже если всё шифрование происходит в браузере javascript'ом и его код трижды проверен, то я не могу быть уверен, что к автору сервера не пришли и, скажем, не попросили отдавать мне особый javascript-код(см., например странную историю про LavaBit).
К тому же в коде этих продуктов могут быть ошибки. Возьмем, например, сервис, первый по ссылке гугла по запросам «secure chat» и «crypto chat», который называется Cryptocat. Примерно два месяца назад в коде обнаружилась ошибка — из-за ошибки в реализации генератора случайных чисел групповые сообщения, которые передавались в период с 17 октября 2011 года по 15 июня 2013 года стало возможно расшифровать, см. Decryptocat. Причём в начале 2013 года проводился аудит кода компанией Veracode, который присудил ей «Security Quality Score of 100/100».
Моя идея состоит в том, чтобы не писать совсем никакого кода, а использовать только библиотеку openssl. Собеседники должны доверять только друг другу и библиотеке openssl.
Небольшой спойлер, о том, как можно этого достичь. Один человек выполняет команду:
а другой:
Но у такого решения есть две проблемы:
1) Что делать, если оба человека за NAT'ом?
2) Оно не защищает от атаки «человек посередине».
И ещё одна маленькая, но сложная для решения проблема:
1) Даже если данные нельзя расшифровать, доступна «метаинформация» о соединении: кто с кем соединялся, когда и сколько данных передано.
Сейчас из всех способов их решения я пытаюсь найти лучший, если результаты меня устроят — напишу статью.
Такая тема появилась потому, что во всех продуктах, которые я видел, возникает проблема доверия — я должен доверять их разработчикам. Даже если всё шифрование происходит в браузере javascript'ом и его код трижды проверен, то я не могу быть уверен, что к автору сервера не пришли и, скажем, не попросили отдавать мне особый javascript-код(см., например странную историю про LavaBit).
К тому же в коде этих продуктов могут быть ошибки. Возьмем, например, сервис, первый по ссылке гугла по запросам «secure chat» и «crypto chat», который называется Cryptocat. Примерно два месяца назад в коде обнаружилась ошибка — из-за ошибки в реализации генератора случайных чисел групповые сообщения, которые передавались в период с 17 октября 2011 года по 15 июня 2013 года стало возможно расшифровать, см. Decryptocat. Причём в начале 2013 года проводился аудит кода компанией Veracode, который присудил ей «Security Quality Score of 100/100».
Моя идея состоит в том, чтобы не писать совсем никакого кода, а использовать только библиотеку openssl. Собеседники должны доверять только друг другу и библиотеке openssl.
Небольшой спойлер, о том, как можно этого достичь. Один человек выполняет команду:
openssl s_server -nocert -cipher ADH-AES256-SHAа другой:
openssl s_client -connect host:4433 -cipher ADH-AES256-SHAНо у такого решения есть две проблемы:
1) Что делать, если оба человека за NAT'ом?
2) Оно не защищает от атаки «человек посередине».
И ещё одна маленькая, но сложная для решения проблема:
1) Даже если данные нельзя расшифровать, доступна «метаинформация» о соединении: кто с кем соединялся, когда и сколько данных передано.
Сейчас из всех способов их решения я пытаюсь найти лучший, если результаты меня устроят — напишу статью.
Вообще говоря, удивительно, но в Интернете действительно мало такой информации по HTTPS, и вообще SSL/TLS, которая бы позволяла первоначально разобраться в теме. Такое ощущение, что почти любому, кто начинает этим интересоваться (и/или использовать в работе), приходится сначала пообщаться на эту тему со знающими друзьями или коллегами, и только потом уже переходить к чтению документации, RFC и прочего.
Если бы хотя бы что-то подобное писали, рассказывая про HTTPS (но, конечно, с бо́льшим количеством подробностей и с необходимыми уточнениями), людям было бы уже намного проще разобраться, мне кажется.
HTTPS широко используется для защиты информации от перехвата, а также, как правило, обеспечивает защиту от атак вида man-in-the-middle — в том случае, если сертификат проверяется на клиенте, и при этом приватный ключ сертификата не был скомпрометирован, пользователь не подтверждал использование неподписанного сертификата, и на компьютере пользователя не были внедрены сертификаты центра сертификации злоумышленника.
Если бы хотя бы что-то подобное писали, рассказывая про HTTPS (но, конечно, с бо́льшим количеством подробностей и с необходимыми уточнениями), людям было бы уже намного проще разобраться, мне кажется.
Sign up to leave a comment.
Первые несколько миллисекунд HTTPS соединения