Инфраструктура открытых ключей в TLS/SSL | Защищенные сетевые протоколы

Лекция по подтверждению подлинности сервера в TLS/SSL. Страница учебного курса - www.asozykin.ru/courses/netwo...
00:00 - Атака человек посередине
02:30 - Электронная подпись
05:26 - Инфраструктура открытых ключей
05:57 - Сертификаты TLS/SSL
06:59 - Просмотр сертификата сайта
07:13 - Что входит в сертификат
11:07 - Путь сертификации/цепочка доверия
11:32 - Хранилище сертификатов
13:20 - Самоподписанный сертификат
14:42 - Набор шифров TLS/SSL
15:24 - Итоги
Добавляйтесь в друзья в социальных сетях:
вКонтакте - avsozykin
Instagram - / sozykin_andr
Facebook - / asozykin
Twitter - / andreysozykin
Мой сайт - www.asozykin.ru
Мой канал с краткими и понятными объяснениями сложных тем в ИТ и компьютерных науках - / andreysozykincs

[@Alex-dw3pn]

Чтобы настолько понятно объяснить тему, нужен настоящий талант. Просто браво.

[@AndreySozykin]

Спасибо!

[@theLoneCodesman]

Я в шоке, на 17 минут видео информации подано больше чем у других в часовых роликах. Очень хорошая подача информации, все по полочкам, без раздражающих моментов. Даже произношение английских названий корректное! Спасибо вам за такой контент!

[@AndreySozykin]

Пожалуйста! Рад, что формат курсов нравится!

[@at0m1x191919]

Наконец-то разобрался с этим. Спасибо!

[@AndreySozykin]

Пожалуйста!

[@alexanderd7201]

Андрей, огромное спасибо за вашу работу! Очень здорово, продолжайте!

[@SiberFrost]

Андрей, спасибо! Посмотрите на всех этих людей, которые вам искренне благодарны! Это указывает на то, что вы вложились от души. Ещё раз спасибо, это действительно золотая находка среди остального контента

[@AndreySozykin]

Спасибо за приятный отзыв! Рад, что курсы нравятся!

[@gabizhum6151]

Отличная лекция . Все понятно, одно удовольствие слушать, Спасибо огромное Андрей за Ваш труд !!!

[@trek3456]

Всего вам хорошего! Вы растите будущих специалистов 🙋

[@SHKIPPER989]

лайк не глядя ибо контент и так будет класный_)

[@AndreySozykin]

Спасибо! Но посмотреть будет полезно ;-)

[@sergm9812]

Доступное и толковое изложение. Спасибо за ваш труд!

[@megatronov]

Спасибо! Очень нужная инфа в доступном формате.

[@FrAnkYbboy61]

Благодарю, Андрей! Очень полезно

[@user-cp8rf4ej6w]

Если бы можно поставить миллион лайков, я бы поставила. Все четко, понятно, по полочкам. Огромное спасибо Вам!

[@bars374]

я в восторге. спасибо, храни вас Господь!

[@AndreySozykin]

Пожалуйста! Успехов!

[@lan0585]

Спасибо , Андрей!

[@AndreySozykin]

Пожалуйста!

[@natalia1908]

Хорошая подача материала, приятный спокойный голос. Благодарю за ваш труд!

[@AndreySozykin]

Спасибо!

[@KILLZONERUSSIA]

удивительно просто рассказано, отлично. ещё слова для статистики

[@user-yh4rx9cq3n]

Спасибо вам, за ваш труд!

[@AndreySozykin]

Пожалуйста!

[@user-hp3xr8it8n]

максимально полезно, спасибо)

[@user-uq4ix5ie3q]

Спасибо вам огромное!

[@seoonlyRU]

спасибо, Андрей! Лукас от сео-гуру СЕООНЛИ

[@sergeydev8273]

Эти короткие лекции внесли бОльшую ясность, чем 2 часовые размусоливания на других каналах

[@AndreySozykin]

Спасибо!

[@user-tr5xk8tj9r]

Действительно спасибо! Теперь разобрался в этой каше. Ну очень полезное видео!!!

[@AndreySozykin]

Спасибо! Рад, что получилось разобраться!

[@MrSatan662]

Спасибо, Андрюха! Делай ещё уроки)

