Спасибо за видео уроки, я просмотрел все ваши уроки во время карантина, именно такие уроки как у вас дают возможность самостоятельно изучать. Еще раз спасибо...
Ложился спать, в итоге просмотрел все видео по tls. Сколько раз пытался понять как оно работает, но только после ваших видео все понял. Огромное спасибо!!!
С первого взгляда ваши видео казались какими-то серьезными и наводили на мысль, что опять ничего не пойму )) Но нет, вы молодец, все очень доступно и главное лаконично объясняете, я в шоке) Спасибо)
Такая проблема есть, человек посередине. Именно об этом я и говорил в конце лекции. Чтобы её решить используется электронеа, подпись и сертификаты открытого ключа. Про них в следующей лекции будет. Шифрование, MAC и сертификаты используются в TLS совместно.
@@Daedalus6968 не так) хэш - это мат функция сведения любого входного многообразия к фиксированному выходному многообразию. Всё. Больше она ничего не делает. А уж то, что её чаще всего используют для проверки целостности передаваемых данных - это дело другое😉
Почему хеш должен быть криптографическим, да ещё и посчитанным вместе с ещё одним закрытым ключом? Ведь данные с хешем все равно шифруются. Неужели возможно сгенерировать зашифрованные данные и хеш неизвестным тебе ключом, так чтобы оно совпало?
Можно расшифровать данные, используя ошибки в реализации и необходимость обеспечить поддержку устаревших алгоритмов. Вот пример таких уязвимостей - www.thesslstore.com/blog/zombie-poodle-and-goldendoodle-two-new-exploits-found-for-tls-1-2/ Если есть желание, то можно найти еще достаточно много подобных уязвимостей. Если данные можно расшифровать, то можно и зашифровать обратно измененное сообщение. Здесь и пригодится хеш, сгенерированный с использование разделяемого ключа, т.к. его подделать очень сложно.
@@AndreySozykin допустим расшифровать можно за счет уязвимостей в алгоритмах. А как обратно злоумышленник зашифрует, если у него нет ключа шифрования данных? Ведь если речь идет о подмене содержимого, значит это атака "здесь и сейчас", в процессе обмена между клиентом и сервером. Значит, соединение уже установлено и стороны обменялись общими ключами, которые злоумышленнику в данный момент неизвестны (иначе бы и МАС не спас). Стало быть, вот я перехватил, расшифровал данные из-за недостатка алгоритма, изменил эти данные и я должен их обратно зашифровать перед передачей серверу. Как я это сделаю, если у меня нет ключа для данных? Если я зашифрую абы как или вообще не зашифрую, тогда сервер не сможет расшифровать корректно, а значит моя подмена данных бесполезна.
В предыдущей лекции сказано что невозможно расшифровать ключи при передаче DH или RSA тк не знаем закрытый ключ, а в этой лекции оказывается возможно их перехватить ?
Закрытый ключ узнать можно, т.к. если что-то где-то хранится, то значит и узнать это можно. Стало быть, если предварительно сохранить перехваченные пакеты, то потом можно после получения ЗК их расшифровать. Невозможность расшифровки появляется, когда все компоненты, на основе которых генерируются общие ключи для шифровки данных и формирования mac, генерируются уникально каждый раз при установке безопасного соединения.
![Seungmin "그렇게, 천천히, 우리(As we are)" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/kAzmhLHePqU/mqdefault.jpg)
Спасибо, чудесные уроки, ваш контент уникален на youtube
Пожалуйста! Рад, что нравится!
Вот уже 2 года работаю разрабом а такого внятного объяснения еще не встречал. Спасибо
Пожалуйста! Рад, что нравится!
Спасибо вам большое за такую щедрость! Всегда люблю освежать память о сетях с вашими роликами. Спасибо!
Пожалуйста!
Спасибо за видео уроки, я просмотрел все ваши уроки во время карантина, именно такие уроки как у вас дают возможность самостоятельно изучать. Еще раз спасибо...
Пожалуйста! Успехов в изучении!
Да, Андрей всем нам очень помог! Очень-очень.
Ложился спать, в итоге просмотрел все видео по tls. Сколько раз пытался понять как оно работает, но только после ваших видео все понял. Огромное спасибо!!!
Пожалуйста! Рад, что понравилось и не дает заснуть ;-)
Спасибо большое! Все лаконично и понятно. Детализация материала прям на таком уровне, как надо!
Спасибо! Рад, что нравится!
Браво, Андрей! Худшее, что вы можете сделать - это перестать записывать лекции. Продолжайте!
Спасибо. Обязательно буду записывать!
пишу диплом, смотрю ваши видео по сетям, анализирую инфу из книг и по понемногу вношу инфу в диплом)
Чудеса чудесные!
Жму руку за потрясающий материал и объяснение 🤝🏻
Огромное спасибо, очень доступно объясняете. С нетерпением жду следующих лекций!
Пожалуйста! Лекция скоро будет!
Прекрасная лёгкая подача материала!!!
Рад, что понравилось!
Очень классные у вас видео! Огромное спасибо за ваш труд!
Ждем продолжения !!! Спачибо!
Продолжение скоро будет!
Andrey Sozykin Спасибо!
Как всегда на высоте! Ждем продолжения.
Спасибо!
Прекрасное объяснение. Спасибо
Пожалуйста!
С первого взгляда ваши видео казались какими-то серьезными и наводили на мысль, что опять ничего не пойму ))
Но нет, вы молодец, все очень доступно и главное лаконично объясняете, я в шоке) Спасибо)
Да, я стараюсь просто и понятно рассказывать о сложных вещах.
звезда в шоке!!!:))
Познавательно)
Как раз то что надо и искать нету нужды)
Спасибо)
Пожалуйста!
Спасибо за лекцию!)
Пожалуйста!
Спасибо за отличные уроки!
супер, жду следующей
Будет на следующей неделе по цифровой подписи и инфраструктуре открытых ключей.
Отличный курс)
Спасибо!
Спасибо огромное очень интересно тем более я учился на факультете компьютерные сети
Пожалуйста! Рад, что понравилось!
Дякую за корисний контент :)))))))))
Спасибо. Все понятно)
Пожалуйста!
я смотрю лайков все меньше и меньше) до конца дойдут только самые стойкие!
Андрей, спасибо за лекции!)
Так всегда бывает, это нормально!
Спасибо!)
Пожалуйста!
лучший!!!!!!!!!!!!!
Спасибо!
Спасибо
Пожалуйста!
Отличные лекции, так держать! У вас заслуженно ровно 0 дислайков!)
Спасибо!
Дизлайки не страшны, главное, просмотры!
супер подача!
Андрей, подскажите, имитовставка - это тоже самое что и соль (salt), у нас используют такой термин?
А если хакер генирирует этот ключ вместо клиента и вместо данных от сервера отдает свои данные? Тогда от такого MAC никакого толку.
Такая проблема есть, человек посередине. Именно об этом я и говорил в конце лекции. Чтобы её решить используется электронеа, подпись и сертификаты открытого ключа. Про них в следующей лекции будет.
Шифрование, MAC и сертификаты используются в TLS совместно.
👍
Подскажите, ключи шифрования и ключи для хэш - это разные ключи?
Хэш это не ключ, а математическая функция для проверки целостности передаваемых данных.
@@Daedalus6968
не так)
хэш - это мат функция сведения любого входного многообразия к фиксированному выходному многообразию. Всё. Больше она ничего не делает.
А уж то, что её чаще всего используют для проверки целостности передаваемых данных - это дело другое😉
Почему хеш должен быть криптографическим, да ещё и посчитанным вместе с ещё одним закрытым ключом? Ведь данные с хешем все равно шифруются. Неужели возможно сгенерировать зашифрованные данные и хеш неизвестным тебе ключом, так чтобы оно совпало?
Можно расшифровать данные, используя ошибки в реализации и необходимость обеспечить поддержку устаревших алгоритмов. Вот пример таких уязвимостей - www.thesslstore.com/blog/zombie-poodle-and-goldendoodle-two-new-exploits-found-for-tls-1-2/
Если есть желание, то можно найти еще достаточно много подобных уязвимостей.
Если данные можно расшифровать, то можно и зашифровать обратно измененное сообщение. Здесь и пригодится хеш, сгенерированный с использование разделяемого ключа, т.к. его подделать очень сложно.
@@AndreySozykin допустим расшифровать можно за счет уязвимостей в алгоритмах. А как обратно злоумышленник зашифрует, если у него нет ключа шифрования данных? Ведь если речь идет о подмене содержимого, значит это атака "здесь и сейчас", в процессе обмена между клиентом и сервером. Значит, соединение уже установлено и стороны обменялись общими ключами, которые злоумышленнику в данный момент неизвестны (иначе бы и МАС не спас). Стало быть, вот я перехватил, расшифровал данные из-за недостатка алгоритма, изменил эти данные и я должен их обратно зашифровать перед передачей серверу. Как я это сделаю, если у меня нет ключа для данных? Если я зашифрую абы как или вообще не зашифрую, тогда сервер не сможет расшифровать корректно, а значит моя подмена данных бесполезна.
В предыдущей лекции сказано что невозможно расшифровать ключи при передаче DH или RSA тк не знаем закрытый ключ, а в этой лекции оказывается возможно их перехватить ?
Закрытый ключ узнать можно, т.к. если что-то где-то хранится, то значит и узнать это можно. Стало быть, если предварительно сохранить перехваченные пакеты, то потом можно после получения ЗК их расшифровать. Невозможность расшифровки появляется, когда все компоненты, на основе которых генерируются общие ключи для шифровки данных и формирования mac, генерируются уникально каждый раз при установке безопасного соединения.
+Plus
Почему не сказали, сколько бит в SHA-1 ?!
Пришлось гуглить: 160 бит там
Да, 160 бит.
@@FeelUs Не надорвался?
+
Спасибо за лекцию!)
Пожалуйста!
спасибо
Пожалуйста!
+