Какая доза клиент безопасно отправляет secert на сервер перед началом зашифрованной передачи во время SSL-квитирования в HTTPS-соединении - PullRequest
0 голосов
/ 06 февраля 2020

Я недавно читаю главу о безопасном HTTP в книге HTTP The Definition Guide . В этой главе рассказывается о том, как создается зашифрованное соединение для HTTPS, и есть схема для рукопожатия SSL, как показано ниже enter image description here

Мой вопрос заключается в том, что клиент и сервер начинают отправку зашифрованное сообщение на шаге 4, но на шаге 3, как они безопасно отправляют секрет. Если кто-то перехватит секретный файл, он будет украден, потому что он не зашифрован.

1 Ответ

1 голос
/ 06 февраля 2020

Цитируемое вами описание в основном устарело . Он предназначен для первоначальной формы обмена ключами, созданной в раннем SSL (v2, затем v3) и перенесенной на некоторое время в TLS, называемой просто «обмен ключами RSA» или иногда выделяемой как «простой RSA» или «только RSA».

[секрет] будет украден, потому что он не зашифрован.

Это зашифровано с использованием открытого ключа сервера RSA c (из сертификата сервера) с использованием первого свободно опубликованного стандарта шифрования RSA, а именно v1 из PKCS1 (Publi c Key Cryptography Standard # 1) от тогдашней дочерней компании Labs, основанной изобретателями RSA. Самую свежую спецификацию смотрите в rfc5246 раздел 7.4.7.1 (здесь не дублируется, потому что это три страницы). Как описано там, за годы, прошедшие после выбора шифрования PKCS1v1.5, атаки на него были обнаружены и постепенно улучшались, снижая его безопасность и добавляя стимул для его замены (ниже).

Однако добавлен SSLv3 (еще в эпоху Билла Клинтона), а TLS сохранил и улучшил улучшенный метод обмена ключами с использованием Diff ie -Hellman в режиме "эфемерности" , сокращенно DHE, а затем математически продвинутый вариант Ellipti c -Curve Diff ie -Hellman, (любой из), который обеспечивает прямую секретность (иногда подчеркивается как совершенная прямая секретность ), в сочетании с аутентификацией RSA, DSA или ECDSA (подпись). В течение многих лет эксперты по безопасности советовали людям использовать эти улучшенные методы, и в основном их игнорировали, пока Сноуден не сообщил всему миру об операциях массового наблюдения; за последние 6 лет люди почти полностью перешли на обмен ключами на основе DHE, и самая последняя версия, TLS 1.3, опубликованная в 2018 году и в настоящее время реализованная в значительной части областей применения, но пока не в большинстве случаев, требует DHE и больше не поддерживает простой обмен ключами RSA. 1.3 также переставляет части протокола так, что ваше упрощенное описание не совсем корректно, хотя и дает тот же результат.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...