[@AndreySozykin]

Обязательно буду делать!

[@alexeyi.197]

Отличный контент 👍

[@sudmal]

Вот проходил курсы цыски (эти их Bob и Alice), книжки разные читал. Но в такой подаче знания ложатся как по маслу. Мое почтение! Гранд мерси за курс!

[@bivis99]

Лучшие обьяснения по сетевым технологиям

[@AndreySozykin]

Спасибо!

[@user-hm2ig2mh3m]

Спасибо за урок!

[@AndreySozykin]

Пожалуйста!

[@user-fq5xp8xg2i]

Спасибо большое!)

[@AndreySozykin]

Пожалуйста!

[@user-on3un9dq5e]

Супер!

[@esse7847]

Случайно наткнулся на канал, и весьма удивлен качеству, как контента так и подачи. Покупал курсы по этой теме на Udemy, у английских авторов. Ваш контент намного проще усваивается. Спасибо!

[@AndreySozykin]

Пожалуйста! Рад, что понравилось! Не все хорошее должно быть платным 😀

[@dmtconst3633]

Спасибо!!! Я все понял

[@c333ton]

Прекрасное изложение!

[@AndreySozykin]

Спасибо!

[@RFSkyliner]

Просто жесть... про рут уц и запись их сертификатов в ось - my mind is blowing... спасибо за видео, P.S.: очччень редко оставляю сообщения

[@AndreySozykin]

Пожалуйста! Рад что материал оказался настолько полезен, что заслужил комментария 😉

[@user-yt7eg2ey4t]

Спасибо!

[@AndreySozykin]

Пожалуйста!

[@user-zp6hk8ic6z]

Вот такие преподаватели должны работать в Российских вузах. А не старые замшелые, извините за слово, но пердуны. Для себя, я безусловно ничего нового не открыл. Но подписался исключительно ради поддержки канала Господина Созыкина. Чтобы канал продвинулся в топы youtuba. Ещё раз, отличная подача материала. Научить других, тому что знаешь сам это тоже талант.

[@AndreySozykin]

Спасибо за поддержку. Я работаю как раз в российском вузе 😉

[@user-zp6hk8ic6z]

@@AndreySozykin Вы белая ворона. Среди вузов.

[@user-kz5xo2zh5r]

Спасибо!!!

[@AndreySozykin]

Пожалуйста!

[@sserj01]

Простое и понятное объяснение... Ещё пару контрольных вопросов для закрепления материала, чтобы слушатели не кисли, а проявляли активность в ответных комментариях. И аудитории полезно, и канал оживёт.

[@AndreySozykin]

Спасибо за предложение! Есть ли в KZbin инструмент, чтобы сделать простые тесты под видео? Или вопросы задавать просто голосом прямо в видео?

[@constantinemakarov5865]

@@AndreySozykin насколько я знаю (почти всегда) авторы роликов задают вопрос и просят ответить в комментариях

[@user-rm6qu8rz8i]

Андрей спасибо за уроки, очень благодарен за Ваш труд. Хотел спросить не собираетесь ли Вы в ближайшее время рассмотреть стек протоколов SS7 ? Заранее спасибо

[@xavivore9628]

Я вот в марте ходил на собеседование в одну компанию и там мне задали несколько каверзных вопросов про TLS/SLL после которых мне пришлось краснеть)) Эххх.. Если бы Вы выпустили свои уроки немного раньше))) Но всё равно, спасибо за урок - очень интересно!!

[@AndreySozykin]

Надеюсь, это не последнее собеседование. Успехов!

[@xavivore9628]

@@AndreySozykin Спасибо!!) После ваших видео уж точно не последнее! Вы очень интересно подаёте материал, а самое главное, именно после Ваших видео очень легко читать книги и статьи по затронутым темам, так как уже сформирован некий базис. Ну, а компания была немного всё таки по выше уровнем, чем я, просто случайно получилось попасть на собеседование, и если бы не этим вопросом, то каким-либо другим уж точно поставили бы меня в тупик) Зато есть к чему стремится!)

[@user-bn2zi6vq2h]

