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




Скачать 176.97 Kb.
НазваниеПредставьте, что вы устройство, которое принимает инструкции. К вам может подключиться каждый желающий и отдать любую команду. Всё хорошо, но на каком-то
ТипДокументы
rykovodstvo.ru > Руководство эксплуатация > Документы
Представьте, что вы — устройство, которое принимает инструкции. К вам может подключиться каждый желающий и отдать любую команду. Всё хорошо, но на каком-то этапе потребовалось фильтровать личностей, которые могут вами управлять. Вот здесь и начинается самое интересное.

Как понять, кто может отдать команду, а кто нет? Первое, что приходит в голову — по паролю. Пусть каждый клиент перед тем, как передать новую команду, передаст некий пароль. Таким образом, вы будете выполнять только команды, которые сопровождались корректным паролем. Остальные — фтопку.




Именно так работает базовая авторизация HTTP (Auth Basic):
AuthType Basic

AuthName "My super secret zone!"

AuthUserFile /home/.htpasswd

Require valid-user


После успешной авторизации браузер просто-напросто будет передавать определённый заголовок при каждом запросе в закрытую зону:

Authorization: Basic YWRtaW46cGFzcw==


То есть исходное:

echo -n 'admin:pass' | base64

# YWRtaW46cGFzcw==


У данного подхода есть один большой недостаток — так как пароль (или логин-пароль, что по сути просто две части того же пароля) передаётся по каналу «как есть» — кто угодно может встрять между вами и клиентом и получить ваш пароль на блюдечке. А затем использовать его и распоряжаться вами, как угодно! 

Для предотвращения подобного безобразия можно прибегнуть к хитрости: использовать какой-либо двухсторонний алгоритм шифрования, где закрытым ключом будет как раз наш пароль, и явно его никогда не передавать. Однако проблемы это не решит — достаточно один раз узнать пароль и можно будет расшифровать любые данные, переданные в прошлом и будущем, плюс шифровать собственные и успешно маскироваться под клиента. А учитывая то, что пароль предназначен для человека, а люди склонны использовать далеко не весь набор из 256 байт в каждом символе, да и символов этих обычно около 6-8… в общем, комсомол не одобрит.

Что делать? А поступим так, как поступают настоящие конспираторы: при первом контакте придумаем длинную случайную строку (достаточно длинную, чтобы её нельзя было подобрать, пока светит это солнце), запомним её и все дальнейшие передаваемые данные будем шифровать с использованием этого «псевдонима» для настоящего пароля. А ещё периодически менять эту строку — тогда джедаи вообще не пройдут.




Первые две передачи (зелёные иконки на рисунке выше) — это фаза с «пожатием рук» (handshake), когда сначала мы говорим серверу о нашей легитимности, показывая правильный пароль, на что сервер нам отвечает случайной строкой, которую мы затем используем для шифрования и передачи любых данных.

Итак, для подбора ключа хакеру нужно будет либо найти уязвимость в алгоритме его генерации (как в случае с Dual_EC_DRBG), либо арендовать сотню-другую параллельных вселенных и несколько тысяч ATI-ферм для решения этой задачи при своей жизни. Всё это благодаря тому, что случайный ключ может быть любой длины и содержать любые коды из доступных 256, потому что пользователю-человеку никогда не придётся с ним работать.

Именно такая схема с временным ключом (сеансовый ключ, session key или ticket) в разных вариациях и используется сегодня во многих системах — в том числе SSL/TLS

 общие представления о принципах работы протокола SSL/TLS. Рассмотрим упрощённый вариант функционирования SSL/TLS, выделив в нем только самые важные для нас моменты.

Обычно началу обмена шифрованными данными, в SSL/TLS предшествует процесс установки соединения, рукопожатие (SSL handshake).

С помощью моего любимого инструмента Wireshark и немного модифицированной отладочной сборки Firefox мы попробуем разобраться, что же именно произошло.
По RFC 2818 Firefox знает, что «https» означает, что нужно использовать 443 порт для подключения к Amazon.com:



Приветствие клиента



TLS заворачивает весь траффик в «записи» различных типов. Мы видим, что первый байт пакета в HEX равен 0x16 = 22, что означает, что «запись» является «рукопожатием»:



