А почему нельзя передать симетричный ключ серверу с помощью шифрования публичным ключём сервера ? Почему это должно происходить именно через https ? Как я понимаю, сервер передаёт клиенту свой сертификат, клиент его проверяет и после шифрует все сообщения к серверу публичным ключём сервера который был в сертификате. После этого у сервера и у клиента есть симетричный ключ и оба могут шифровать им сообщения через http ? Где я ошибаюсь ?
> почему нельзя передать симетричный ключ серверу с помощью шифрования публичным ключём сервера ? Для упрощения можно считать что как-бы так и происходит. На самом деле все чуть сложнее, см. ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D1%82%D0%BE%D0%BA%D0%BE%D0%BB_%D0%94%D0%B8%D1%84%D1%84%D0%B8_%E2%80%94_%D0%A5%D0%B5%D0%BB%D0%BB%D0%BC%D0%B0%D0%BD%D0%B0 > после шифрует все сообщения к серверу публичным ключём сервера который был в сертификате Нет, все сообщения шифруются симметричным сеансовым ключем, который согласуется при помощи алгоритма Диффи-Хеллмана
Почему хотя доверились самоподписанному сертификату соединение не стало безопасным , т.е. https не позеленело, а осталось также с перечеркнутой красной чертой?
Потому что зеленое только то, что защищенно доверенным сертификатом. Остальное - красное ;) и насколько я понимаю самоподписанные не могут стать доверенными, даже если их руками явно попытаться добавить в хранилище.
Столкнулась давече с созданием сертификата для клиентской авторизации -pkcs12. Там среди прочих данных, передаваемых клиенту, стоит приватный ключ сервера... я решительно в замешательстве.
как браузер понимает каким сертификатом проверять подлинность сертификата с ключём от сервера? откуда в браузер попадают сертификаты соответствующих центров?
@@DmitryKetov почему для translate.yandex.ru центр "Yandex CA", но его нет в настройках браузера в разделе "Certificate authorities"? почему на ya.ru и yandex.ru в инфе о сертификате в "Issued To" напротив "Common Name (CM)" указано *.xn--d1acpjx3f.xn--p1ai (что вообще похоже на кодирование кириллицы)?
@@JaroslavNesterov 1. Потому что Yandex CA есть подчиненный CA и его сертификат проверяется вышестоящим Certum Trusted Network CA (Unizeto Technologies S.A.) 2. Потому что а) xn--d1acpjx3f.xn--p1ai = яндекс.рф, см. ru.wikipedia.org/wiki/Punycode b) Issued To не единственное поле сертификата, которое указывает его владельца - см. расширения сертификата, поле en.wikipedia.org/wiki/Subject_Alternative_Name
since 7 years still pound for pound
Хороший преподаватель.
Отличное видео. Большое вам спасибо)
Просто о сложном, спасибо! Ну и напоминаю, не нужно нажимать на эту клавишу!!
А почему нельзя передать симетричный ключ серверу с помощью шифрования публичным ключём сервера ? Почему это должно происходить именно через https ? Как я понимаю, сервер передаёт клиенту свой сертификат, клиент его проверяет и после шифрует все сообщения к серверу публичным ключём сервера который был в сертификате. После этого у сервера и у клиента есть симетричный ключ и оба могут шифровать им сообщения через http ? Где я ошибаюсь ?
> почему нельзя передать симетричный ключ серверу с помощью шифрования публичным ключём сервера ?
Для упрощения можно считать что как-бы так и происходит. На самом деле все чуть сложнее, см.
ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D1%82%D0%BE%D0%BA%D0%BE%D0%BB_%D0%94%D0%B8%D1%84%D1%84%D0%B8_%E2%80%94_%D0%A5%D0%B5%D0%BB%D0%BB%D0%BC%D0%B0%D0%BD%D0%B0
> после шифрует все сообщения к серверу публичным ключём сервера который был в сертификате
Нет, все сообщения шифруются симметричным сеансовым ключем, который согласуется при помощи алгоритма Диффи-Хеллмана
Когда ctrl+w закрывает страницу, это конечно боль. Хорошо, что в Опере можно это отключить.
Почему хотя доверились самоподписанному сертификату соединение не стало безопасным , т.е. https не позеленело, а осталось также с перечеркнутой красной чертой?
Потому что зеленое только то, что защищенно доверенным сертификатом. Остальное - красное ;) и насколько я понимаю самоподписанные не могут стать доверенными, даже если их руками явно попытаться добавить в хранилище.
Столкнулась давече с созданием сертификата для клиентской авторизации -pkcs12. Там среди прочих данных, передаваемых клиенту, стоит приватный ключ сервера... я решительно в замешательстве.
Хммм. Хорошо бы пример....
как браузер понимает каким сертификатом проверять подлинность сертификата с ключём от сервера?
откуда в браузер попадают сертификаты соответствующих центров?
1. уникальный идентификатор CA т. н. issuer name содержится в сервером сертификате
2. предустановлены в ОС её производителем
@@DmitryKetov почему для translate.yandex.ru центр "Yandex CA", но его нет в настройках браузера в разделе "Certificate authorities"?
почему на ya.ru и yandex.ru в инфе о сертификате в "Issued To" напротив "Common Name (CM)" указано *.xn--d1acpjx3f.xn--p1ai (что вообще похоже на кодирование кириллицы)?
для справки, использую Yandex.Browser
@@JaroslavNesterov 1. Потому что Yandex CA есть подчиненный CA и его сертификат проверяется вышестоящим Certum Trusted Network CA (Unizeto Technologies S.A.)
2. Потому что а) xn--d1acpjx3f.xn--p1ai = яндекс.рф, см. ru.wikipedia.org/wiki/Punycode
b) Issued To не единственное поле сертификата, которое указывает его владельца - см. расширения сертификата, поле en.wikipedia.org/wiki/Subject_Alternative_Name