@@AndreySozykin Андрей!!! Конструктивныя критика. Очень непонятный выпуск! Не согласуется с предыдущим выпуском! 1. Не показана передача p,g Ys, Yc!! 2. Не показана передача Session_ID в Server Hello! 3. В Server/Client Key Exchange непонятно значение ключей и зашифрованного чего-то в контексте прошлого выпуска!! Огромная просьба переработать эти выпуски в новом курсе!☝🏼 Даю наводку: если в практическом выпуске с WiredShark планируете показывать определенный набор шифров, то как минимум именно о них (шифрах) и их параметрах и надо рассказывать на предыдущем уроке. Как минимум. Тогда текущий урок будет согласован с предыдущим.
Не увидел, чтобы в ServerKeyExchange передавались параметры g и p. Также, странно, что и клиент и сервер каждый раз отправляют друг другу новые client_random и server_random, даже при возобновлении сессии, и поэтому не понятно, по какому параметру сервер определяет, что нужно возобновить сессию. Клиент также каждый раз отправляет разный SessionID. Предполагаю, что клиент и сервер после установки защищенного соединения договариваются о новых client_random, и sessionID, которые клиент сможет использовать при возобновлении сессии.
В таймлайне 08:35 рассматривается сообщение с сертификатом и в частности данные сертификата Let'sEncrypt. Там есть поля Certificate->signedCertificate->signature = sha256WithRSAEncryption Certificate->signedCertificate->subjectPublicKeyInfo->algoritm= rsaEncryption Правильно я понимаю, что 1е значение показывает алгоритм подписи (sha+rsa) текущего сертификата корневым сертификатом? А второе значение показывает, каким алгоритмом сгенерирован публичный ключ? Спасибо!
в прошлом видео вы говорили что сервер передаёт Session ID по которому потом и восстанавливается соединение, но во первых, Session ID передаёт клиент почему-то, а так же восстановление сессии идёт через ticked я думал что id сессии и определяет саму сессию. или я ошибаюсь?
Жаль, что к предыдущему видео закрыты комментарии. Почитать бы, что к чему, т.к. тема про установку соединения в видео не до конца освещена. Например, не совсем понятно, в каких вычислениях используются client_random и server_random, только ясно, что они защищают от повторной передачи злоумышленником клиенту заранее перехваченных зашифрованных настоящим сервером сообщений. Про динамический диффи-хелман не рассказано, потому как в нём ещё принимает участие закрытый ключ сертификата. Также ошибочно было сказано про то, что клиент может быть уверен в том, что подключился к тому серверу, к которому хочет, сразу же после проверки сертификата. На самом деле, клиент может быть в этом убежден только после того, как проверит зашифрованное сервером сообщение FINISHED. Тема установки соединения на самом деле сложная, до сих пор не могу до конца запомнить, как всё таки на самом деле происходит установка соединения, постоянно забываю.
Вот, что нашёл в одной из статье (ещё пол года назад): "Чтобы провести аутентификацию, сервер берёт случайные числа клиента (client_random) и сервера (server_random), а также параметр DH, который будет использоваться для вычисления сеансового ключа, и шифрует их с помощью своего закрытого ключа. Результат будет выполнять роль цифровой подписи: клиент использует открытый ключ для проверки подписи и того, что сервер является законным владельцем пары ключей, и ответит своим собственным параметром DH." Под параметром DH имеется в виду тот параметр, который был вычислен по формуле g^k mod p, где k - простое секретное число сервера/клиента. На видео они называются, как Yc (вычислен клиентом) и Ys (вычислен сервером). Чтобы убедить клиента, что параметр Ys вычислен владельцем сертификата, а не мошенником по середине, он шифрует его с помощью закрытого ключа, тем самым образуя цифровую подпись, которую позже клиент проверяет открытым ключом сертификата. Эта цифровая подпись добавляется к сообщению ServerKeyExchange. Также выше было написано, что помимо параметра DH были зашифрованы client_random и server_random. Возможно это для того, чтобы данный параметр был привязан к текущей сессии и его нельзя было использовать в другой сессии, т.е. чтобы мошенник не смог повторно выслать клиенту перехваченный параметр DH.
Пожалуйста! К сожалению, я не очень хорошо разбираюсь, что делает тестировщик. Кроме того, тестирование бывает очень разным. Что именно тестируете: графический интерфейс, API? Какой тип приложения: web, мобильное, десктоп? Используется ли база данных?
Андрюш помоги, у меня гугл ак ограниченный. Знакомый дал, все привязки снял, все равно коды на его тел идут. Не знаю к кому обратиться, и в гугл некуда писать😐
Здравствуйте. Спасибо большое за видео. Возник вопрос: "Как динамический Диффи-Хелман обеспечивает защиту от человека по середине, ведь если я правильно понял, то обмен ключами в этом случае вроде никак не зависит от того, что прописано в сертификате?" Злоумышленник может отправить клиенту настоящий сертификат сервера и обменяться с ним ключами на основе динамического Диффи-Хелмана, но при этом клиент будет думать, что обменялся ключами с настоящим сервером.
тоже не понял этого. ты разобрался?:) более того, добавлю к твоему: дядька в срединке может динамически обменяться как с клиентом (это ты указал) так и с сервером. и будет: с клиентом симметричное шифрование по одному ключу, а с сервером - по другому. мы что-то упускаем.
@@hunter-speexz посмотрю остальные комментарии) еще не все посмотрел. скажи:) как у тебя сложилась судьба знаний из этого видео курса по сетям?) пригодилось для собеса/работы или просто для себя изучал?
![[ TEASER ] เงาะป่า - วงL.กฮ. | TMG RECORD](http://i.ytimg.com/vi/M4ObdFfcPww/mqdefault.jpg)
Да, очень интересная тема. Давно хотел в этом разобраться, но как-то до книг не добраться. Ваши видео - то, что надо. Спасибо!!!
Пожалуйста. Рад, что понравилось!
Спасибо за проделанную работу. Очень полезно! Ждем ещё
Пожалуйста!
Дякую за корисний контент :))))))))))))))))))
Огромное спасибо, ваши видео лучшие! Сразу все понятно!
Пожалуйста! Рад, что удалось понятно объяснить.
@@AndreySozykin
Андрей!!! Конструктивныя критика. Очень непонятный выпуск! Не согласуется с предыдущим выпуском!
1. Не показана передача p,g Ys, Yc!!
2. Не показана передача Session_ID в Server Hello!
3. В Server/Client Key Exchange непонятно значение ключей и зашифрованного чего-то в контексте прошлого выпуска!!
Огромная просьба переработать эти выпуски в новом курсе!☝🏼
Даю наводку: если в практическом выпуске с WiredShark планируете показывать определенный набор шифров, то как минимум именно о них (шифрах) и их параметрах и надо рассказывать на предыдущем уроке. Как минимум. Тогда текущий урок будет согласован с предыдущим.
Огромное спасибо! 🥳
Здоровья и счастья вам и вашей семье 🤝🏻
Ждём следующее видео!
Надеюсь, будет скоро. С этим видео сильно задержался.
Спасибо за видео. Давно его ждали.
Пожалуйста! Да, давно не делал видео.
Все четко , спасибо
Огромное спасибо! Очень классно, просто и доходчиво. А самое важное с кучей деталей!
Спасибо тебе! Отличный курс!
Пожалуйста!
О спасибо! Как раз есть задачка о неудачном соединению с сайтом...
Пожалуйста! Успехов!
Супер!
Спасибо!
Супер.
Спасибо за видео
О, уже соединение идёт по tls 1.3 :)
Прогресс!
Установка соединения преодолена =D
спасибо
Пожалуйста!
Когда планируются следующие видео по расшифровки? PS. Огромное спасибо, материал то что нужно!
Видео по расшифровке будет завтра. Уже записал, монтирую.
Не увидел, чтобы в ServerKeyExchange передавались параметры g и p. Также, странно, что и клиент и сервер каждый раз отправляют друг другу новые client_random и server_random, даже при возобновлении сессии, и поэтому не понятно, по какому параметру сервер определяет, что нужно возобновить сессию. Клиент также каждый раз отправляет разный SessionID. Предполагаю, что клиент и сервер после установки защищенного соединения договариваются о новых client_random, и sessionID, которые клиент сможет использовать при возобновлении сессии.
это самое подробное объяснение по TLS на русском. Я удивлен, почему так мало лайков...
Клас)
Спасибо!
В таймлайне 08:35 рассматривается сообщение с сертификатом и в частности данные сертификата Let'sEncrypt. Там есть поля
Certificate->signedCertificate->signature = sha256WithRSAEncryption
Certificate->signedCertificate->subjectPublicKeyInfo->algoritm= rsaEncryption
Правильно я понимаю, что 1е значение показывает алгоритм подписи (sha+rsa) текущего сертификата корневым сертификатом?
А второе значение показывает, каким алгоритмом сгенерирован публичный ключ?
Спасибо!
так вы из урфу, сколько раз был там, никогда не видел) слишком большой университет!
Да, из УрФУ, с радиофака.
4:49 получается, атакующий может немного упростить себе задачу, изменив этот запрос, оставив в нем только слабые методы шифрования?
в прошлом видео вы говорили что сервер передаёт Session ID по которому потом и восстанавливается соединение, но во первых, Session ID передаёт клиент почему-то, а так же восстановление сессии идёт через ticked я думал что id сессии и определяет саму сессию. или я ошибаюсь?
Жаль, что к предыдущему видео закрыты комментарии. Почитать бы, что к чему, т.к. тема про установку соединения в видео не до конца освещена. Например, не совсем понятно, в каких вычислениях используются client_random и server_random, только ясно, что они защищают от повторной передачи злоумышленником клиенту заранее перехваченных зашифрованных настоящим сервером сообщений. Про динамический диффи-хелман не рассказано, потому как в нём ещё принимает участие закрытый ключ сертификата. Также ошибочно было сказано про то, что клиент может быть уверен в том, что подключился к тому серверу, к которому хочет, сразу же после проверки сертификата. На самом деле, клиент может быть в этом убежден только после того, как проверит зашифрованное сервером сообщение FINISHED.
Тема установки соединения на самом деле сложная, до сих пор не могу до конца запомнить, как всё таки на самом деле происходит установка соединения, постоянно забываю.
Вот, что нашёл в одной из статье (ещё пол года назад):
"Чтобы провести аутентификацию, сервер берёт случайные числа клиента (client_random) и сервера (server_random), а также параметр DH, который будет использоваться для вычисления сеансового ключа, и шифрует их с помощью своего закрытого ключа. Результат будет выполнять роль цифровой подписи: клиент использует открытый ключ для проверки подписи и того, что сервер является законным владельцем пары ключей, и ответит своим собственным параметром DH."
Под параметром DH имеется в виду тот параметр, который был вычислен по формуле g^k mod p, где k - простое секретное число сервера/клиента. На видео они называются, как Yc (вычислен клиентом) и Ys (вычислен сервером).
Чтобы убедить клиента, что параметр Ys вычислен владельцем сертификата, а не мошенником по середине, он шифрует его с помощью закрытого ключа, тем самым образуя цифровую подпись, которую позже клиент проверяет открытым ключом сертификата. Эта цифровая подпись добавляется к сообщению ServerKeyExchange.
Также выше было написано, что помимо параметра DH были зашифрованы client_random и server_random. Возможно это для того, чтобы данный параметр был привязан к текущей сессии и его нельзя было использовать в другой сессии, т.е. чтобы мошенник не смог повторно выслать клиенту перехваченный параметр DH.
@@hunter-speexz Спасибо за разъяснение.)
Спасибо за ваше видео ,скажите пожалуйста я начал курс тестировщика на какие видео уроки мне особенно стоит обратить внимание как тестировщик.
Пожалуйста!
К сожалению, я не очень хорошо разбираюсь, что делает тестировщик. Кроме того, тестирование бывает очень разным. Что именно тестируете: графический интерфейс, API? Какой тип приложения: web, мобильное, десктоп? Используется ли база данных?
@@AndreySozykin понятно спасибо .
Добрый день. Спасибо за контент.
На каких фреймврках и технологиях работает сервер?
Имеется в виду мой веб-сервер? Если да, то на Tilda :-)
@@AndreySozykin
почему закрыты комы к предыдущему видео? всё-таки оно очень сложное, есть что обсудить.
Андрюш помоги, у меня гугл ак ограниченный. Знакомый дал, все привязки снял, все равно коды на его тел идут. Не знаю к кому обратиться, и в гугл некуда писать😐
Здравствуйте. Спасибо большое за видео. Возник вопрос: "Как динамический Диффи-Хелман обеспечивает защиту от человека по середине, ведь если я правильно понял, то обмен ключами в этом случае вроде никак не зависит от того, что прописано в сертификате?" Злоумышленник может отправить клиенту настоящий сертификат сервера и обменяться с ним ключами на основе динамического Диффи-Хелмана, но при этом клиент будет думать, что обменялся ключами с настоящим сервером.
тоже не понял этого.
ты разобрался?:)
более того, добавлю к твоему: дядька в срединке может динамически обменяться как с клиентом (это ты указал) так и с сервером. и будет: с клиентом симметричное шифрование по одному ключу, а с сервером - по другому.
мы что-то упускаем.
@@manOfPlanetEarth вроде разобрался, но уже забыл. Вроде где-то среди комментариев оставлял ответ.
@@hunter-speexz
посмотрю остальные комментарии) еще не все посмотрел.
скажи:) как у тебя сложилась судьба знаний из этого видео курса по сетям?) пригодилось для собеса/работы или просто для себя изучал?
А где хранится эти ticket? И на сервере и клиенте , можно ли посмотреть какие есть тикеты в системе
такой же вопрос
+Plus
Я пинганул твой сайт через консоль, было 4 попытки и 4 раза превышено время ожидания, ты что поменял IP?