Следующие два байта — 0x0301, означающие версию 3.1, что говорит о том, что TLS 1.0 на самом деле SSL 3.1.
Запись с рукопожатием разбита на несколько сообщений. Первый — «приветствие клиента» (0x01). Здесь есть несколько важных моментов: 


  • Случайность:


    Эти четыре байта — текущее Unix time, количество секунд с 1 Января, 1970. В нашем случае это 0x4a2f07ca. За ними идут 28 случайных байт, которые понадобятся позже.

  • ID сессии:


    В нашем случае это поле пусто. Если бы мы подключались к Amazon.com несколькими секундами ранее, то могли бы продолжить сессию и не проводить полное рукопожатие.

  • Cipher Suites:


    Список всех поддерживаемых браузером алгоритмов шифрования. По умолчанию используется очень сильный «TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA», за которым идут ещё 33 варианта. Не волнуйтесь, если ничего не понимаете. Далее мы узнаем, что Amazon не примет наш вариант по умолчанию.

  • Расширение server_name:


    Способ сказать amazon.com, что браузеру нужна страница по адресу www.amazon.com. Это довольно удобно, потому что TLS рукопожатие начинается задолго до HTTP траффика. В HTTP есть заголовок «Host», позволяющий хостить сотни сайтов на одном IP. SSL традиционно требовал разные IP для разных сайтов, но это расширение позволяет серверу отвечать сертификатом конкретного сайта.


Приветствие сервера



Amazon.com отвечает довольно крупной записью с рукопожатием, размером в два пакета (2,551 байт). В ней указана та же последовательность байт 0x0301, что означает согласие Amazon использовать TLS 1.0. В записи есть три подсообщения с интересными данными:


  1. Сообщение «Приветствие сервера»:



    • Четыре байта Unix time и 28 случайных байт.

    • ID сессии в 32 байтах для ускорения следующих запросов.

    • Из 34 алгоритмов, предложенных нами, Amazon выбрал «TLS_RSA_WITH_RC4_128_MD5» (0x0004). Это означает, что будет использоваться алгоритм RSA для проверки подписей сертификата и обмена ключами, алгоритм RC4 для шифрования данных, хэш функция MD5 для проверки содержимого. Мы обсудим всё это более подробно позже. Мне кажется, у Amazon есть свои причины для выбора именно этих алгоритмов, например, снижение нагрузки на CPU. Менее вероятный вариант — благодарность Ron Rivest, создателю всех трёх вышеуказанных алгоритмов.



  1. Сообщение с сертификатом:



    • Огромное сообщение в 2.464 байта и его сертификат, который клиент может использовать для валидации сертификата Amazon. Всё это также можно посмотреть в браузере.


  2. Сообщение «Приветствие сервера выполнено»


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


Проверка сертификата



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

Почему мы должны доверять сертификатам?

К нему прикреплена «подпись», длинное число в формате big-endian: 
Кто угодно мог прислать эти байты. Почему мы должны доверять этой подписи? Для ответа совершим небольшое путешествие в мир математики:

Небольшое введение в RSA



Некоторые люди задаются вопросом, имеет ли математика какую либо связь с программированием? Сертификаты — очень наглядный случай применения математики. Сертификат Amazon говорит нам, что нужно использовать RSA для проверки подписи. RSA был создан в 1970 профессорами MIT Ron Rivest, Adu Shamir и Len Adleman, нашедшими красивый способ соединить идеи, появившиеся за 2000 лет развития математки и создать простой алгоритм:

Вы выбираете два простых числа, p и q. Умножаете их и получаете n. Далее, вы выбираете простую публичную экспоненту e, которая будет шифрующей экспонентой, и специально подобранную обратную e, d, которая будет дешифрующей. Затем вы делаете n и e публичными и храните d в секрете. Про p и q можно забыть, или же хранить вместе с d.

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

C ≡ Me (mod n)

Это означает, что нужно умножить M на себя e раз. mod n означает, что мы берём только остаток от деления на n. Например, 11 AM + 3 часа = 2PM (mod 12 часов). Получатель знает d и может произвести обратную операцию для расшифровки:

Cd ≡ (Me)d ≡ Me*d ≡ M1 ≡ M (mod n)

Также интересно, что человек с d может подписать документ возведя сообщение M в степень d:

Md ≡ S (mod n)

Это возможно благодаря тому, что подписывающая сторона делает публичными S, M, e и n. Кто угодно может проверить подпись S с помощью простых вычислений:

Se ≡ (Md)e ≡ Md*e ≡ Me*d ≡ M1 ≡ M (mod n)

