Ваше видео про то, как достать сертификаты из трафика, как бальзам на мою душу. Я 4 дня не понимал, куда деваются сертификаты из тспдамов, пока не посмотрел и не понял, как их доставать
Поле version, в котором указана версия 1.2 устаревшее. В TLS 1.3 для указания поддерживаемых версий используется поле supported_versions. Согласно RFC 8446 The Transport Layer Security (TLS) Protocol Version 1.3, в поле version указывается версия 1.2: struct { ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ Random random; opaque legacy_session_id_echo; CipherSuite cipher_suite; uint8 legacy_compression_method = 0; Extension extensions; } Более подробное объяснение по ссылке stackoverflow.com/questions/73445222/determine-tls-version-in-wireshark
Как-то ничего не сказано про CertificateVerify от сервера (8:50), а ведь как я понял, это одно из важных изменений в TLS1.3. В TLS1.2 аутентификация сервера происходит опосредованно при получении ключа симметричного шифрования (если сертификат подлинный и проходит цепочку доверия, как мы узнаем, что он принадлежит именно тому серверу, с которым мы общаемся, а не MITM?): 1.а. в случае RSA - клиент шифрует предлагаемый ключ открытым ключом сервера из сертификата, поэтому если у сервера нет закрытого ключа, он его не расшифрует (F1.1.2 в RFC5246) 2б. в случае статического Диффи-Хеллмана, числа сервера указаны в сертификате, поэтому своё загаданное число может знать только сервер, издавший сертификат (F1.1.3 в RFC5246) 2в. в случае динамического Диффи-Хеллмана, сервер шифрует свое число Ys закрытым ключом, и расшифровать его можно только с помощью открытого ключа верного сертификата (F1.1.3 в RFC5246) Т.е. в TLS1.2 отдельного шага по аутентификации сервера нет, тогда как в TLS1.3 есть: - [пункт 2 в RFC8446] CertificateVerify: A signature over the entire handshake using the private key corresponding to the public key in the Certificate message. - [пункт 4.4.3 в RFC8446] CertificateVerify: This message is used to provide explicit proof that an endpoint possesses the private key corresponding to its certificate. The CertificateVerify message also provides integrity for the handshake up to this point. Servers MUST send this message when authenticating via a certificate.
Возник именно такой вопрос на предыдущих видео курса! Уточните, пожалуйста, правильно ли я вас понял. Через CA (Certificate Authority) сертифицируется связь домена с публичным ключом. При RSA этот ключ используется для шифрования передачи секрета от клиента к ресурсу. При эфимерном (динамическом) Диффи-Хеллмане для аутентификации (ДЕшифровании) полученного клиентом от ресурса числа Ys. Пытаюсь нагуглить, но все статьи вокруг этого момента, но о нём не получается найти! Заранее спасибо! PS: в 2014 проходил CS50 Дэвида Малана из Гарварда и кажется на аватарке гитхаба курса был кот прямо как у вас на аве, да ещё и John Harvard у вас в имени. Совпадение?)
@@KomarovPavel-if8ud Это то, что я вычленил из документов RFC. В 1.2 получается всё так. В 1.3 появился новый шаг, чтобы убедиться, что правильный сертификат нам предъявляет его владелец, а не какой-то скопировавший его жулик. Совпадение? Не думаю :) Аккаунт этот создал когда проходил тот курс (2015), с тех пор им и пользуюсь.
Здравствуйте, спасибо за курс. У меня вопрос. Почему с одним и тем же сервером, в начале идёт соединение по протоколу тлс 1.2, а потом с тем же сервером по тлс 1.3 ??? В упор не понимаю, просьба, объясните.
@@AndreySozykin давеча надо было скрапить один сайт (не сразу сообразил , что он http2). Запустил постмен и нифига. Тыркался всяко без результата и не понимал почему в браузере реквесты улетают норм , а в постмене без ответа. Оказалось, что постмен не поддерживает http2
У меня такой же вопрос возник к клиенту базы данных. Спросил у вкндоров, дали ответ: такой фичи нет, вот вам исходный код клиента, дописывайте сами перехват ключей. Так что идите с вашим вопросом к мелкософту, но с 99% вероятностью этой фичи нет
"Согласно правилам русского правописания, употребление буквы ё в большинстве случаев факультативно (т. е. необязательно)" - gramota.ru/class/istiny/istiny_7_jo
@@AndreySozykin а вот если вникнуть и посмотреть, кто эти правила и когда вводил, и для кого. Для деревянных тожероссиян это правило, трудно им знать и помнить, где ё пишется, а где нет. Для русских же вообще не проблема, ведь это их родной язык. Передохнем или передохнём?
Однако правила есть, и они общие для русского языка. Последний ваш пример полностью под эти правила подходит: если смысл слова меняется, когда ё заменяется на е, то нужно писать ё.
Тут все хорошо, таким и должен быть мой ютуб. Мне нравится. Лайк
Спасибо!
Ваше видео про то, как достать сертификаты из трафика, как бальзам на мою душу. Я 4 дня не понимал, куда деваются сертификаты из тспдамов, пока не посмотрел и не понял, как их доставать
Спасибо за Ваш труд.
Дякую за навчальний контент :)))))
Спа си бо "-)
Пожалуйста.
4:23 - у вас видео про протокол 1.3, но на этом моменте в Change Cipher Spec Protocol указана версия протокола 1.2. Как тут оказалась версия 1.2?
Поле version, в котором указана версия 1.2 устаревшее. В TLS 1.3 для указания поддерживаемых версий используется поле supported_versions.
Согласно RFC 8446 The Transport Layer Security (TLS) Protocol Version 1.3, в поле version указывается версия 1.2:
struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
opaque legacy_session_id_echo;
CipherSuite cipher_suite;
uint8 legacy_compression_method = 0;
Extension extensions;
}
Более подробное объяснение по ссылке stackoverflow.com/questions/73445222/determine-tls-version-in-wireshark
@@AndreySozykin спасибо за ответ! Понаоставляли своих легаси полей, голову морочат
Как-то ничего не сказано про CertificateVerify от сервера (8:50), а ведь как я понял, это одно из важных изменений в TLS1.3.
В TLS1.2 аутентификация сервера происходит опосредованно при получении ключа симметричного шифрования (если сертификат подлинный и проходит цепочку доверия, как мы узнаем, что он принадлежит именно тому серверу, с которым мы общаемся, а не MITM?):
1.а. в случае RSA - клиент шифрует предлагаемый ключ открытым ключом сервера из сертификата, поэтому если у сервера нет закрытого ключа, он его не расшифрует (F1.1.2 в RFC5246)
2б. в случае статического Диффи-Хеллмана, числа сервера указаны в сертификате, поэтому своё загаданное число может знать только сервер, издавший сертификат (F1.1.3 в RFC5246)
2в. в случае динамического Диффи-Хеллмана, сервер шифрует свое число Ys закрытым ключом, и расшифровать его можно только с помощью открытого ключа верного сертификата (F1.1.3 в RFC5246)
Т.е. в TLS1.2 отдельного шага по аутентификации сервера нет, тогда как в TLS1.3 есть:
- [пункт 2 в RFC8446] CertificateVerify: A signature over the entire handshake using the private key corresponding to the public key in the Certificate message.
- [пункт 4.4.3 в RFC8446] CertificateVerify: This message is used to provide explicit proof that an endpoint possesses the private key corresponding to its certificate. The CertificateVerify message also provides integrity for the handshake up to this point. Servers MUST send this message when authenticating via a certificate.
Возник именно такой вопрос на предыдущих видео курса! Уточните, пожалуйста, правильно ли я вас понял. Через CA (Certificate Authority) сертифицируется связь домена с публичным ключом. При RSA этот ключ используется для шифрования передачи секрета от клиента к ресурсу. При эфимерном (динамическом) Диффи-Хеллмане для аутентификации (ДЕшифровании) полученного клиентом от ресурса числа Ys. Пытаюсь нагуглить, но все статьи вокруг этого момента, но о нём не получается найти! Заранее спасибо! PS: в 2014 проходил CS50 Дэвида Малана из Гарварда и кажется на аватарке гитхаба курса был кот прямо как у вас на аве, да ещё и John Harvard у вас в имени. Совпадение?)
@@KomarovPavel-if8ud Это то, что я вычленил из документов RFC. В 1.2 получается всё так. В 1.3 появился новый шаг, чтобы убедиться, что правильный сертификат нам предъявляет его владелец, а не какой-то скопировавший его жулик.
Совпадение? Не думаю :)
Аккаунт этот создал когда проходил тот курс (2015), с тех пор им и пользуюсь.
@@johnharvard6608 хах даже год почти тот же! бывают же совпадения) ну надеюсь это на удачу 😉
Здравствуйте, спасибо за курс. У меня вопрос. Почему с одним и тем же сервером, в начале идёт соединение по протоколу тлс 1.2, а потом с тем же сервером по тлс 1.3 ??? В упор не понимаю, просьба, объясните.
Всё видео происходит подключение только по 1.3, нигде нет 1.2
Добрый вечер. Лекция про DNS over TLS планируется?
Да, и про DNS over HTTPS.
круто было бы так ещё ipsec показать...
А могли бы сделать аналогичный обзор для http2?
По HTTP2 будет после HTTPS. Уже скоро.
@@AndreySozykin давеча надо было скрапить один сайт (не сразу сообразил , что он http2). Запустил постмен и нифига. Тыркался всяко без результата и не понимал почему в браузере реквесты улетают норм , а в постмене без ответа. Оказалось, что постмен не поддерживает http2
не хочет он сертификат расшифрованный показывать все application data
Спасибо за ролик, Андрей, а если будет не браузер клиентом а например рдп клиент , то как подсунуть ключи вайершарку?
У меня такой же вопрос возник к клиенту базы данных. Спросил у вкндоров, дали ответ: такой фичи нет, вот вам исходный код клиента, дописывайте сами перехват ключей. Так что идите с вашим вопросом к мелкософту, но с 99% вероятностью этой фичи нет
Для гостей с гор - защищЁнные 🤣
Сложно спорить с ценителями буквы ё 😉
@@AndreySozykin почему ценители? Просто русский человек 😁
"Согласно правилам русского правописания, употребление буквы ё в большинстве случаев факультативно (т. е. необязательно)" - gramota.ru/class/istiny/istiny_7_jo
@@AndreySozykin а вот если вникнуть и посмотреть, кто эти правила и когда вводил, и для кого. Для деревянных тожероссиян это правило, трудно им знать и помнить, где ё пишется, а где нет. Для русских же вообще не проблема, ведь это их родной язык. Передохнем или передохнём?
Однако правила есть, и они общие для русского языка.
Последний ваш пример полностью под эти правила подходит: если смысл слова меняется, когда ё заменяется на е, то нужно писать ё.