Что на клиенте создается свою пару ключей для https соединения?

Question

[Boris007]

Прочитал статьи про то, как работает криптография, но осталось пару вопросов
Как я понял, чтобы на сервере сделать доступным протокол https, нам нужно на него установить пару ключей, публичный и приватный
После мы можем уже использовать асимметричное шифрование в передаче данных
Но откуда у обычных пользователей появляется эта пара ключей?
Ведь, чтобы обмениваться по RSA нужно между друг другом обменяться публичными ключами

Между делом появляется еще сертификаты
Как я понял, при запросе на сервер, чтобы у нас заработало наше https соединения, нам нужно в первом запросе обратиться к доверенному домену, который выдает сертификаты, чтобы он сделал нам секретную подпись, тогда браузер начнет обрабатывать наши запросы по https

Но тут еще появился сессионный ключ о котором я узнал из стаковерфлоу и тут я совсем запутался

Если handshake проходит успешно они обмениваются публичными ключами и на их основе вычисляют сессионный ключ, который вычисляется как sessionKey=sharedKey(PubKeyClient, PrivKeyServer)==sharedKey(PubKeyServer, PrivKeyClient)

https://ru.stackoverflow.com/questions/734459/Где-...

Т.е. асимметричное шифрование может быть использовано только для личного использования, чтобы закодировать сообщения и файлы, если мы решим передавать их по http, то это будет безопасно
Но браузеры устроены так, что им нужен еще какой-то ключ или сертификат, чтобы они одобрили, что мы используем безопасную передачу данных и отобразили нам https?

И почему везде пишут, что SSL устарел и ненадежен, что нужно использовать TSL, хотя во всех примерах для подключения к удаленным ПК через консоль, все примеры через команду SSL

Comments

[Василий Банников]

И почему везде пишут, что SSL устарел и ненадежен, что нужно использовать TSL, хотя во всех примерах для подключения к удаленным ПК через консоль, все примеры через команду SSL

Потому что продукт называется "openssl", а протокол - TLS. На самом деле сейчас практически никто не использует SSL протокол.

[Boris007]

Василий Банников, т.е. TSL и SSL это то, что мы сами руками никогда не выберем это все заложено в системе, а команда ssl это вызов утилиты openssl?

[Василий Банников]

Boris007, лучше покажи пример этого гайда и я тогда скажу, что именно там вызывается)

[Boris007]

Василий Банников, немного ошибся, ссх )
https://losst.pro/kak-podklyuchitsya-po-ssh
А ssh это что на фоне ssl и tsl?

[Василий Банников]

Boris007, ssh - это вообще отдельная и самостоятельная технология, которая не имеет отношения к TLS

[Boris007]

Василий Банников, но мы по ней с помощью приватных и публичных ключей подключаемся же

[Василий Банников]

Boris007, и что?

Answer 1

[Saboteur]

Для того, чтобы создать https, на стороне сервера нужен сертификат.
Сертификат содержит внутри пару ключей (приватную, публичную), и некоторые другие поля, например доменное имя сайта для валидации.

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

Сервер получив зашифрованный пакет расшифровывает его приватным ключом и вот у нас есть tls (https) сессия, и уникальный секрет у браузера и у сервера.

Для каждой новой сессии этот секрет будет генерироваться заново.

Ну а доверие к сертификату идет, если ты сертификат покупаешь у доверенных центров сертификации, чьи сертификаты встроены в систему/браузер и периодически обновляются с новыми версиями браузеров.

Либо ты можешь руками установить сертификат в доверенные. Но самоподписанные нужно будет в каждую систему/браузер руками ставить.

Comments

[Boris007]

Спасибо!
Т.е. сертификат это не публичный ключ, а просто документ, который выдает некий сайт, но для чего тогда?
Что бы подтвердить подлинность публичного ключа, который так же находится в реестре сайта, который выдал этот сертификат?
Но при этом публичный и приватный ключ выдает та же организация, которая выдает нашему сайду сертификат?

[pumpkinm]

Boris007,
1. Владелец сайта генерирует случайную последовательность байт — закрытый(секретный) ключ. На основе секретного ключа с помощью неких необратимых математических преобразований получает открытый(публичный) ключ — тоже пока просто последовательность байт.
2. Владелец сайта отправляет открытый ключ на сертификацию в удостоверяющий центр.
3. Удостоверяющий центр добавляет к открытому ключу разного рода атрибуты: кто владелец, срок действия, для чего можно применять и т.д. и потом всё это подписывает своим ключом. Получается сертификат.

То есть сертификат = это открытый ключ с атрибутами, сверху подписанный удостоверяющим центром.

Saboteur,

Сертификат содержит внутри пару ключей (приватную, публичную), и некоторые другие поля, например доменное имя сайта для валидации.

Сертификат не содержит приватный ключ, только открытый/публичный.

[Saboteur]

pumpkinm,
Сертификат может содержать и приватный и публичный ключ. Для httpd/nginx/jetty и некоторых других серверов обычно указывается один сертификат, а не сертификат и ключ отдельными файлами.
А вот клиенту сертификат отправляется уже только с публичным ключом

[Saboteur]

Boris007, Ключи генерит владелец сертификата. И когда запрашивает создание сертификата прикладывает публичный ключ к заявке.
Регистратор (СФ) создает сертификат и добавляет туда и публичный ключ и другую информацию. Основные поля это Certificate Subject или CN, serial ID, сроки годности (когда выдано, когда экспайрится), кем выдано (CA), рутовый сертификат CA, публичный ключ и дополнительные поля, например Alternate DNS subject
Все это подписывается ключом CA, чтобы сертификат нельзя было подделать и возвращается назад.