Криптография с публичным ключом часто называется асимметричной, потому что ключ шифрования (в нашем случае e) не равен ключу дешифровки (d). Магия RSA работает из-за того, что вы можете рассчитать C ≡ Me (mod n) довольно быстро, но почти невозможно Cd ≡ M (mod n) не зная d. Как мы уже убедились ранее, d полуается из факторизации n обратно к p и q, что довольно-таки сложно.

Проверка подписей



Работая с RSA в реальной жизни важно помнить, что все числа должны быть __очень__ большими. Насколько? Сертификат Amazon подписан «VeriSign Class 3 Secure Server CA». Это значит, что n должно быть 2048 бит длинной, что в десятичном виде:

1890572922 9464742433 9498401781 6528521078 8629616064 3051642608 4317020197 7241822595 6075980039 8371048211 4887504542 4200635317 0422636532 2091550579 0341204005 1169453804 7325464426 0479594122 4167270607 6731441028 3698615569 9947933786 3789783838 5829991518 1037601365 0218058341 7944190228 0926880299 3425241541 4300090021 1055372661 2125414429 9349272172 5333752665 6605550620 5558450610 3253786958 8361121949 2417723618 5199653627 5260212221 0847786057 9342235500 9443918198 9038906234 1550747726 8041766919 1500918876 1961879460 3091993360 6376719337 6644159792 1249204891 7079005527 7689341573 9395596650 5484628101 0469658502 1566385762 0175231997 6268718746 7514321
(Удачи с подбором p и q. Если получится — можно сгенирировать поддельный VeriSign сертификат.)

Если мы возведём подпись S в степень публичного e VeriSign, а затем возьмём остаток от деления на модуль n, то получим расшифрованную подпись в hex: 

0001FFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFF00302130 0906052B0E03021A 05000414C19F8786 871775C60EFE0542 E4C2167C830539DB

По стандарту PKCS #1 v1.5, первый байт 00 для того, чтобы блок шифрования, сконвертированный в integer, был меньше, чем модуль(так и не понял, что за модуль — прим. перев.). Второй байт 01 указывает на то, что это операция с приватным ключом. Затем куча FF байт для того, чтобы забить пустое место. Завершается оно байтом 00, затем идёт последовательность «30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14», что означает применение SHA-1 функции. Последние 20 байт — результат SHA-1 от байт в signedCertificate.

Так как расшифрованное значение правильно отформатировано и последние байты соответствуют тем, что мы можем посчитать сами, мы можем предположить, что кто-то знающий приватный ключ «VeriSign Class 3 Secure Server CA» подписал это. 

Можно повторить процесс и удостовериться в том, что сертифика «VeriSign Class 3 Secure Server CA» был подписан VeriSign «Class 3 Public Primary Certification Authority».

Но почему надо ему доверять? В этой цепочке доверия нет больше звеньев.



Корневой «VeriSign Class 3 Public Primary Certification Authority» был подписан сам собой. Этот сертификат встроен в продукты Mozilla как безоговорочно доверенный сертификат.

Pre-master Ключ



Мы проверили Amazon.com и знаем его публичную шифрующую экспоненту e и модуль n. Кто угодно прослушивающий нас может сделать то же самое. Теперь нам надо сгенерировать случайный ключ, который атакующий не узнает. Это не так просто как может показаться, из-за уязвимости псевдогенератора случайных чисел в Netscape Navigator 1.1 SSL можно было взломать за 25 секунд на машинах того времени. Если не верите, что настоящая случайность — это сложно, можете спросить мэинтейнеров OpenSSL в Debian.

На Windows, например, функция генерации псевдослучайных чисел берёт данные из 125 источников. Firefox использует её результат и добавляет несколько бит собственных псевдослучайных данных

Очень важно держать в секрете 48-байтовы «pre-master ключ», так как многие вещи выводятся именно из него. Не удивительно, что в Firefox так сложно его найти. Мне пришлось собрать отладочную версию и установить флаги SSLDEBUGFILE и SSLTRACE чтобы его увидеть