Здравствуйте Андрей! спасибо за очередную понятную лекцию, у меня вопрос. сервер создаёт 2 ключа открытый и закрытый, после он подаёт запрос в Удостоверяющий центр на сертификат этого ключа, в ответ он получает этот самый сертификат, и после он может слать его пользователям и те расшифровывая его понимают что этот ключ подлинный? как они это поняли? из-за того что подпись центра управления стоит? Так ведь получается Хакер может сделать свой сервер, запросить на него сертификат, а после тупо отправлять его пользователям, на нём ведь стоит подпись, след ключ в нём подлинный, я не особо понимаю как клиент понимает что ключ именно этого сервера? возможно вопрос глупый но всё же я действительно не понял. Второй вопрос. выходит все пользователи сервера, исп. один и тот же ключ? то есть расшифровать сообщения всех пользователей может лишь один ключ? А трак же вопрос. все хосты хоронят открытые ключи центра управления в памяти? иначе как они расшифровывают подписи сертификатов? если да то выходит что открытый ключ удостоверяющего центра тоже один на всех? Заранее благодарю за ответ. Ваши курсы действительно находка!!!

[@Dm-if3vl]

Спасибо

[@AndreySozykin]

Пожалуйста!

[@azersharifov7786]

Super

[@artur_kia]

спасибо

[@AndreySozykin]

Пожалуйста!

[@mrmaxepik]

Андрей, Вы написали тут важную вещь, что при регистрации сертификата у удост. центра "Сервер отправляет удостоверяющему центру запрос на создание сертификата и высылает свой открытый ключ." Ещё было сказано, что сертификаты выдаются на непродолжительное время ( 3 месяца например), понятно в каких целях. НО в вашем прошло видео было сравнение двух алгоритмов асс. шифрования RSA и Д-Х. Первый, да, - генерирует тот самый закрытый ключ и, соответственно, открытый один раз на продолжительное время, из-за чего подвержен неполной совершенной секретности и в связи с этим исключен из TSL 1.3. А второй, - генерирует наборы ключей: открытый (g, p значения) и закрытый каждый раз при установке нового соединения. Итак, вопрос. При использовании Д-Х в TSL 1.3, сертификат для каждого нового соединения содержит новый уникальный открытый ключ(g, p значения), и соответственно, такой сертификат переподписывается удост. центром снова и снова - или же это как-то работает по-другому?

[@mrmaxepik]

Всё разобрался. 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.

[@iesmirnoff_dev]

Спасибо, что прояснили, мне тоже непонятен был этот момент

[@NikolaiRiazhskikh]

Спасибо. Сам мучался этим вопросом и не мог найти ответ. Буду примного благодарен, если укажите где нашли это объяснение.

[@publiusdimianius6206]

Спасибо за отличные лекции! Хочу уточнить один момент: если с помощью открытого ключа можно расшифровать информацию, распространяемую закрытым ключём, разве это не ставит под угрозу приватность диалога клиента и сервера?

[@AndreySozykin]

Обычно при информацию шифруют как раз при помощи открытого ключа. Расшифровать такую информацию может только обладатель закрытого ключа. Поэтому приватность диалога не страдает, если не будет получен доступ к закрытому ключу. Другой вариант, при котором данные шифруются закрытым ключом и расшифровываются открытым, применяется для электронной подписи. В этом случае каждый, у кого есть открытый ключ, может убедиться, что подписан обладает закрытым ключом, т.к. с помощью открытого ключа можно расшифровать только сообщение, зашифрованное закрытым ключом.

[@user-zx7nt3vt1n]

Спасибо! А в этом плейлисте будут рассмотрены только TLS/SSL и HTTPS или другие защищенные протоколы тоже?

[@AndreySozykin]

Будут другие протоколы, основанные на TLS: DNSoverTLS, OpenVPN.

[@andreivasiljev2791]

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

[@user-gg9ec2nm6i]

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

[@NikolaiRiazhskikh]

Отличный вопрос. При использовании RSA вроде понятно(клиент зашифрует семитричный ключ открытым ключем и только сервер его расшиврует своим закрытым). А вот при использовании алгоритма Диффи-Хеллмана(да еще и эфемерного)мне не понятно как сертификат спасет от mitm. Злоумышленник отдаст сертификат банка клиенту, клиент его проверит и радостный пойдет устанавливать соединене с злоумышленником по алгоритму Диффи-Хеллмана.