[pumpkinm]

Saboteur, сетификат, содержащий приватный (он же закрытый, он же секретный) ключ — это сразу его компрометация. Если где-то секретный ключ упакован в один файл рядом с сертификатом, это не значит, что он содержится в сертификате. Сертификат — это подписанная поверх всего своего содержимого сущность, и если туда засунуть секретный ключ, то удалить его из сертификата не нарушив целостность подписи не получится.

[Saboteur]

Популярные форматы-контейнеры для хранения сертификата и ключа хранят все в одном файле.

Те же .p12 и .jks (уже устаревающий), где сертификат и приватный ключ хранятся в одном файле, и сервер их вычитывает из одного файла.
И не путайте это с тем сертификатом, который отправляет веб сервер.
Да даже в банальном PEM файле они лежат рядом, а не отдельными разными файлами. Множество ембеддед серверов так делает - указывается путь к .p12 файлу и имя алиаса для сертификата, который нужно использовать для https или авторизации или two-way-ssl

[pumpkinm]

Saboteur, Так это внешний контейнер содержит и приватный ключ, и сертфикат, а не сертификат содержит внутри приватный ключ. И тип контейнера не имеет значения, да хоть zip-архив. Сертификат отдельно, приватный ключ отдельно.

И не путайте это с тем сертификатом, который отправляет веб сервер.

Сертификат не бывает тот или не тот. Сертификат один — подписанный удостоверяющим центром открытый ключ с атрибутами (или полями как вы говорите).

Сертификат содержит внутри пару ключей (приватную, публичную)

Сертификат ни при каких условиях не может содержать внутри приватный ключ.

Answer 2

[mayton2019]

Когда ты купил (устнановил себе ОС) в ней уже был браузер и в этом браузере прописаны центры сертификации. Это что-то вроде нотариальных контор. Ты им доверяешь по умолчанию. И они по цепочке являются гарантами сертификатов других доменов или других контор. И связка сет доменов + публичный ключ являются реквизитами сертификата. Ты их можешь увидеть в настройках безопасности браузера. И по протоколам TLS/SSL когда ты заходишь на сайт происходит быстрая проверка что интернет домен подтвержден и между вами устанавливается доверительный канал по которому вся инфа от сервера - прогарантирована. Но еще пока не скрыта. Но ввиду того что ассиметричка работает медленно и дорого, на самом деле эта процедура обрамляет другой протокол - создание симметричного канала с временным сеансовым ключом где дальше ты уже работаешь по обычному быстрому симметричному AES например до следующего сеанса обновления ключа. Этот канал уже скрытый от постороеннего наблюдателя. Если запускать openssl с некоторыми
параметрами то эта процедура рукопожатия будет трассироваться на экран и можно подсмотреть что реально
происходит у тебя на локалхосте.

По поводу что там и где устарело. SSL/TLS это просто версии алгоритмов вот этого рукопожатия.

Comments

[Boris007]

Т.е. ассиметричное шифрование происходит только при первом запросе, а дальше мы получаем сессионный ключ и последующие запросы работают по принципу симметричного шифрования?

Так все-таки при первом запросе, у нас должны быть приватный и публичный ключ или как безопасно получают сессионный ключ?

[mayton2019]

Boris007, да. Получают и периодически обновляют.

[Boris007]

mayton2019, откуда клиент берет свои публичный и приватный ключи?
Их создает браузер или система?

Сессионный ключ нам доверенный сервер сертификации отдает для клиента и сервера?

[pumpkinm]

Boris007, Если очень-очень грубо, то клиент запрашивает и получает от сервера его сертификат, проверяет его по цепочке на валидность и принадлежность именно этому серверу. Потом генерит случайную последовательность, шифрует её на этом сертификате и отправляет серверу. Расшифровать эту случайную последовательность может только сервер своим секретным ключом, парным сертификату. Вот мы и получили некий "ключ", который знает только сервер и клиент.
В реальности рукопожатие устроено сложнее, и этим далеко не ограничивается, плюс в разных версиях алгоритм/шаги различаются.

[pumpkinm]

Boris007, https://www.cloudflare.com/ru-ru/learning/ssl/what...

[Boris007]

pumpkinm, т.е. сертификат является публичным ключом сервера, а браузер генерирует на его основе наш ключ сессии и отправляет на сервер. На этом ассиметричный этап зашифрованного общения заканчивается и начинается симметричный путем сессионного ключа, верно?

[pumpkinm]

Boris007,

а браузер генерирует на его основе наш ключ сессии и отправляет на сервер.

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

На этом ассиметричный этап зашифрованного общения заканчивается и начинается симметричный путем сессионного ключа, верно?

Ну, в общем да. На самом деле они там потом еще туда-сюда обмениваются, но база в этом. Почитай по ссылке, там подробно по всем версиям расписано.

[Boris007]

pumpkinm, спасибо!
А сессионный ключ создает браузер или кто?

[pumpkinm]

Boris007, сессионный ключ создается из нескольких частей, но основную секретную его часть генерит клиент. У сервера нет возможности передать секрет клиенту не скомпрометировав его, а у клиента такая возможность есть благодаря сертификату сервера.

[Boris007]

pumpkinm, спасибо!