4456: SSL[131491792]: Pre-Master Secret [Len: 48]
03 01 bb 7b 08 98 a7 49 de e8 e9 b8 91 52 ec 81 ...{...I.....R…
4c c2 39 7b f6 ba 1c 0a b1 95 50 29 be 02 ad e6 L.9{......P)…
ad 6e 11 3f 20 c4 66 f0 64 22 57 7e e1 06 7a 3b .n.? .f.d«W~..z;

Он не совсем случаен, первые два байта по стандарту TLS должны быть 03 01.

Обмен ключами
Теперь нам надо передать это секретное число в Amazon.com. Так как Amazon пожелал использовать „TLS_RSA_WITH_RC4_128_MD5“, мы зашифруем его RSA. Можно использовать в качестве сообщения только 48 байт pre-master ключа, но по стандарту PKCS #1 v1.5 нужно забить пустое место случайными данными и довести размер пакета до 128 байт. Так будет сложнее расшифровать пакет атакующему.

Наконец, Firefox отправляет последнее незашифрованное сообщение, запись „Change Cipher Spec“:



Это способ Firefox сказать Amazon, что он собирается использовать переданные ранее секретные ключи для следующих сообщений.

Вычисление Master Secret

Если мы сделали всё верно, то обе стороны теперь знают 48 байт pre-master ключа. Со стороны Amazon есть лёгкое недоверие, так как pre-master содержит только данные клиента и не содержит данных сервера. Исправим это вычислив master key.

master_secret = PRF(pre_master_secret, „master secret“, ClientHello.random + ServerHello.random)

PRF — псевдорандомная функция, которая определена в спецификациях и довольно хитра. В ней используются HMAC версии MD5 и SHA-1. По половине ввода отправляется в каждую функцию, получается результат, весьма устойчивый к атакам.

В результате получаем 48 байт master secret.

4C AF 20 30 8F 4C AA C5 66 4A 02 90 F2 AC 10 00 39 DB 1D E0 1F CB E0 E0 9D D7 E6 BE 62 A4 6C 18 06 AD 79 21 DB 82 1D 53 84 DB 35 A7 1F C1 01 19

Генерируем остальные ключи

Теперь, когда у двух сторон есть master secret, по спецификации мы можем вычислить все нужные для сессии ключи используя PRF для создания „блока ключей“, из которого и возьмём нужные данные:

key_block = PRF(SecurityParameters.master_secret, „key expansion“, SecurityParameters.server_random + SecurityParameters.client_random);

Байты из „блока ключей“ нужны для: 
client_write_MAC_secret[SecurityParameters.hash_size]
server_write_MAC_secret[SecurityParameters.hash_size]
client_write_key[SecurityParameters.key_material_length]
server_write_key[SecurityParameters.key_material_length]
client_write_IV[SecurityParameters.IV_size]
server_write_IV[SecurityParameters.IV_size]

Так как мы используем потоковое, а не блочное шифрование, нам не нужны векторы инициализации. Тем не менее, нам нужны два Message Authentication Code (MAC) ключа для каждой стороны, каждый по 16 байт, так как длина результата MD5 тоже 16 байт. К тому же RC4 использует 16 байтный ключ, который также понадобится обеим сторонам. В общем, нам понадобятся 2*16 + 2*16 = 64 байта из блока ключей

Запуская PRF, получаем:
client_write_MAC_secret = 80 B8 F6 09 51 74 EA DB 29 28 EF 6F 9A B8 81 B0
server_write_MAC_secret = 67 7C 96 7B 70 C5 BC 62 9D 1D 1F 4A A6 79 81 61
client_write_key = 32 13 2C DD 1B 39 36 40 84 4A DE E5 6C 52 46 72
server_write_key = 58 36 C4 0D 8C 7C 74 DA 6D B7 34 0A 91 B6 8F A7

Приготовтесь быть зашифрованными!

Последнее сообщение рукопожатия, отправляемое клиентом — „Финальное сообщение“. Это хитрое сообщение, которое доказывает, что никто не подделал рукопожатие и доказывает, что мы знаем ключ. Клиент берёт все байты из сообщений рукопожатия и складывает в буфер. Потом высчитываются 12 байт подтвеждения с использованием генератора псевдослучайных чисел, master key, строки „client finished“, и MD5 и SHA-1 от буфера.

verify_data = PRF(master_secret, „client finished“, MD5(handshake_messages) + SHA-1(handshake_messages))

Берём результат и добавляем в заголовок байт 0x14, указывающий на завершение, и байты длины 00 00 0с, чтобы показать, что мы отправляем 12 байт. Затем, как в будущем и для всех зашифрованных сообщений, нужно удостовериться, что расшифрованное содержимое никто не подделал. Используем MD5, а точнее его HMAC версию. 

HMAC_MD5(Key, m) = MD5((Key opad) ++ MD5((Key ipad) ++ m)
( означает XOR, ++ означает конкатенацию, „opad“ это байты „5c 5c… 5c“, и „ipad“ это байты „36 36… 36“).

В общем, мы высчитываем:
HMAC_MD5(client_write_MAC_secret, seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length + TLSCompressed.fragment));

Как вы могли заметить, мы подмешиваем номер запроса, который защищает от специфической атаки с повторением пакета.
Осталось только зашифровать.

RC4 Шифрование



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

RC4 начинается с создания 256 байтного массива S и заполнением его значениями от 0 до 255. Затем нужно пройти по массиву „вмешивая“ байты ключа. Это делается для создания автомата состояний, используемого для генерирования случайных байт. Затем мы перемешиваем массив S.

Графически это можно представить так:



Чтобы зашифровать байт, мы XORим псевдослучайный байт с байтом, который надо зашифровать.
Итак, всё довольно просто, и быстро работает. Мне кажется, из-за этого Amazon выбрал этот алгоритм.

Вспомним, что у нас есть „client_write_key“ и „server_write_key“. Это значит, что нам нужно два экземпляра RC4: один для расшифровки ответов, другой — для шифрования запросов.

Первые несколько случайных байт из „client_write“ это „7E 20 7A 4D FE FB 78 A7 33 ...“. Если поXORить эти байты с незашифрованным заголовком и проверить байты сообщения „14 00 00 0C 98 F0 AE CB C4 ...“, то получим то, что можно видеть на скриншоте Wireshark ниже:



Сервер делает почти то же самое. Он посылает „Change Cipher Spec“, а затем „финальное“ сообщение, которое включает все сообщения рукопожатия и незашифрованное „финальное“ сообщение. Это доказывает клиенту, что сервер смог расшифровать его сообщения.

Добро пожаловать на прикладной уровень!



Сейчас, через 220 миллисекунд (три часа спустя — прим. перев.), мы наконец готовы использовать прикладной уровень. Теперь можно обмениваться обычным HTTP траффиком, который будет зашифрован TLS с применением RC4 и проверен на случай подмены.

Сейчас рукопожатие завершено. Содержимое записи TLS теперь 0x17. Шифрованый траффик начинается с 17 03 01, что указывает на тип записи и версию TLS. 

Шифрование пакета:

GET /gp/cart/view.html/ref=pd_luc_mri HTTP/1.1
Host: www.amazon.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.10) Gecko/2009060911 Minefield/3.0.10 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive


