Обновить
Комментарии 36
Спасибо за перевод интересной статьи.

P.S. Некоторые люди все же читают теги :)
НЛО прилетело и опубликовало эту надпись здесь
Имени Боб в России, как бы, нет ;)
Если не ошибаюсь, в России для таких примеров используют Бориса :)
Боб — негласный общепринятый мировой стандарт)
Какое имеет отношение к русскому имени?
На счет Бориса сходу сложно вспомнить книгу российского автора. Но даже погуглив чутка, натыкаюсь на таких участников протоколов, как Антон и Борис, Анна и Борис. Если вспомню конкретную книгу (вроде бы видел в каком-то учебнике Молдовяна Н.А.), то дам знать.
Фонетический алфавит же.
Если имеется ввиду метапеременные, то согласен)
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Предлагаете Алису и Боба называть Чук и Гек?
Разумеется нет. Полностью SSL handshake за 220 мс мог пройти только где-нибудь в Калифорнии, с местным же сервером, но никак не в России.
> На этом всё!

А дальше началось самое интересное.

Где-то глубоко, в самых глубинах оперативной памяти впыхнул бит, потом еще один и еще. Это просыпались тулбары. Почувствовав вкусную добычу они ломанулись парсить содержимое страницы: «что, что же ему нужно?» — бешено полыхало в их электронных мозгах. «Может он хочет купить слона?» — думал яндекс.бар. Через несколько миллисекунд его анализатор изображений завершил работу и выдал результат: пользователь ищет слона! Вновь полетели биты по проводам — тулбар докладывал в контору, что Бобу срочно нужен слон. Через несколько секунд главный сервер директа уже обладал всей необходимой информацией и подобрал десятки объявлений о продаже слонов всех пород и расцветок. Теперь на всех сайтах Боб увидит желанное объявление, к которому он стремился всю жизнь. Слоны будут окружать его повсюду. С чувством глубокого удовлетворения Яндекс.бар засыпал, он выполнил свою работу, он сделал еще одного человека счастливым.

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

Боб сделал заказ. Открылось окно подтверждения платежа.

В глубина компьютера что-то снова проснулось.
наблюдение: первый комментатор всегда читает теги.
>>Четыре байта Unix time и 28 случайных байт.

А что произойдет c этими 4 байтами 19 января 2038 года с 03:14:08?
Возможно, подправят код, и будет 5 байт юникстайм и 27 байт рандома.
НЛО прилетело и опубликовало эту надпись здесь
Ничего страшного — они тут нужны как дополнительная гарантия уникальности сообщений, никто их не сравнивает — а значит, и проблема знака отсутствует.

Есть также проблема возможного повтора, но, во-первых, она наступит на 40 лет позже, а во-вторых, за полную Unix-эпоху либо алгоритмы шифрования сменятся, либо ключевая пара сервера, либо сайт исчезнет. Не говоря уже об остальных 28ми байтах.
Сертификат Амазона уже давно просрочен, а браузер до сих пор говорит «Всё ок». Да и RC4 уже взломали. Как же быстро время летит.
НЛО прилетело и опубликовало эту надпись здесь
так и не понял, что за модуль — прим. перев.

модуль 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), у нас есть все для дальнейшей работы.
Эх, напомнило курс «Введение в криптографию»! Интересные были темы…
А квантовые протоколы вообще где нибудь используются в быту?
На сколько знаю, сейчас это только лабораторный эксперимент. До бытового использования квантовых протоколов еще очень далеко.
Спасибо за статью. Узнал, что домен тоже передаётся незашифрованным. Раньше думал, что только IP можно узнать, если есть возможность сниффать трафик.
Если я правильно понял, то ж только если SNI на сервере и клиенте поддерживается, что (как минимум в теории) не всегда верно.
А при условии, что все пакеты такого общения перехвачены, расшифровать получится?
Нет, расшифровать имея только записанные пакеты не получится. Зато, если не использовался обмен ключами по DH (почти не применяется [1], [2] кроме google и cloudflare; см Perfect forward secrecy), и будет доступен секретный ключ сертификата — расшифровать возможно. + см VVV комментарий от alexbers.
Часто компании избегают обычного 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 за приглашение
Ух ты! Очень здорово. Не хотите статью написать? :)
У меня есть идея статьи про использование tls для защищённой коммуникации между людьми(в простонародии — крипточат).

Такая тема появилась потому, что во всех продуктах, которые я видел, возникает проблема доверия — я должен доверять их разработчикам. Даже если всё шифрование происходит в браузере 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 широко используется для защиты информации от перехвата, а также, как правило, обеспечивает защиту от атак вида man-in-the-middle — в том случае, если сертификат проверяется на клиенте, и при этом приватный ключ сертификата не был скомпрометирован, пользователь не подтверждал использование неподписанного сертификата, и на компьютере пользователя не были внедрены сертификаты центра сертификации злоумышленника.

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