Как работает HTTPS?
Вставка
- Опубліковано 9 кві 2020
- В данном видео я попытался описать основные принципы работы протокола HTTPS.
Всё сказанное я попытался обосновать на этом документе:
tools.ietf.org/html/rfc5246#s...
Если вы заметили неточность и знаете, где именно в документации указано другое, пишите.
«Все как один ответили разные вещи» :)
Никогда такого не было и вот опять
Евгений, Шикарное объяснение! Продолжайте!
Спасибо за отзыв!
1. Почему данные шифруются симметричным ключом?
- Шифрование и расшифровка данных ассиметричным алгоритмом более дорогая операция. Поэтому обычно данные всегда шифруются симметричным ключом, что является более дешевой операцией, а уже сам симметричный ключ шифруется ассиметричным публичным ключом адресата. Таким образом при зашифрованном обмене информацией передаются данные, зашифрованные симметричным ключом, и сам симметричный ключ, зашифрованный публичным ассиметричным ключом адрессата.
2. Сертификационному центру следует предоставить публичный и приватный ключ?
- Сертификационный центр выдает сертификат на публичный ключ при предоставлении личных данных владельца ресурса. Разные сертификационные центры требуют различную личную информацию владельца ресурса. Приватный ключ сертификационному серверу не предоставляется. Задача, которую сертификационный центр решает, заключается в установлении взаимно однозначного соответствия между владельцем ресурса и публичным ключом. Алгоритмическая корректность сформированной ассиметричной пары ключей сертификационным центром не верифицируется.
1. Вроде бы, тоже самое я и сказал.
2. А вот по этому пункту, есть ли ссылка на документацию?
Спасибо за комментарий
@@EugeneSuleimanov Документацию сходу не предоставлю. Где-то здесь вроде: tools.ietf.org/html/rfc5280.
Вики: en.wikipedia.org/wiki/Public_key_certificate.
"Certificate, is an electronic document used to prove the ownership of a public key".
То есть сертификат подтверждает принадлежность владельцу открытого ключа.
Кроме того, об этом, кажется, было сказано во втором томе Хорстмана.
@@ttampuom да, на вики видел, но, также видел статьи, где упоминается и другое. Прочитаю доку еще раз о CSR, спасибо.
@@EugeneSuleimanov Вам спасибо, классный канал
@@EugeneSuleimanov думаю Владимир прав - приватный ключ центру сертификации не предоставляется, иначе вся приватность теряется. Согласно tools.ietf.org/html/rfc2986 - "A certification request consists of a distinguished name, a public key, and optionally a set of attributes, collectively signed by the entity requesting certification"
Спасибо за видео! За что нравятся ваши ролики, что очень короткие и крайне по существу. Иногда ощущение, что сижу рядом с коллегой и он на пальцах объясняет что как))) Класс и респект!
Евгений, спасибо за понятное описание! Получилось здорово! Ждем новых видео!)
Очень классно и понятно объяснил, спасибо) Побольше бы таких видео!
Лучшее объясние во всём рунете!
Теперь это мой любимый канал. Все видео смотрю)
Спасибо тебе, мил человек! Всё понятно на бытовом уровне!
Я не мог разобраться с этими ключами кто кому передает в каком порядке, Евгений все разложил по полочкам, спасибо большое за объяснение
Спасибо за отзыв!
Спасибо. Очень хотелось бы ещё про Сокеты послушать)
Супер! Очень-очень-очень полезно и интересно!!!Спасибо!
Спасибо за отзыв!
Респект за пытливость и за видео про https🤙🏻
Спасибо!
Действительно наглядно и понятно :)
Спасибо большое, что разжевал! Спасибо за предметные комментарии.
Огонь видос, редко оставляю комментарии, но тут другой случай. Очень понятно обьяснил!
Большое спасибо за отзыв!
Спасибо! За час поиска первое нормальное объяснение.
Спасибо за комментарий!
Ничего не понятно, но очень интересно!
Спасибо за видео)
Доступно для 1-го понимания. Спасибо
Оч круто! Спасибо Евгений)
Спасибо за отзыв :)
Спасибо за ваш труд
Спасибо! Все очень понятно объяснил.
Очень хорошее объяснение, спасибо!
Спасибо за отзыв!
спасибо большое за такой подробный разбор
Спасибо за отзыв!
Хорошее видео, спасибо за труд)
Очень хорошее объяснение, спасибо!)
Спасибо за отзыв, Никита!
Очень годный контент. Спасибо за видео.
Спасибо!
Спасибо, детально и понятно :))
Прекрасное видео!
Спасибо за видо, все было разложено поняьным человеческим языком
Спасибо за отзыв!
Отличное видео! Теперь, когда браузер ругается на ключи, я понимаю, что происходит))
Класс! Теперь всё понятно
Спасибо за комментарий!
Спасибо, очень круто!
доступное объяснение, спасибо
Спасибо!
Спасибо! Просто и понятно!
Все ничтяк! Good!
ну это самое крутое видео ведь, даже англоязычные источники не имеют аналогов
Отличное видео! Спасибо)
Спасибо за отзыв!
Спасибо вам за помощь
Обращайтесь
Очень полезно, спасибо.
Спасибо за отзыв!
Спасибо большое Вам очень понятно
Спасибо за отзыв!
Супер. Спасибо)
Евгений, очень полезный материал, спасибо за старания! Подскажите, а каким образом шифруется трафик между самим сервером и CA? HTTPS с использованием другого, более авторитетного CA?) Немного впал в ступор
Спасибо за отзыв! Насколько я знаю через тот же HTTPS. Но, честно говоря, не углублялся в данный вопрос. Попробую найти информацию.
хорошее объяснение
Спасибо за отзыв!
Большой респект за создание видеороликов. Нынче действительно полезных видеороликов минимум. Как начинающему QA Python что бы могли посоветовать?
Спасибо за отзыв! QA Python - не моя специализация, вряд ли смогу подсказать что-то стоящее, к сожалению.
Очень понятно, хоть и с третьего раза. Спасибо. Но вопросы все равно остались. Где локально хранятся сертификаты нужные для работы SSL? И насколько они защищены.
Спасибо!
Спасибо) вот это я понимаю объяснение) а у вас не планируется туториала в похожем ключе по многопоточности в java ?
Спасибо за отзыв! Я подумаю, получится ли в подобном формате о многопоточности.
Как всегда отлично ! А не могли бы вы сделать урок по слоям приложения - как разбивать приложение на слои и какие потерны при этом использовать . Спасибо
Спасибо, Павел! Я подумаю, что можно сделать полезного в этом плане.
Вот это годно
Очень интересно, суть работы понятна!
Теперь назрел вопрос: Есть ли тёмная сторона всего этого?
Получается всеми нашими данными теперь свободно владеет этот центр сертификации (даже если он надёжный)? И у кого с этой стороны появляется физический доступ ко всему этому?
автор видео скорее всего ошибся, приватные ключи центрам сертификации не перелаются.
всё понял.Спасибо
Много, где шифрование с открытым ключом применяется) Вроде как в чатах типа WhatsApp, в Telegram тоже на основе этого сделано шифрование, но там вроде как модифицирован алгоритм этого шифрования.
Как именно браузер проверяет сертификат через CA? В чем проблема это соединение перехватить как обычный HTTP?
Добрый день, Евгений. Спасибо за видео, но хотел бы уточнить один момент. Начиная с 6:38 (начала пошагового описания работы HTTPS), я начал расписывать на бумаге ход за ходом и в итоге получил, что публичный и приватный ключи клиента вообще нигде не участвуют, раз общение между клиентом и сайтом происходит только по ключу-сессии, к которому не имеет отношение ни приватный, ни публичные ключи клиента. Зачем же тогда нужны эти ключи? Или я где-то что-то упустил?
В итоге имеем:
Клиент с ПРиватным Ключом Клиента (ПРКК) и ПУбличный Ключом Клиента (ПУКК).
Сайт с ПРиватным Ключом Сайта (ПРКС) и ПУбличный Ключом Сайта (ПУКС).
Центр Сертификации с ПРиватным Ключом Центра (ПРКЦ) и ПУбличный Ключом Центра (ПУКЦ).
Получился такой набор ходов
1. Сайт предоставляет Центру Сертификации свой сертификат, сгенеренный на основе своих же ПРКС и ПУКС.
2. Центр сертификации подписывает сертификат своим ПУКЦ.
3. Клиент обращается к сайту.
4. Клиент получает от сайта сертификат.
5. Клиент обращается к Центру Сертификации по ПУКЦ, где его сравнивают с ПРКЦ.
6. Центру Сертификации подтверждает подлинность сертификата.
7. Клиент, с помощью ПУКС, шифрует ключ-сессию, и отправляет его сайту.
8. Сайт расшифровывает ключ-сессию с помощью своего ПРКС.
9. В итоге и Сайт, и Клиент имеют у себя уникальный ключ-сессию, который будет использоваться при обемене данными.
На каком шаге (или между какими шагами) тут появляется ПРКК и/или ПУКК?
Паблик и приват ключи клиента никак не участвуют. Сервер не проверяет с кем он общается, ему этого ненадо. Это нужно лишь браузеру
Ага, public и private клиента никак не участвуют, если только сам клиент в каких-то случаях не может выступать в качестве сервера
Зачем центру сертификации передавать на подпись так же и секретный ключ, если он потом никуда не передается? Разве не достаточно просто подписать публичный ключ?
Certificate Revocation List можно про него немного рассказать.
браузер обращаться в центр сертификации тоже по https? если да то у кого он сверяет пуб. ключ сертеф ценрта? если нет то там незащищенное http соед?
спасибо! помогло
Вы сказали, что сервер для использования https должен сгенерировать пары публичного и приватного ключей и отослать их в некий центр сертификации. Так вот, как он отсылает эти данные? Он их шифрует публичным ключом центра сертификации или как?
приватным ключом шифрует запрос и отправляет CA запрос + публичный ключ, приватный оставляет у себя
CA расшифровывает открытым ключом запрос, провееряет его и выдает обратно сертификат
На 8:23 написано, что приватный ключ совпадает с публичным ключом и значит все хорошо, хотя немного раньше говорилось о том, что от сайта браузер получил только публичный ключ. Так что с чем сравнивается, публичный с приватным или публичный с публичным?
Евгений ,спасибо . Сделайте пожалуйста видео про REST
Спасибо за отзыв! Вы имеете в виду описание самого подхода?
@@EugeneSuleimanov да, тоже интересно. Описание подхода, а так же популярные вопросы, почему нужны put, delete(кроме того что так рекомендуется), а не просто использовать всегда post. Мне кажется это будет интересно
@@EugeneSuleimanov Да
@@EugeneSuleimanov soap и rest? в чём различия?)
Здравствуйте. Подскажите пожалуйста. https - шифрует трафик, что это означает? Если я напр.смотрю фильм онлайн в яндекс-видео - будет ли видно третьей стороне - какой фильм? Или запросы в гугле? Или то что я смотрю на сайте аптеки?
Обычно, демонстрация видео идёт не по протоколу http. Чаще всего RTMP, HLS и т.д. Поэтому здесь https не применим. Сами запросы, т.е. ресурсы, которые вы просматриваете - могут быть перехвачены, а вот данные которые идут в теле запросов, обычно, нет.
супер
Спасибо за отзыв!
@Eugene Suleimanov А как происходит обмен public ключами при асимметричном шифровании?
При рукопожатии
👊
Не подскажете, шифруется только тело передаваемого запроса, а HTTP заголовки остаются незащищенными?
Шифруется весь слой http.
Все кроме хоста и порта
А можно вопрос, возможно глупый? Если на стороне клиента секретный ключ шифруется на основе публичного ключа сервера, и по сути расшифровать его возможно имея доступ к этому публичному ключу, а этот серверный ключ, подписанный в CA, один же, то если второй клиент сделает запрос к тому же серверу и также получит доступ к его публичному ключу, то на его основе он сможет расшифровать секретный ключ первого клиента? Или они на каждый handshake для разных клиентов по разному генерятся и не подойдут соответственно друг другу?
Нет, не получится. Ключ сессии сможет расшифровать только сервер. И этот ключ валиден только для 1 клиента
Посмотри алгоритм Диффи-Хеллмана(там где с краской объяснение и поймешь все) ua-cam.com/video/vFjq9pID4-E/v-deo.html
Спасибо!)
Я только одного момента не понял: а если перехватят данные с секретным ключом браузера разве его нельзя расшифровать с помощью публичного ключа сервера - злоумышленник же его тоже может получить.
Дело в том, что данные зашифрованные ОТКРЫТЫМ ключом, можно расшифровать лишь - ПРИВАТНЫМ КЛЮЧОМ. и никак иначе, а приватный ключ - есть только на сервере (и он никуда не передается)
хорошо бы если ты показал различия на практике со стороны злоумышленика, что он видит
Содержание отличное, но вот звук немного раздражает, хочется получше качество слышать
Если я правильно понял, то принцип работы по https похож с принципом подключения к машине по ssh с помощью приватных и публичных ключей.
konstantin viktorovich да, только отсутствует session key
Как можно шифровать одним ключом, а расшифровывать другим?
Алгоритм шифрования RSA в действии! Советую почитать вам о нем. Функция Эйлера, простые числа...)
Что мешает использовать http но шифровать все данные публичным ключем и на сервере расшифрововать приватным, откуда мы знаем что https безопасный, откуда гарантии, что мешает на уровне lets encrypt не перехватить данные или что б какая нибудь служба безопасности государства не перехватила, как то мутно все равно
а что значит "подписал" сертификат? добавил туда какой-то текст внизу?
Да. Добавляется к сертификату hash - например DFE5557. Это и есть подпись или сигнатура как её называют.
@@funtikos , не просто добавить hash, но еще и зашифровать эту hash своим приватным ключом. В этом случае на проверяющей стороне смогут расшифровать электронную подпись на вашем открытом ключе и сравнить результат с hash от части "подписываемой" сообщения (например, сертификата).
ОТПРАВИТЬ центру сертификации PRIVATE KEY ??? что за бред
согласен. не эксперт в этой области, но нигде больше не слышал кроме этого видео, что бы приватные ключи кому-то отправлялись.
Cм. обсуждение в комментарии выше. Автор ошибся.
Пропущены важные ньюансы : 1) Как определенный SSL сертификат устанавливается в Browser для общения с определенным сайтом; 2) Как указывать сертификат, симулируя request с помощью Postman ?
Нехороший человек..... Не хороший человек, а плохой
А так в целом все отлично👍
Ssl и TLS это одно и тоже, в каком-то лохматом 95 году было решено, его переименовать так как SSL была абривиатура другой компанией.
8:54 вот тот момент который я не понял. Вот мой(браузер) ключ1, который я зашифровал твоим ключом2. Но где гарантия что злоумыш тоже не имеет этот ключ2, ведь браузер его получил как-то??? Я не могу понять, как это технология исключает утечку?
Дело в том что ключом2 (публичным ключом сервера) можно только зашифровать данные, а расшифровать можно только приватным ключом сервера(который хранится исключительно у сервера) а после того как сервер безопасно получит ключ сессии или симметричный ключ все остальные данные будут шифроваться симметричным ключом
Спасибо! Но над звуком надо поработать, он ужасен)
Спасибо за отзыв! А что не так со звуком? Уже и внешняя звуковая и микрофон и даже фильтр взял для него ))
@@EugeneSuleimanov видимо еще поднастроить надо все это дело) по ощущениям слишком задраны низкие частоты, из-за чего слышен неприятный "гул"
@@SplashDmg2011 проверю, спасибо
лукасик вам от СЕООНЛИ
ua-cam.com/play/PLxGo9dxQkqWAOEUOMOo9Da0l-8qKndNTP.html
Хороший плейлист, для понимания основ криптографии. И понимание как работают приватный и публиснве ключи
Большое спасибо за рекомендацию, обязательно просмотрю.
куда пропали видео собеседований?(
Не каждый же день - быстро надоест :)
На днях точно будет следующее. Уже записано - "кандидат" - junior java разработчик в крупной компании.
@@EugeneSuleimanov я в том плане, что не успел посмотреть последнее, а его удалили(
@@andriimelnyk7129 какое именно? Не было такого. Все 3 видео на месте в плейлисте
@@andriimelnyk7129 оставляю ссылку:
ua-cam.com/video/XZIwI_bdNKU/v-deo.html
@@EugeneSuleimanov пора завязывать с файберами) второе видео в списке не увидел) спасибо!
Спасибо! Вот ещё видео 👇🏻
ua-cam.com/video/GuCOkuN70VA/v-deo.html
Всегда хотя бы поработай с технологией))
Центр сертификации: "Я подписал их с помощью своего ПРИВАТНОГО КЛЮЧА. Любой у кого есть мой ПУБЛИЧНЫЙ КЛЮЧ (например браузер), может проверить что это именно я подписал его."
Вопросы:
1. Как именно клиент это проверяет?
2. Какой смысл клиенту это проверять? Ну подписал центр сертификации этот сертификат, и что из этого? Как клиент понимает что публичный ключ который передал ему сервер, можно использовать? Как он, обращаясь в центр сертификации, понимает, что получил правильный публичный ключ, а не ключ мошенника?
Клиент сравнивает с центром сертификации надежный ли узел. Если ЦС говорит что узел надежный, клиент продолжает с ним работу и шифрует данные при помощи ключ-сессии. Эту сессию может расшифровать только сервер и клиент.
Таким образом клиент может доверять серверу, и они обмениваются шифрованными данными, которые недоступны злоумышленникам (для всех остальных ведь это просто крокозябры, у них нет приватного ключа для расшифровки)
Центр сертификации подтверждает, что этот открытый ключ принадлежит этому серверу с таким-то и таким-то доменом. То есть что это не открытый ключ злоумышленника, который потом прочтёт ваши секретные данные, например банковской карты.
Сказки для джуниоров)))
Так сложно для понимания..Лучше бы какой-нибудь мультик нарисовать..
Визуально понять проще..
Жил-был протокол...
не понимаю зачем снимать ролики по темам которые давно уже более подробно описаны в интернете
В самом начале ролика ответил на этот вопрос
@@EugeneSuleimanov вначале пропустил немного, теперь я понял) спасибо
про SSL уже лет десять как стоит забыть и не вспоминать
Спасибо!