Я в шоке, на 17 минут видео информации подано больше чем у других в часовых роликах. Очень хорошая подача информации, все по полочкам, без раздражающих моментов. Даже произношение английских названий корректное! Спасибо вам за такой контент!
Андрей, спасибо! Посмотрите на всех этих людей, которые вам искренне благодарны! Это указывает на то, что вы вложились от души. Ещё раз спасибо, это действительно золотая находка среди остального контента
согласен☝🏼 слу, у тебя в загашнике есть что-нить в таком же толковом стиле про линукс? даже несколько часовых видосов подошли бы. с краткой историей и базовым администрирование линуха. мне надо освежиться в этом плане.
Здравствуйте! Подтверждаю все комметарии о понятности и полезности вашего видео!)) Я в восторге, что нашла его! Спасибо большое за качественный материал в доступном формате!
Случайно наткнулся на канал, и весьма удивлен качеству, как контента так и подачи. Покупал курсы по этой теме на Udemy, у английских авторов. Ваш контент намного проще усваивается. Спасибо!
Вот такие преподаватели должны работать в Российских вузах. А не старые замшелые, извините за слово, но пердуны. Для себя, я безусловно ничего нового не открыл. Но подписался исключительно ради поддержки канала Господина Созыкина. Чтобы канал продвинулся в топы youtuba. Ещё раз, отличная подача материала. Научить других, тому что знаешь сам это тоже талант.
Простое и понятное объяснение... Ещё пару контрольных вопросов для закрепления материала, чтобы слушатели не кисли, а проявляли активность в ответных комментариях. И аудитории полезно, и канал оживёт.
Я вот в марте ходил на собеседование в одну компанию и там мне задали несколько каверзных вопросов про TLS/SLL после которых мне пришлось краснеть)) Эххх.. Если бы Вы выпустили свои уроки немного раньше))) Но всё равно, спасибо за урок - очень интересно!!
@@AndreySozykin Спасибо!!) После ваших видео уж точно не последнее! Вы очень интересно подаёте материал, а самое главное, именно после Ваших видео очень легко читать книги и статьи по затронутым темам, так как уже сформирован некий базис. Ну, а компания была немного всё таки по выше уровнем, чем я, просто случайно получилось попасть на собеседование, и если бы не этим вопросом, то каким-либо другим уж точно поставили бы меня в тупик) Зато есть к чему стремится!)
Андрей, Вы написали тут важную вещь, что при регистрации сертификата у удост. центра "Сервер отправляет удостоверяющему центру запрос на создание сертификата и высылает свой открытый ключ." Ещё было сказано, что сертификаты выдаются на непродолжительное время ( 3 месяца например), понятно в каких целях. НО в вашем прошло видео было сравнение двух алгоритмов асс. шифрования RSA и Д-Х. Первый, да, - генерирует тот самый закрытый ключ и, соответственно, открытый один раз на продолжительное время, из-за чего подвержен неполной совершенной секретности и в связи с этим исключен из TSL 1.3. А второй, - генерирует наборы ключей: открытый (g, p значения) и закрытый каждый раз при установке нового соединения. Итак, вопрос. При использовании Д-Х в TSL 1.3, сертификат для каждого нового соединения содержит новый уникальный открытый ключ(g, p значения), и соответственно, такой сертификат переподписывается удост. центром снова и снова - или же это как-то работает по-другому?
Всё разобрался. The server (and the client, if they are authenticated) signs their Diffie-Hellman public key with the private key in the server certificate (which is usually RSA or ECDSA). The fact that both sides can negotiate a connection successfully and the Diffie-Hellman public key is signed proves authenticity of the connection. An attacker impersonating the server would be limited to reusing a previous signed DH public key sent by the server, but because it did not know the private key, it couldn't successfully negotiate a connection.
@@mrmaxepik всё равно ничего не понятно из текста: кто подписывает-то ключи/сертификаты. и что за "negotiate a connection"? обычно establish a connection. Просто накиданы общие слова без конкретики.
Здравствуйте, спасибо за урок!. Цитирую вас: "Например, если мы расшифровываем сообщение с помощью открытого ключа с сайта банка, то значит мы можем быть уверены, что получили это сообщение от банка". Но ведь сертификат банка является публичным и может быть скопирован злоумышленником. Что если злоумышленник скопирует себе этот сертификат, затем выступит в роли человека по середине? Тогда ведь клиент получит копию сертификата банка но от злоумышленника. Так как это копия сертификата, клиент сможет дешифровать подпись публичным ключом удостоверяющего центра и результат дешифровки будет совпадать с хешем от данных т.к злоумышленник не менял сертификат. В результате аутентификация будет пройдена, а по факту сообщение нам отправил злоумышленник, а не банк. Как клиент в таком случае поймет, что этот сертификат был получен от злоумышленника и перестанет передавать ему свои данные?
Отличный вопрос. При использовании RSA вроде понятно(клиент зашифрует семитричный ключ открытым ключем и только сервер его расшиврует своим закрытым). А вот при использовании алгоритма Диффи-Хеллмана(да еще и эфемерного)мне не понятно как сертификат спасет от mitm. Злоумышленник отдаст сертификат банка клиенту, клиент его проверит и радостный пойдет устанавливать соединене с злоумышленником по алгоритму Диффи-Хеллмана.
Здравствуйте Андрей! спасибо за очередную понятную лекцию, у меня вопрос. сервер создаёт 2 ключа открытый и закрытый, после он подаёт запрос в Удостоверяющий центр на сертификат этого ключа, в ответ он получает этот самый сертификат, и после он может слать его пользователям и те расшифровывая его понимают что этот ключ подлинный? как они это поняли? из-за того что подпись центра управления стоит? Так ведь получается Хакер может сделать свой сервер, запросить на него сертификат, а после тупо отправлять его пользователям, на нём ведь стоит подпись, след ключ в нём подлинный, я не особо понимаю как клиент понимает что ключ именно этого сервера? возможно вопрос глупый но всё же я действительно не понял. Второй вопрос. выходит все пользователи сервера, исп. один и тот же ключ? то есть расшифровать сообщения всех пользователей может лишь один ключ? А трак же вопрос. все хосты хоронят открытые ключи центра управления в памяти? иначе как они расшифровывают подписи сертификатов? если да то выходит что открытый ключ удостоверяющего центра тоже один на всех? Заранее благодарю за ответ. Ваши курсы действительно находка!!!
Не совсем понятно что если сообщение от сервера(касаемое сертификата), злоумышленник по середине, передаст без изменений, а в остальном трафике будет посредником?
Допустим, мы получили от сервера сертификат, выданный промежуточным CA. Далее нам нужно провалидировать сертификат этого CA, пока по цепочке не доберемся до корневого CA. Вопрос в том, откуда браузер получает этот промежуточный сертификат (в хранилище ведь только корневые сертификаты)? Сервер присылает всю цепочку сертификатов или браузер сам получает сертификат с сайта промежуточного CA? UPD: увидел, что в Chrome в настройках можно найти список сертификатов промежуточных центров. Тем не менее, вопрос, как они там появились, остается. UPD: ответ быстро нашелся security.stackexchange.com/questions/211749/where-do-tls-clients-fetch-intermediate-ca-certificates-from. Действительно, сервер присылает всю цепочку, кроме корневого сертификата в общем случае. Но браузер может кешировать промежуточные сертификаты.
Здравствуйте! Ответьте пожалуйста на вопрос. Так как в пиратской ОС может быть изменено хранилище сертификатов. Получается люди, которые скачивают пиратскую ОС подвержены "атаке человек посередине"?
То есть сервер шлет сертификат пользователю. Подпись это хеш(sha1 или варианты) самого сертификата, который зашифрован закрытым ключем сервера. Пользователь получает сертификат и расшифровывает подпись. Но как открытый ключ расшифровывает подпись, если этот ключ открытый и может только шифровать?
С помощью открытого ключа можно расшифровать то, что зашифровано закрытым ключом. И наоборот: если сообщение зашифровано открытым ключом, то его можно расшифровать закрытым ключом.
@@AndreySozykin Не понимаю, вы ранее говорили что открытый ключ только шифрует, а расшифровать может толь закрытый. Это же логика работы асинхронных методов шифрования
Ассиметричное шифрование означает, что один ключ используется для шифрования, а другой для расшифровки. При этом открытый и закрытый ключи могут использоваться для обеих целей: шифруем открытым - расшифровываем закрытым, шифруем закрытым - расшифровываем открытым.
@@AndreySozykin то есть, подпись которую ставит удостоверяющий центр, может расшифровывать открытый ключ, который содержится в сертификате удостоверяющего центра, который есть у нас в момент установки соединения
Огромное спасибо за лекцию! Но возник один вопрос, возможно глуповатый, но для полного понимания для себя я все таки его задам. Как я понял, электронную подпись имеет только сертификат, и используется только для установления защищенного соединения. То есть все остальные сообщения, которые пересылаются после установления соединения и генерации ключей, не подписываются, я правильно понимаю?
Все остальные сообщения используют MAC, а не электронную подпись. В MAC работает симметричное шифрование, которое гораздо быстрее, чем шифрование с открытым ключем. В TLS достаточно проверить подлинность сервера один раз, во время установки соединения. После этого подменить сервер почти не возможно, если используются сильные наборы шифров.
@@AndreySozykin Приветствую, Андрей, спасибо за видео. То есть в алгоритмах работы с цифровой подписью и с MAC отличия только в том, что в одном случае используются симметричные ключи, а в другом открытый/закрытый? При получении сообщения в обоих случаях происходит извлечение хешей(из подписи/мака с помощью ключа и из сообщения с помощью хеш-функции) и сравнение этих хешей? Спасибо.
Спасибо за видео! Такой вопрос: если открытый ключ корневого агенства прошивается в ОС, то предполагается, что он - бессрочный, а закрытый ключ принципиально не подвержен утечке? Или есть какой-то механизм обновления ключа?
Механизм обновления есть, для Windows описан здесь - support.microsoft.com/en-us/topic/support-for-urgent-trusted-root-updates-for-windows-root-certificate-program-in-windows-a4ac4d6c-7c62-3b6e-dfd2-377982bf3ea5 . Клиенты каждую неделю опрашивают сервер PKI, появились ли обновления сертификатов.
Я не понял почему удостоверяющий центр выдал вам в сертификате ваш открытый ключ? Ведь открытый и закрытый ключ должен создать ваш сервер. Откуда удостоверяющий центр взял ваш открытый ключ?
Да, вопрос доверия, важный. Например, сейчас активно рекомендуют устанавливать сертификаты Мин цифры и скоро многие официальные сайты не будут работать без них.
Здравствуйте Уважаемый Андрей, У меня вопрос такой: Есть веб сервер который работает сервер сертификат то есть https, сервер когда передает эти сертификаты к клиентам ,чтобы они смогли шифровать первоначальные данные (handshake) и когда клиенты шифровав данные этим сертификатом отправляет данные обратно серверу сервер как то проверяет действительно клиенты шифровали данные этим сертификатом то есть это тот сертификат ? или сервер private ключом просто проверят смог расшифровать данные от клиентов , если да то все ок Заранее благодарен !! буду рад если ответите )
Самим сертификатом нельзя ничего зашифровать или расшифровать. Для этого используется открытый ключ в сертификате. Сообщение, зашифрованное открытым ключом, можно расшифровать только закрытым ключом сервера. Поэтому если расшифровать не удалось, то ключ неправильный. С другой стороны, злоумышленник может перехватить открытый ключ сервера и зашифровать сообщение им. Это сделать просто, т.к. ключ открытый. Сервер будет способен расшифровать такое сообщение от злоумышленника. Чтобы обнаружить такую проблему как раз и используется сертификат. Сервер может проверить сертификат клиента и убедиться в его подлинности. И если сертификат не действительный, то сообщение не будет обработано, даже если оно зашифровано открытым ключом сервера. Но серверы не всегда проверяют подлинность клиента с помощью сертификата. Web-серверы не делают этого почти никогда.
Спасибо за отличные лекции! Хочу уточнить один момент: если с помощью открытого ключа можно расшифровать информацию, распространяемую закрытым ключём, разве это не ставит под угрозу приватность диалога клиента и сервера?
Обычно при информацию шифруют как раз при помощи открытого ключа. Расшифровать такую информацию может только обладатель закрытого ключа. Поэтому приватность диалога не страдает, если не будет получен доступ к закрытому ключу. Другой вариант, при котором данные шифруются закрытым ключом и расшифровываются открытым, применяется для электронной подписи. В этом случае каждый, у кого есть открытый ключ, может убедиться, что подписан обладает закрытым ключом, т.к. с помощью открытого ключа можно расшифровать только сообщение, зашифрованное закрытым ключом.
Интересно нельзя ли использовать систему блокчейндж для подписи сертификат? Как по моему маленькому представлению это гораздо надёжнее но пока не имею ни какого понятие как это осуществить детально
Андрей спасибо за уроки, очень благодарен за Ваш труд. Хотел спросить не собираетесь ли Вы в ближайшее время рассмотреть стек протоколов SS7 ? Заранее спасибо
@@AndreySozykin я вот чего не могу понять. вот есть RSA с парой ключей. Открытым шифруем, закрытым расшифровываем. Вопрос: а можно этим же закрытым зашифровать, а открытым расшифровать? Т.е. реализовать ЭЦП. Или для ЭЦП нужна отдельная пара ключей?
@@manOfPlanetEarthоно так и работает. сообщение хэшируется, хэш зашифровывается приватным ключем, передается клиенту. клиент получает сообщение + сертификат, расшифровывает сертификат открытым ключе, хэширует сообщение, сравнивает хэши. просто открытый ключ надо как-нибудь заранее передать, по флешке или через гитхаб
Почему я вообще должен доверять удостоверяющему центру? Что будет, если я зарегистрирую свой удостоверяющий центр, и буду иногда устраивать атаки человек посередине? Мне просто потом не будут доверять, если обнаружат это?
То есть в момент когда пользователь раз в несколько лет скачивает сертификат с корневого удостоверяющего центра все же можно осуществить MITM подмену ?
не ясно кто где подмешивает например имя сервера. ведь именно имя идентифицирует сервер. или у вас это раскрыто в лекции про фишинг наверно. но тут про подмешивание тоже надо было упомянуть хотя бы
Именно так. Нужно очень внимательно относится к удостоверяющим центрам, сертификаты которых установлены на ваше устройство. Вот, правительство Казахстана заставляло всех граждан доверять государственному удостоверяющему центру, чтобы можно было читать весь TLS трафик - m.habr.com/ru/post/272207/
@@AndreySozykin как правительство Казахстана может получить доступ к зашифрованному трафику жителей (например, на gmail)? Такая ли схема: при каждом запросе к gmail оно "встанет посередине", а свой прослушивающий сервер аутентифицирует для устройства пользователя, используя свой "карманный" CA?
При передаче ЭЦП, данные отдельно шифруются от хэша? Или просто передаются в открытом виде с подписью. Но тогда же при перехвате злоумышленник не сможет их изменить, но спокойно просмотрит. А если там тайная информация? Получается данные должны шифроваться по какому то алгоритму отдельно. По тому же RSA, используя те же ключи? Или дополнительно использует симметричное шифрование?
Да, элеатронная подпись и шифрование - это разные технологии. Электронная подпись нужна, чтобы документ нельзя было изменить. Шифрование - чтобы документ нельзы было прочитать. Конечно, шифрование и электронную подпись можно использовать совместно.
2:57 не правда! Это так не работает, сообщение может быть зашифрованно открытым ключ и расшифровано только закрытым!!! В ОБРАТНУЮ СТОРОНУ ЭТО НЕ РАБОТАЕТ!!
Работает, подтяни знания по криптографии… Можешь включить ролик про ассиметричное шифрование RSA, взять ручку и на небольших числах создать два ключа. Далее попробуй зашифровать текст закрытым и расшифровать открытым , и будет тебе чудо Когда мы генерируем два ключа, мы сами решаем какой из них private а какой public . При генерировании сервером, он сам также решает какой он делает private а каким можно делиться
Меня смутило это место! Кто в курсе проясните. Клиент не расшифровывает а сверяет сертификат с СА, так как доверять может только СА. А в этом месте клиент расшифровывает Сертификат от сервера. В этом месте обьясните пожалуйста! ruclips.net/video/6wCwjIhGylY/видео.html
Это всё конечно классно, но откуда такая уверенность, что закрытый 🔑 уже не в кармане злоумышленников, и они электронную подпись и подделывают, кстати длжеоа уже таких примеров по СМИ.. Ибо тот кто хочет взломать он знает как система работает и начнёт её с поиска именно закрытого ключа... Короче судя по алгоритмам шифрования выше, пока ничего надёжного нет... Посмотрим конечно на другими системы... Материал хорошо 👌 подан, кратко и содержательно 👍👏
Очень правильный вопрос! Слепо доверять не стоит. Нужно, как минимум, посмотреть, что установлено в хранилище сертификатов. Если сертификат вызывает подозрение, то его можно удалить из хранилища.
@@AndreySozykin Напросился логичный вопрос - как удалить? Я нашёл в списке сертификатов один, срок которого истёк в июле прошлого года. Но кнопка Remove неактивна. Только кнопки Import и Export рабочие.
![Seungmin "그렇게, 천천히, 우리(As we are)" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/kAzmhLHePqU/mqdefault.jpg)
Чтобы настолько понятно объяснить тему, нужен настоящий талант. Просто браво.
Спасибо!
Я в шоке, на 17 минут видео информации подано больше чем у других в часовых роликах. Очень хорошая подача информации, все по полочкам, без раздражающих моментов. Даже произношение английских названий корректное!
Спасибо вам за такой контент!
Пожалуйста! Рад, что формат курсов нравится!
Андрей, спасибо! Посмотрите на всех этих людей, которые вам искренне благодарны! Это указывает на то, что вы вложились от души. Ещё раз спасибо, это действительно золотая находка среди остального контента
Спасибо за приятный отзыв! Рад, что курсы нравятся!
согласен☝🏼
слу, у тебя в загашнике есть что-нить в таком же толковом стиле про линукс? даже несколько часовых видосов подошли бы. с краткой историей и базовым администрирование линуха. мне надо освежиться в этом плане.
@@AndreySozykin
Спасибо за выпуски!
По линуксу подкинете что-нибудь толковое? (см мой вопросик выше). Мне надо освежиться.
Постоянно обращаюсь к курсу по сетевым протоколам как к справочнику. Отличный баланс между академическим и популярным изложением.
Наконец-то разобрался с этим. Спасибо!
Пожалуйста!
Вот проходил курсы цыски (эти их Bob и Alice), книжки разные читал. Но в такой подаче знания ложатся как по маслу. Мое почтение! Гранд мерси за курс!
Хорошая подача материала, приятный спокойный голос. Благодарю за ваш труд!
Спасибо!
Здравствуйте! Подтверждаю все комметарии о понятности и полезности вашего видео!)) Я в восторге, что нашла его!
Спасибо большое за качественный материал в доступном формате!
спасибо, Андрей! Лукас от сео-гуру СЕООНЛИ
лайк не глядя ибо контент и так будет класный_)
Спасибо! Но посмотреть будет полезно ;-)
Эти короткие лекции внесли бОльшую ясность, чем 2 часовые размусоливания на других каналах
Спасибо!
Случайно наткнулся на канал, и весьма удивлен качеству, как контента так и подачи. Покупал курсы по этой теме на Udemy, у английских авторов. Ваш контент намного проще усваивается. Спасибо!
Пожалуйста! Рад, что понравилось! Не все хорошее должно быть платным 😀
Действительно спасибо! Теперь разобрался в этой каше. Ну очень полезное видео!!!
Спасибо! Рад, что получилось разобраться!
Спасибо , Андрей!
Пожалуйста!
Всего вам хорошего!
Вы растите будущих специалистов 🙋
Вот такие преподаватели должны работать в Российских вузах. А не старые замшелые, извините за слово, но пердуны. Для себя, я безусловно ничего нового не открыл. Но подписался исключительно ради поддержки канала Господина Созыкина. Чтобы канал продвинулся в топы youtuba. Ещё раз, отличная подача материала. Научить других, тому что знаешь сам это тоже талант.
Спасибо за поддержку.
Я работаю как раз в российском вузе 😉
@@AndreySozykin Вы белая ворона. Среди вузов.
Просто жесть... про рут уц и запись их сертификатов в ось - my mind is blowing... спасибо за видео,
P.S.: очччень редко оставляю сообщения
Пожалуйста! Рад что материал оказался настолько полезен, что заслужил комментария 😉
Если бы можно поставить миллион лайков, я бы поставила. Все четко, понятно, по полочкам. Огромное спасибо Вам!
я в восторге. спасибо, храни вас Господь!
Пожалуйста! Успехов!
Доступное и толковое изложение. Спасибо за ваш труд!
Отличная лекция . Все понятно, одно удовольствие слушать, Спасибо огромное Андрей за Ваш труд !!!
Простое и понятное объяснение... Ещё пару контрольных вопросов для закрепления материала, чтобы слушатели не кисли, а проявляли активность в ответных комментариях. И аудитории полезно, и канал оживёт.
Спасибо за предложение!
Есть ли в RUclips инструмент, чтобы сделать простые тесты под видео?
Или вопросы задавать просто голосом прямо в видео?
@@AndreySozykin насколько я знаю (почти всегда) авторы роликов задают вопрос и просят ответить в комментариях
удивительно просто рассказано, отлично. ещё слова для статистики
Я вот в марте ходил на собеседование в одну компанию и там мне задали несколько каверзных вопросов про TLS/SLL после которых мне пришлось краснеть))
Эххх.. Если бы Вы выпустили свои уроки немного раньше))) Но всё равно, спасибо за урок - очень интересно!!
Надеюсь, это не последнее собеседование. Успехов!
@@AndreySozykin Спасибо!!) После ваших видео уж точно не последнее! Вы очень интересно подаёте материал, а самое главное, именно после Ваших видео очень легко читать книги и статьи по затронутым темам, так как уже сформирован некий базис.
Ну, а компания была немного всё таки по выше уровнем, чем я, просто случайно получилось попасть на собеседование, и если бы не этим вопросом, то каким-либо другим уж точно поставили бы меня в тупик) Зато есть к чему стремится!)
@@xavivore9628
привет!) как оно сейчас? сетями занимаешься?
подкинешь что-нибудь еще почитать/посмотреть кроме Андрея?
Андрей, огромное спасибо за вашу работу! Очень здорово, продолжайте!
Спасибо вам, за ваш труд!
Пожалуйста!
Спасибо! Очень нужная инфа в доступном формате.
Благодарю, Андрей! Очень полезно
Спасибо, Андрюха! Делай ещё уроки)
Обязательно буду делать!
Андрей, Вы написали тут важную вещь, что при регистрации сертификата у удост. центра "Сервер отправляет удостоверяющему центру запрос на создание сертификата и высылает свой открытый ключ." Ещё было сказано, что сертификаты выдаются на непродолжительное время ( 3 месяца например), понятно в каких целях. НО в вашем прошло видео было сравнение двух алгоритмов асс. шифрования RSA и Д-Х. Первый, да, - генерирует тот самый закрытый ключ и, соответственно, открытый один раз на продолжительное время, из-за чего подвержен неполной совершенной секретности и в связи с этим исключен из TSL 1.3. А второй, - генерирует наборы ключей: открытый (g, p значения) и закрытый каждый раз при установке нового соединения. Итак, вопрос. При использовании Д-Х в TSL 1.3, сертификат для каждого нового соединения содержит новый уникальный открытый ключ(g, p значения), и соответственно, такой сертификат переподписывается удост. центром снова и снова - или же это как-то работает по-другому?
Всё разобрался.
The server (and the client, if they are authenticated) signs their Diffie-Hellman public key with the private key in the server certificate (which is usually RSA or ECDSA). The fact that both sides can negotiate a connection successfully and the Diffie-Hellman public key is signed proves authenticity of the connection. An attacker impersonating the server would be limited to reusing a previous signed DH public key sent by the server, but because it did not know the private key, it couldn't successfully negotiate a connection.
Спасибо, что прояснили, мне тоже непонятен был этот момент
Спасибо. Сам мучался этим вопросом и не мог найти ответ. Буду примного благодарен, если укажите где нашли это объяснение.
@@mrmaxepik
всё равно ничего не понятно из текста: кто подписывает-то ключи/сертификаты.
и что за "negotiate a connection"? обычно establish a connection.
Просто накиданы общие слова без конкретики.
Здравствуйте, спасибо за урок!.
Цитирую вас: "Например, если мы расшифровываем сообщение с помощью открытого ключа с сайта банка, то значит мы можем быть уверены, что получили это сообщение от банка". Но ведь сертификат банка является публичным и может быть скопирован злоумышленником. Что если злоумышленник скопирует себе этот сертификат, затем выступит в роли человека по середине? Тогда ведь клиент получит копию сертификата банка но от злоумышленника. Так как это копия сертификата, клиент сможет дешифровать подпись публичным ключом удостоверяющего центра и результат дешифровки будет совпадать с хешем от данных т.к злоумышленник не менял сертификат. В результате аутентификация будет пройдена, а по факту сообщение нам отправил злоумышленник, а не банк. Как клиент в таком случае поймет, что этот сертификат был получен от злоумышленника и перестанет передавать ему свои данные?
так у банка **закрытый** ключь с помощью которого он шифрует сообщение! он не находится в открытом доступе
Отличный вопрос. При использовании RSA вроде понятно(клиент зашифрует семитричный ключ открытым ключем и только сервер его расшиврует своим закрытым).
А вот при использовании алгоритма Диффи-Хеллмана(да еще и эфемерного)мне не понятно как сертификат спасет от mitm.
Злоумышленник отдаст сертификат банка клиенту, клиент его проверит и радостный пойдет устанавливать соединене с злоумышленником по алгоритму Диффи-Хеллмана.
Оказывается выше в комментариях с подобным вопросом уже дали ответ. Параметры для алгоритма DH тоже шифруются ключем из сертификата.
Спасибо за урок!
Пожалуйста!
максимально полезно, спасибо)
Здравствуйте Андрей! спасибо за очередную понятную лекцию, у меня вопрос. сервер создаёт 2 ключа открытый и закрытый, после он подаёт запрос в Удостоверяющий центр на сертификат этого ключа, в ответ он получает этот самый сертификат, и после он может слать его пользователям и те расшифровывая его понимают что этот ключ подлинный? как они это поняли? из-за того что подпись центра управления стоит? Так ведь получается Хакер может сделать свой сервер, запросить на него сертификат, а после тупо отправлять его пользователям, на нём ведь стоит подпись, след ключ в нём подлинный, я не особо понимаю как клиент понимает что ключ именно этого сервера? возможно вопрос глупый но всё же я действительно не понял.
Второй вопрос. выходит все пользователи сервера, исп. один и тот же ключ? то есть расшифровать сообщения всех пользователей может лишь один ключ?
А трак же вопрос. все хосты хоронят открытые ключи центра управления в памяти? иначе как они расшифровывают подписи сертификатов? если да то выходит что открытый ключ удостоверяющего центра тоже один на всех?
Заранее благодарю за ответ. Ваши курсы действительно находка!!!
Если уже поняли, объясните, пожалуйста
Спасибо большое!)
Пожалуйста!
Не совсем понятно что если сообщение от сервера(касаемое сертификата), злоумышленник по середине, передаст без изменений, а в остальном трафике будет посредником?
Спасибо вам огромное!
Допустим, мы получили от сервера сертификат, выданный промежуточным CA. Далее нам нужно провалидировать сертификат этого CA, пока по цепочке не доберемся до корневого CA. Вопрос в том, откуда браузер получает этот промежуточный сертификат (в хранилище ведь только корневые сертификаты)? Сервер присылает всю цепочку сертификатов или браузер сам получает сертификат с сайта промежуточного CA?
UPD: увидел, что в Chrome в настройках можно найти список сертификатов промежуточных центров. Тем не менее, вопрос, как они там появились, остается.
UPD: ответ быстро нашелся security.stackexchange.com/questions/211749/where-do-tls-clients-fetch-intermediate-ca-certificates-from. Действительно, сервер присылает всю цепочку, кроме корневого сертификата в общем случае. Но браузер может кешировать промежуточные сертификаты.
Да, сервер присылает всю цепочку сертификатов.
Спасибо!!!
Пожалуйста!
Здравствуйте! Ответьте пожалуйста на вопрос. Так как в пиратской ОС может быть изменено хранилище сертификатов. Получается люди, которые скачивают пиратскую ОС подвержены "атаке человек посередине"?
Да, конечно.
@@AndreySozykin спасибо!
Не могли рассказать про авторизацию по клиентскому сертификату?
То есть сервер шлет сертификат пользователю. Подпись это хеш(sha1 или варианты) самого сертификата, который зашифрован закрытым ключем сервера.
Пользователь получает сертификат и расшифровывает подпись. Но как открытый ключ расшифровывает подпись, если этот ключ открытый и может только шифровать?
С помощью открытого ключа можно расшифровать то, что зашифровано закрытым ключом. И наоборот: если сообщение зашифровано открытым ключом, то его можно расшифровать закрытым ключом.
@@AndreySozykin Не понимаю, вы ранее говорили что открытый ключ только шифрует, а расшифровать может толь закрытый. Это же логика работы асинхронных методов шифрования
Ассиметричное шифрование означает, что один ключ используется для шифрования, а другой для расшифровки. При этом открытый и закрытый ключи могут использоваться для обеих целей: шифруем открытым - расшифровываем закрытым, шифруем закрытым - расшифровываем открытым.
@@AndreySozykin то есть, подпись которую ставит удостоверяющий центр, может расшифровывать открытый ключ, который содержится в сертификате удостоверяющего центра, который есть у нас в момент установки соединения
Огромное спасибо за лекцию! Но возник один вопрос, возможно глуповатый, но для полного понимания для себя я все таки его задам. Как я понял, электронную подпись имеет только сертификат, и используется только для установления защищенного соединения. То есть все остальные сообщения, которые пересылаются после установления соединения и генерации ключей, не подписываются, я правильно понимаю?
Все остальные сообщения используют MAC, а не электронную подпись. В MAC работает симметричное шифрование, которое гораздо быстрее, чем шифрование с открытым ключем.
В TLS достаточно проверить подлинность сервера один раз, во время установки соединения. После этого подменить сервер почти не возможно, если используются сильные наборы шифров.
@@AndreySozykin спасибо за пояснение
@@AndreySozykin Приветствую, Андрей, спасибо за видео. То есть в алгоритмах работы с цифровой подписью и с MAC отличия только в том, что в одном случае используются симметричные ключи, а в другом открытый/закрытый? При получении сообщения в обоих случаях происходит извлечение хешей(из подписи/мака с помощью ключа и из сообщения с помощью хеш-функции) и сравнение этих хешей? Спасибо.
Отличный контент 👍
Прекрасное изложение!
Спасибо!
Ни одного диза под роликом)
Видео только вчера вышло. Еще появяться ;-)
Спасибо за видео! Такой вопрос: если открытый ключ корневого агенства прошивается в ОС, то предполагается, что он - бессрочный, а закрытый ключ принципиально не подвержен утечке? Или есть какой-то механизм обновления ключа?
Механизм обновления есть, для Windows описан здесь - support.microsoft.com/en-us/topic/support-for-urgent-trusted-root-updates-for-windows-root-certificate-program-in-windows-a4ac4d6c-7c62-3b6e-dfd2-377982bf3ea5 .
Клиенты каждую неделю опрашивают сервер PKI, появились ли обновления сертификатов.
@@AndreySozykin Спасибо.
Я не понял почему удостоверяющий центр выдал вам в сертификате ваш открытый ключ? Ведь открытый и закрытый ключ должен создать ваш сервер. Откуда удостоверяющий центр взял ваш открытый ключ?
Сервер отправляет удостоверяющему центру запрос на создание сертификата и высылает свой открытый ключ.
Встает вопрос доверия к сертификационному центру. Я так понимаю сигнал их не использует. Блин, получается надо мне копать дальше ...
Да, вопрос доверия, важный. Например, сейчас активно рекомендуют устанавливать сертификаты Мин цифры и скоро многие официальные сайты не будут работать без них.
Здравствуйте Уважаемый Андрей, У меня вопрос такой: Есть веб сервер который работает сервер сертификат то есть https, сервер когда передает эти сертификаты к клиентам ,чтобы они смогли шифровать первоначальные данные (handshake) и когда клиенты шифровав данные этим сертификатом отправляет данные обратно серверу сервер как то проверяет действительно клиенты шифровали данные этим сертификатом то есть это тот сертификат ? или сервер private ключом просто проверят смог расшифровать данные от клиентов , если да то все ок
Заранее благодарен !! буду рад если ответите )
Самим сертификатом нельзя ничего зашифровать или расшифровать. Для этого используется открытый ключ в сертификате. Сообщение, зашифрованное открытым ключом, можно расшифровать только закрытым ключом сервера. Поэтому если расшифровать не удалось, то ключ неправильный.
С другой стороны, злоумышленник может перехватить открытый ключ сервера и зашифровать сообщение им. Это сделать просто, т.к. ключ открытый. Сервер будет способен расшифровать такое сообщение от злоумышленника.
Чтобы обнаружить такую проблему как раз и используется сертификат. Сервер может проверить сертификат клиента и убедиться в его подлинности. И если сертификат не действительный, то сообщение не будет обработано, даже если оно зашифровано открытым ключом сервера. Но серверы не всегда проверяют подлинность клиента с помощью сертификата. Web-серверы не делают этого почти никогда.
@@AndreySozykin Спасибо за такую объяснения 👍
@@eldarkarimov5791
абсолютно безграмотно пишешь, неуч
Спасибо за отличные лекции! Хочу уточнить один момент: если с помощью открытого ключа можно расшифровать информацию, распространяемую закрытым ключём, разве это не ставит под угрозу приватность диалога клиента и сервера?
Обычно при информацию шифруют как раз при помощи открытого ключа. Расшифровать такую информацию может только обладатель закрытого ключа. Поэтому приватность диалога не страдает, если не будет получен доступ к закрытому ключу.
Другой вариант, при котором данные шифруются закрытым ключом и расшифровываются открытым, применяется для электронной подписи. В этом случае каждый, у кого есть открытый ключ, может убедиться, что подписан обладает закрытым ключом, т.к. с помощью открытого ключа можно расшифровать только сообщение, зашифрованное закрытым ключом.
Спасибо!!! Я все понял
На чем зарабатывают владельцы удостоверяющих центров? На серверах, чьи ключи они подписывают?
Да. Обычно за получение сертификата нужно платить деньги. Исключение составляет Let's Encrypt.
Интересно нельзя ли использовать систему блокчейндж для подписи сертификат? Как по моему маленькому представлению это гораздо надёжнее но пока не имею ни какого понятие как это осуществить детально
Андрей спасибо за уроки, очень благодарен за Ваш труд. Хотел спросить не собираетесь ли Вы в ближайшее время рассмотреть стек протоколов SS7 ? Заранее спасибо
3 человека посередине поставили диз
😀😀😀
@@AndreySozykin
я вот чего не могу понять. вот есть RSA с парой ключей. Открытым шифруем, закрытым расшифровываем. Вопрос: а можно этим же закрытым зашифровать, а открытым расшифровать? Т.е. реализовать ЭЦП. Или для ЭЦП нужна отдельная пара ключей?
@@manOfPlanetEarthоно так и работает. сообщение хэшируется, хэш зашифровывается приватным ключем, передается клиенту. клиент получает сообщение + сертификат, расшифровывает сертификат открытым ключе, хэширует сообщение, сравнивает хэши. просто открытый ключ надо как-нибудь заранее передать, по флешке или через гитхаб
надо ли удалять просроченные сертификаты из системы, обязательно ли это делать?
А данные, полученные клиентом, для сравнения с подписью хешируются тем же, присланным от сервера открытым ключом или своим?
Почему я вообще должен доверять удостоверяющему центру? Что будет, если я зарегистрирую свой удостоверяющий центр, и буду иногда устраивать атаки человек посередине? Мне просто потом не будут доверять, если обнаружат это?
Да, именно так.
То есть в момент когда пользователь раз в несколько лет скачивает сертификат с корневого удостоверяющего центра все же можно осуществить MITM подмену ?
Зачем в windows установлены сертификаты уже с истекшим сроком?
Хотите сами пронаблюдать mitm? просто попробуйте зайти на сайт ми5/ми6
не ясно кто где подмешивает например имя сервера. ведь именно имя идентифицирует сервер. или у вас это раскрыто в лекции про фишинг наверно. но тут про подмешивание тоже надо было упомянуть хотя бы
Андрей, по какой причине мы должны доверять удостоверяющему центру? Ведь за ним могут стоять недобросовестные люди.
Именно так. Нужно очень внимательно относится к удостоверяющим центрам, сертификаты которых установлены на ваше устройство. Вот, правительство Казахстана заставляло всех граждан доверять государственному удостоверяющему центру, чтобы можно было читать весь TLS трафик - m.habr.com/ru/post/272207/
@@AndreySozykin И что мы теперь должны доверять правительству?
@@AndreySozykin как правительство Казахстана может получить доступ к зашифрованному трафику жителей (например, на gmail)? Такая ли схема: при каждом запросе к gmail оно "встанет посередине", а свой прослушивающий сервер аутентифицирует для устройства пользователя, используя свой "карманный" CA?
@@AndreySozykin это хорошо или плохо
Где находится эти уд центры
Андрей, а лекция по сертификатам ГОСТ будет?
Не планировал. Но если интересно, то могу попробовать сделать.
@@AndreySozykin было бы очень интересно) особенно в контексте сравнения с RSA)
Спасибо! А в этом плейлисте будут рассмотрены только TLS/SSL и HTTPS или другие защищенные протоколы тоже?
Будут другие протоколы, основанные на TLS: DNSoverTLS, OpenVPN.
@@AndreySozykin
пока не дошли руки?☹️
Супер!
А как SSH соотносится с TLS/SSL?
Никак. SSH - это независимый протокол, он не использует TLS/SSL.
При передаче ЭЦП, данные отдельно шифруются от хэша? Или просто передаются в открытом виде с подписью. Но тогда же при перехвате злоумышленник не сможет их изменить, но спокойно просмотрит. А если там тайная информация? Получается данные должны шифроваться по какому то алгоритму отдельно. По тому же RSA, используя те же ключи? Или дополнительно использует симметричное шифрование?
Да, элеатронная подпись и шифрование - это разные технологии. Электронная подпись нужна, чтобы документ нельзя было изменить. Шифрование - чтобы документ нельзы было прочитать. Конечно, шифрование и электронную подпись можно использовать совместно.
@@AndreySozykin Спасибо большое за ответ)
Спасибо
Пожалуйста!
2:57 не правда! Это так не работает, сообщение может быть зашифрованно открытым ключ и расшифровано только закрытым!!! В ОБРАТНУЮ СТОРОНУ ЭТО НЕ РАБОТАЕТ!!
Работает, подтяни знания по криптографии… Можешь включить ролик про ассиметричное шифрование RSA, взять ручку и на небольших числах создать два ключа. Далее попробуй зашифровать текст закрытым и расшифровать открытым , и будет тебе чудо
Когда мы генерируем два ключа, мы сами решаем какой из них private а какой public . При генерировании сервером, он сам также решает какой он делает private а каким можно делиться
Super
Меня смутило это место! Кто в курсе проясните. Клиент не расшифровывает а сверяет сертификат с СА, так как доверять может только СА. А в этом месте клиент расшифровывает Сертификат от сервера. В этом месте обьясните пожалуйста! ruclips.net/video/6wCwjIhGylY/видео.html
Короче хакеров берут измором, а не защитой.
и хакеров и как следствие нас, изучающих, тоже берут измором🤣
Ком ком комментарий комментирующий
+Plus
+
Это всё конечно классно, но откуда такая уверенность, что закрытый 🔑 уже не в кармане злоумышленников, и они электронную подпись и подделывают, кстати длжеоа уже таких примеров по СМИ.. Ибо тот кто хочет взломать он знает как система работает и начнёт её с поиска именно закрытого ключа... Короче судя по алгоритмам шифрования выше, пока ничего надёжного нет... Посмотрим конечно на другими системы... Материал хорошо 👌 подан, кратко и содержательно 👍👏
Андрей, ты хочешь сказать, что кому доверяет Билл Гейтс, тому должны доверять и мы? А по какой причине мы должны доверять Биллу Гейтсу?
Очень правильный вопрос! Слепо доверять не стоит. Нужно, как минимум, посмотреть, что установлено в хранилище сертификатов. Если сертификат вызывает подозрение, то его можно удалить из хранилища.
@@AndreySozykin А как выявить подозрительный сертификат?
@@AndreySozykin Напросился логичный вопрос - как удалить? Я нашёл в списке сертификатов один, срок которого истёк в июле прошлого года. Но кнопка Remove неактивна. Только кнопки Import и Export рабочие.
три раза заснул, более нудного и монотонного голоса я не слышал.
спасибо
Пожалуйста!
Спасибо!
Пожалуйста!
+
Спасибо!
Пожалуйста!
Спасибо!