Спасибо за видео уроки, я просмотрел все ваши уроки во время карантина, именно такие уроки как у вас дают возможность самостоятельно изучать. Еще раз спасибо...
Ложился спать, в итоге просмотрел все видео по tls. Сколько раз пытался понять как оно работает, но только после ваших видео все понял. Огромное спасибо!!!
С первого взгляда ваши видео казались какими-то серьезными и наводили на мысль, что опять ничего не пойму )) Но нет, вы молодец, все очень доступно и главное лаконично объясняете, я в шоке) Спасибо)
Такая проблема есть, человек посередине. Именно об этом я и говорил в конце лекции. Чтобы её решить используется электронеа, подпись и сертификаты открытого ключа. Про них в следующей лекции будет. Шифрование, MAC и сертификаты используются в TLS совместно.
@@Daedalus6968 не так) хэш - это мат функция сведения любого входного многообразия к фиксированному выходному многообразию. Всё. Больше она ничего не делает. А уж то, что её чаще всего используют для проверки целостности передаваемых данных - это дело другое😉
Почему хеш должен быть криптографическим, да ещё и посчитанным вместе с ещё одним закрытым ключом? Ведь данные с хешем все равно шифруются. Неужели возможно сгенерировать зашифрованные данные и хеш неизвестным тебе ключом, так чтобы оно совпало?
Можно расшифровать данные, используя ошибки в реализации и необходимость обеспечить поддержку устаревших алгоритмов. Вот пример таких уязвимостей - www.thesslstore.com/blog/zombie-poodle-and-goldendoodle-two-new-exploits-found-for-tls-1-2/ Если есть желание, то можно найти еще достаточно много подобных уязвимостей. Если данные можно расшифровать, то можно и зашифровать обратно измененное сообщение. Здесь и пригодится хеш, сгенерированный с использование разделяемого ключа, т.к. его подделать очень сложно.
@@AndreySozykin допустим расшифровать можно за счет уязвимостей в алгоритмах. А как обратно злоумышленник зашифрует, если у него нет ключа шифрования данных? Ведь если речь идет о подмене содержимого, значит это атака "здесь и сейчас", в процессе обмена между клиентом и сервером. Значит, соединение уже установлено и стороны обменялись общими ключами, которые злоумышленнику в данный момент неизвестны (иначе бы и МАС не спас). Стало быть, вот я перехватил, расшифровал данные из-за недостатка алгоритма, изменил эти данные и я должен их обратно зашифровать перед передачей серверу. Как я это сделаю, если у меня нет ключа для данных? Если я зашифрую абы как или вообще не зашифрую, тогда сервер не сможет расшифровать корректно, а значит моя подмена данных бесполезна.
В предыдущей лекции сказано что невозможно расшифровать ключи при передаче DH или RSA тк не знаем закрытый ключ, а в этой лекции оказывается возможно их перехватить ?
Закрытый ключ узнать можно, т.к. если что-то где-то хранится, то значит и узнать это можно. Стало быть, если предварительно сохранить перехваченные пакеты, то потом можно после получения ЗК их расшифровать. Невозможность расшифровки появляется, когда все компоненты, на основе которых генерируются общие ключи для шифровки данных и формирования mac, генерируются уникально каждый раз при установке безопасного соединения.
Спасибо, чудесные уроки, ваш контент уникален на youtube
Пожалуйста! Рад, что нравится!
Спасибо за видео уроки, я просмотрел все ваши уроки во время карантина, именно такие уроки как у вас дают возможность самостоятельно изучать. Еще раз спасибо...
Пожалуйста! Успехов в изучении!
Да, Андрей всем нам очень помог! Очень-очень.
Ложился спать, в итоге просмотрел все видео по tls. Сколько раз пытался понять как оно работает, но только после ваших видео все понял. Огромное спасибо!!!
Пожалуйста! Рад, что понравилось и не дает заснуть ;-)
Вот уже 2 года работаю разрабом а такого внятного объяснения еще не встречал. Спасибо
Пожалуйста! Рад, что нравится!
Спасибо вам большое за такую щедрость! Всегда люблю освежать память о сетях с вашими роликами. Спасибо!
Пожалуйста!
Браво, Андрей! Худшее, что вы можете сделать - это перестать записывать лекции. Продолжайте!
Спасибо. Обязательно буду записывать!
Дякую за корисний контент :)))))))))
Прекрасная лёгкая подача материала!!!
Рад, что понравилось!
Спасибо большое! Все лаконично и понятно. Детализация материала прям на таком уровне, как надо!
Спасибо! Рад, что нравится!
Чудеса чудесные!
Жму руку за потрясающий материал и объяснение 🤝🏻
Огромное спасибо, очень доступно объясняете. С нетерпением жду следующих лекций!
Пожалуйста! Лекция скоро будет!
Очень классные у вас видео! Огромное спасибо за ваш труд!
пишу диплом, смотрю ваши видео по сетям, анализирую инфу из книг и по понемногу вношу инфу в диплом)
Прекрасное объяснение. Спасибо
Пожалуйста!
Как всегда на высоте! Ждем продолжения.
Спасибо!
Ждем продолжения !!! Спачибо!
Продолжение скоро будет!
Andrey Sozykin Спасибо!
Спасибо за лекцию!)
Пожалуйста!
Познавательно)
Как раз то что надо и искать нету нужды)
Спасибо)
Пожалуйста!
супер, жду следующей
Будет на следующей неделе по цифровой подписи и инфраструктуре открытых ключей.
Спасибо огромное очень интересно тем более я учился на факультете компьютерные сети
Пожалуйста! Рад, что понравилось!
Отличный курс)
Спасибо!
Спасибо за отличные уроки!
лучший!!!!!!!!!!!!!
Спасибо!
С первого взгляда ваши видео казались какими-то серьезными и наводили на мысль, что опять ничего не пойму ))
Но нет, вы молодец, все очень доступно и главное лаконично объясняете, я в шоке) Спасибо)
Да, я стараюсь просто и понятно рассказывать о сложных вещах.
звезда в шоке!!!:))
Спасибо. Все понятно)
Пожалуйста!
я смотрю лайков все меньше и меньше) до конца дойдут только самые стойкие!
Андрей, спасибо за лекции!)
Так всегда бывает, это нормально!
спасибо
Пожалуйста!
Спасибо!)
Пожалуйста!
👍
супер подача!
Андрей, подскажите, имитовставка - это тоже самое что и соль (salt), у нас используют такой термин?
Отличные лекции, так держать! У вас заслуженно ровно 0 дислайков!)
Спасибо!
Дизлайки не страшны, главное, просмотры!
А если хакер генирирует этот ключ вместо клиента и вместо данных от сервера отдает свои данные? Тогда от такого 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 Не надорвался?
Спасибо за лекцию!)
Пожалуйста!
Спасибо
Пожалуйста!
+