даст примерно следующий результат:



Сервер делает то же самое. Расшифровка даёт нам следующее:



HTTP/1.1 200 OK
Date: Wed, 10 Jun 2009 01:09:30 GMT
Server: Server

Conection: close
Transfer-Encoding: chunked

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

Важно понимать, что на прикладном уровне может быть абсолютно что угодно. Есть множество других основанных на TCP/IP протоколов, которые могут работать поверх TLS. Например, FTPS. Всегда лучше использовать TLS вместо изобретения своего велосипеда.

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

Однако как стороны согласуют одинаковый сеансовый ключ, общаясь по незащищенным каналам связи?
Для этого существуют различные алгоритмы. Наиболее часто используемые в Интернет – это RSA(самый популярный) и эфемерный Диффи-Хеллмана (DHE/ECDHE).

В момент установки SSL/TLS соединения алгоритм согласования сеансовых ключей выбирает сервер.
Выбор происходит из списка алгоритмов, поддерживаемых клиентом, которые он передает на сервер.


Ниже на диаграмме показан процесс согласования сеансовых ключей в случаях RSA и DHE/ECDHE, а также информация, которую видит сниффер (Wireshark) в перехваченном SSL/TLS трафике.



В первом случае (согласование ключей RSA) в момент установки соединения клиент генерирует случайное число, предварительный секрет (pre-master secret). Шифрует его открытым ключом, полученным в сертификате от сервера. 
Отправляет в зашифрованном виде на сервер. Сервер расшифровывает предварительный секрет своим секретным ключом. Далее обе стороны, обладая одинаковым предварительным секретом, конвертируют его в главный и уже из него создают общий сеансовый ключ.
В ассиметричных алгоритмах шифрования (RSA) данные, зашифрованные открытым ключом, могут быть расшифрованы только секретным. При этом, открытый и секретный ключи должны быть связаны между собой определенным математическим образом, являются ключевой парой.