[@NikolaiRiazhskikh]

Оказывается выше в комментариях с подобным вопросом уже дали ответ. Параметры для алгоритма DH тоже шифруются ключем из сертификата.

[@andreyblinnikov9874]

Спасибо за видео! Такой вопрос: если открытый ключ корневого агенства прошивается в ОС, то предполагается, что он - бессрочный, а закрытый ключ принципиально не подвержен утечке? Или есть какой-то механизм обновления ключа?

[@AndreySozykin]

Механизм обновления есть, для 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, появились ли обновления сертификатов.

[@andreyblinnikov9874]

@@AndreySozykin Спасибо.

[@user-eo8uv9yl2p]

То есть в момент когда пользователь раз в несколько лет скачивает сертификат с корневого удостоверяющего центра все же можно осуществить MITM подмену ?

[@owlhunter1519]

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

[@AndreySozykin]

Все остальные сообщения используют MAC, а не электронную подпись. В MAC работает симметричное шифрование, которое гораздо быстрее, чем шифрование с открытым ключем. В TLS достаточно проверить подлинность сервера один раз, во время установки соединения. После этого подменить сервер почти не возможно, если используются сильные наборы шифров.

[@owlhunter1519]

@@AndreySozykin спасибо за пояснение

[@user-by4lq6ui3l]

@@AndreySozykin Приветствую, Андрей, спасибо за видео. То есть в алгоритмах работы с цифровой подписью и с MAC отличия только в том, что в одном случае используются симметричные ключи, а в другом открытый/закрытый? При получении сообщения в обоих случаях происходит извлечение хешей(из подписи/мака с помощью ключа и из сообщения с помощью хеш-функции) и сравнение этих хешей? Спасибо.

[@user-xr5kh1zc1k]

Интересно нельзя ли использовать систему блокчейндж для подписи сертификат? Как по моему маленькому представлению это гораздо надёжнее но пока не имею ни какого понятие как это осуществить детально

[@userbill3236]

не ясно кто где подмешивает например имя сервера. ведь именно имя идентифицирует сервер. или у вас это раскрыто в лекции про фишинг наверно. но тут про подмешивание тоже надо было упомянуть хотя бы

[@arvgo41]

Не совсем понятно что если сообщение от сервера(касаемое сертификата), злоумышленник по середине, передаст без изменений, а в остальном трафике будет посредником?

[@user-jk3so4by8j]

Здравствуйте! Ответьте пожалуйста на вопрос. Так как в пиратской ОС может быть изменено хранилище сертификатов. Получается люди, которые скачивают пиратскую ОС подвержены "атаке человек посередине"?

[@AndreySozykin]

Да, конечно.

[@user-jk3so4by8j]

@@AndreySozykin спасибо!

[@Arahaon]

3 человека посередине поставили диз

[@AndreySozykin]

😀😀😀

[@gghost_rider]

Хотел спросить о ситуации с сертификатом. Может ли "человек по середине" установить связь с сервером банка и получить его сертификат и далее использовать его для общения с жертвой. Выйдет так, что клиент будет думать, что общается с сервером, но в самом деле все данные попадут в руки для злоумышленика.

[@MELkey3]

Нет, у злоумышленника нет закрытого ключа, значит он не может ничего расшифровать или подписать

[@user-jd8ky3dj5c]

Андрей, а лекция по сертификатам ГОСТ будет?

[@AndreySozykin]

Не планировал. Но если интересно, то могу попробовать сделать.

[@user-jd8ky3dj5c]

@@AndreySozykin было бы очень интересно) особенно в контексте сравнения с RSA)

[@eldarkarimov5791]

Здравствуйте Уважаемый Андрей, У меня вопрос такой: Есть веб сервер который работает сервер сертификат то есть https, сервер когда передает эти сертификаты к клиентам ,чтобы они смогли шифровать первоначальные данные (handshake) и когда клиенты шифровав данные этим сертификатом отправляет данные обратно серверу сервер как то проверяет действительно клиенты шифровали данные этим сертификатом то есть это тот сертификат ? или сервер private ключом просто проверят смог расшифровать данные от клиентов , если да то все ок Заранее благодарен !! буду рад если ответите )

[@AndreySozykin]

Самим сертификатом нельзя ничего зашифровать или расшифровать. Для этого используется открытый ключ в сертификате. Сообщение, зашифрованное открытым ключом, можно расшифровать только закрытым ключом сервера. Поэтому если расшифровать не удалось, то ключ неправильный. С другой стороны, злоумышленник может перехватить открытый ключ сервера и зашифровать сообщение им. Это сделать просто, т.к. ключ открытый. Сервер будет способен расшифровать такое сообщение от злоумышленника. Чтобы обнаружить такую проблему как раз и используется сертификат. Сервер может проверить сертификат клиента и убедиться в его подлинности. И если сертификат не действительный, то сообщение не будет обработано, даже если оно зашифровано открытым ключом сервера. Но серверы не всегда проверяют подлинность клиента с помощью сертификата. Web-серверы не делают этого почти никогда.

[@eldarkarimov5791]

@@AndreySozykin Спасибо за такую объяснения 👍

[@DIMARIK9990]

А данные, полученные клиентом, для сравнения с подписью хешируются тем же, присланным от сервера открытым ключом или своим?

[@Voha]

Ни одного диза под роликом)

[@AndreySozykin]

Видео только вчера вышло. Еще появяться ;-)

[@serpov5453]

Это всё конечно классно, но откуда такая уверенность, что закрытый 🔑 уже не в кармане злоумышленников, и они электронную подпись и подделывают, кстати длжеоа уже таких примеров по СМИ.. Ибо тот кто хочет взломать он знает как система работает и начнёт её с поиска именно закрытого ключа... Короче судя по алгоритмам шифрования выше, пока ничего надёжного нет... Посмотрим конечно на другими системы... Материал хорошо 👌 подан, кратко и содержательно 👍👏

[@egornovivan]

Хотите сами пронаблюдать mitm? просто попробуйте зайти на сайт ми5/ми6

[@user-wm7sp4bm6h]

надо ли удалять просроченные сертификаты из системы, обязательно ли это делать?

[@user-gw5lu3gj9g]

При передаче ЭЦП, данные отдельно шифруются от хэша? Или просто передаются в открытом виде с подписью. Но тогда же при перехвате злоумышленник не сможет их изменить, но спокойно просмотрит. А если там тайная информация? Получается данные должны шифроваться по какому то алгоритму отдельно. По тому же RSA, используя те же ключи? Или дополнительно использует симметричное шифрование?

[@AndreySozykin]

Да, элеатронная подпись и шифрование - это разные технологии. Электронная подпись нужна, чтобы документ нельзя было изменить. Шифрование - чтобы документ нельзы было прочитать. Конечно, шифрование и электронную подпись можно использовать совместно.

[@user-gw5lu3gj9g]

@@AndreySozykin Спасибо большое за ответ)

[@ubelian]

То есть сервер шлет сертификат пользователю. Подпись это хеш(sha1 или варианты) самого сертификата, который зашифрован закрытым ключем сервера. Пользователь получает сертификат и расшифровывает подпись. Но как открытый ключ расшифровывает подпись, если этот ключ открытый и может только шифровать?

[@AndreySozykin]

С помощью открытого ключа можно расшифровать то, что зашифровано закрытым ключом. И наоборот: если сообщение зашифровано открытым ключом, то его можно расшифровать закрытым ключом.

[@ubelian]

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

[@AndreySozykin]

Ассиметричное шифрование означает, что один ключ используется для шифрования, а другой для расшифровки. При этом открытый и закрытый ключи могут использоваться для обеих целей: шифруем открытым - расшифровываем закрытым, шифруем закрытым - расшифровываем открытым.

[@ubelian]

@@AndreySozykin то есть, подпись которую ставит удостоверяющий центр, может расшифровывать открытый ключ, который содержится в сертификате удостоверяющего центра, который есть у нас в момент установки соединения

[@Andrey-gp5qi]

Я не понял почему удостоверяющий центр выдал вам в сертификате ваш открытый ключ? Ведь открытый и закрытый ключ должен создать ваш сервер. Откуда удостоверяющий центр взял ваш открытый ключ?

[@AndreySozykin]

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

[@FeelUs]

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

[@AndreySozykin]