Во втором случае (согласование ключей DHE/ECDHE) все работает немного по-другому.
В момент установки нового соединения клиент и сервер генерируют пару случайных эфемерных (временных) ключей Диффи-Хеллмана.
Пара состоит из открытого и секретного ключей. Стороны обмениваются открытыми ключами. 
Далее клиент и сервер, используя свой закрытый и полученный открытый ключи, создают предварительный секрет, главный секрет и общий сеансовый ключ.
В данном алгоритме постоянный секретный ключ сервера (RSA/DSA/ECDSA) в шифрации не участвует и используется только для подписи открытых DH-ключей. Описание очень общее, есть подробная информация в статье на хабре (Как HTTPS обеспечивает безопасность соединения: что должен знать каждый Web-разработчикzavg.


Теперь возможно стало немного понятней.

Если клиент и сервер при согласовании сеансовых ключей используют алгоритм RSA, то перехваченный между ними трафик всегда можно расшифровать, имея секретный ключ сервера.
Дело в том, что в момент установки SSL/TLS-соединения клиент пересылает серверу зашифрованное значение предварительного секрета.
Предварительный секрет дешифруется секретным ключом сервера, далее вычисляется сеансовый ключ.
Данные расшифровываются полученным сеансовым ключом.

В случае использования алгоритма DHE/ECDHE и обладая секретным ключом сервера, расшифровать данные SSL/TLS трафика уже не получится.
В момент установки соединения передаются только открытые значения DH-ключей.
Секретные DH-ключи, необходимые для вычисления сеансовых, находятся в оперативной памяти клиента и сервера и после завершения соединения уничтожаются.
Эфемерные алгоритмы согласования ключей Диффи-Хеллмана (DHE/ECDHE) поддерживают Perfect Forward Secrecy (PFS).


Есть конечно другой, альтернативный вариант.
Подходит для расшифровки SSL/TLS-трафика без секретного ключа сервера, а также если используются алгоритмы DHE/ECDHE, RSA и другие.
В момент установки SSL/TLS-соединения в оперативной памяти клиента и сервера присутствуют открытые значения секретов, предварительного и главного.
Если успеть вытащить секреты из памяти и сохранить на диск, то в дальнейшем их также можно использовать для расшифровки данных.
Конечно, это не всегда просто сделать и не позволяет расшифровать трафик, перехваченный когда-либо ранее.

Похожие:

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

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

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

Представьте, что вы устройство, которое принимает инструкции. К вам может подключиться каждый желающий и отдать любую команду. Всё хорошо, но на каком-то iconЧто такое спид?
Вич до развития спида может пройти от 2—3 до 10—15 и более лет. Пока это не произошло, человек может не подозревать о том, что инфицирован,...

Представьте, что вы устройство, которое принимает инструкции. К вам может подключиться каждый желающий и отдать любую команду. Всё хорошо, но на каком-то iconТема: «Нормы речевого развития»
Каждый родитель мечтает и стремится к тому, что­бы его ребенок вырос гармонично развитым — был крепким и здоровым, умным, хорошо...

Представьте, что вы устройство, которое принимает инструкции. К вам может подключиться каждый желающий и отдать любую команду. Всё хорошо, но на каком-то iconИнструкция: «Предположим, что после соответствующего обучения Вы...
Инструкция: «Предположим, что после соответствующего обучения Вы сможете выполнять любую работу. Но если бы Вам пришлось выбирать...

Представьте, что вы устройство, которое принимает инструкции. К вам может подключиться каждый желающий и отдать любую команду. Всё хорошо, но на каком-то iconПодробная инструкция по работе с SonyEricsson K750 cid 49 Содержание
...

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

Представьте, что вы устройство, которое принимает инструкции. К вам может подключиться каждый желающий и отдать любую команду. Всё хорошо, но на каком-то iconЕсли на этой странице, в каком-то пункте написано обязательно
Если на этой странице, в каком-то пункте написано «обязательно», то не выполнение пункта может повлечь за собой 2-ух дневное общение...

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

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

Представьте, что вы устройство, которое принимает инструкции. К вам может подключиться каждый желающий и отдать любую команду. Всё хорошо, но на каком-то iconИнструкция по эксплуатации браслетов противоскольжения " 4wd " Несоблюдение...
Мы снимаем с себя любую ответственность за ущерб, причиненный вследствие невыполнения настоящей инструкции

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

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

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

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


Руководство, инструкция по применению






При копировании материала укажите ссылку © 2018
контакты
rykovodstvo.ru
Поиск