Да. Обычно за получение сертификата нужно платить деньги. Исключение составляет Let's Encrypt.

[@dimkaddd7674]

Встает вопрос доверия к сертификационному центру. Я так понимаю сигнал их не использует. Блин, получается надо мне копать дальше ...

[@AndreySozykin]

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

[@user-wm7sp4bm6h]

Зачем в windows установлены сертификаты уже с истекшим сроком?

[@artemivanov2141]

А как SSH соотносится с TLS/SSL?

[@AndreySozykin]

Никак. SSH - это независимый протокол, он не использует TLS/SSL.

[@FeelUs]

Почему я вообще должен доверять удостоверяющему центру? Что будет, если я зарегистрирую свой удостоверяющий центр, и буду иногда устраивать атаки человек посередине? Мне просто потом не будут доверять, если обнаружат это?

[@AndreySozykin]

Да, именно так.

[@MrEmityushkin]

+Plus

[@dmitriys5353]

+

[@kirillp4547]

Допустим, мы получили от сервера сертификат, выданный промежуточным CA. Далее нам нужно провалидировать сертификат этого CA, пока по цепочке не доберемся до корневого CA. Вопрос в том, откуда браузер получает этот промежуточный сертификат (в хранилище ведь только корневые сертификаты)? Сервер присылает всю цепочку сертификатов или браузер сам получает сертификат с сайта промежуточного CA? UPD: увидел, что в Chrome в настройках можно найти список сертификатов промежуточных центров. Тем не менее, вопрос, как они там появились, остается. UPD: ответ быстро нашелся security.stackexchange.com/questions/211749/where-do-tls-clients-fetch-intermediate-ca-certificates-from. Действительно, сервер присылает всю цепочку, кроме корневого сертификата в общем случае. Но браузер может кешировать промежуточные сертификаты.

[@AndreySozykin]

Да, сервер присылает всю цепочку сертификатов.

[@inigoloy]

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

[@AndreySozykin]

Именно так. Нужно очень внимательно относится к удостоверяющим центрам, сертификаты которых установлены на ваше устройство. Вот, правительство Казахстана заставляло всех граждан доверять государственному удостоверяющему центру, чтобы можно было читать весь TLS трафик - m.habr.com/ru/post/272207/

[@inigoloy]

@@AndreySozykin И что мы теперь должны доверять правительству?

[@jonnyradars]

@@AndreySozykin как правительство Казахстана может получить доступ к зашифрованному трафику жителей (например, на gmail)? Такая ли схема: при каждом запросе к gmail оно "встанет посередине", а свой прослушивающий сервер аутентифицирует для устройства пользователя, используя свой "карманный" CA?

[@zhadyraimashova1776]

@@AndreySozykin это хорошо или плохо

[@zhadyraimashova1776]

Где находится эти уд центры

[@ostrov11]

Ком ком комментарий комментирующий

[@user-fk2ks5ij1l]

Короче хакеров берут измором, а не защитой.

[@katharinaartes4734]

Меня смутило это место! Кто в курсе проясните. Клиент не расшифровывает а сверяет сертификат с СА, так как доверять может только СА. А в этом месте клиент расшифровывает Сертификат от сервера. В этом месте обьясните пожалуйста! kzbin.info/www/bejne/bKimqJ1_naysors

[@inigoloy]

Андрей, ты хочешь сказать, что кому доверяет Билл Гейтс, тому должны доверять и мы? А по какой причине мы должны доверять Биллу Гейтсу?

[@AndreySozykin]

Очень правильный вопрос! Слепо доверять не стоит. Нужно, как минимум, посмотреть, что установлено в хранилище сертификатов. Если сертификат вызывает подозрение, то его можно удалить из хранилища.

[@inigoloy]

@@AndreySozykin А как выявить подозрительный сертификат?

[@Egorello100]

@@AndreySozykin Напросился логичный вопрос - как удалить? Я нашёл в списке сертификатов один, срок которого истёк в июле прошлого года. Но кнопка Remove неактивна. Только кнопки Import и Export рабочие.

[@user-mx6qb6en8x]

три раза заснул, более нудного и монотонного голоса я не слышал.

[@dimavolokh8]

Спасибо!

[@AndreySozykin]

Пожалуйста!

[@maximfinojenok228]

+