34:10 По HTTPS немного не точно, но допустимо для обьяснения. Симетричный (сессионный) ключ не пересылается зашифрованым асиметрично - как раньше (давным давно - очень давно - в 2015 уже так не делали.), он генерируется из определенных данных, с обеих сторон пересылаемых во время соединения TLS/SSL, по протоколу Диффи-Хелмана. Cервер не проверяет клиента, клиент проверяет сервер, или наоборот, сертификат служит для идентификации и аутентичности сервера. Сеансовый ключ не шифруется ассиметричной криптой.
Спасибо. У Вас без сомнения дар чисто и просто объяснять. До Вас всё слушала только на английском. Так что Вы лучший на рускоязычном пространстве. При работе с Сервером Сертификации, сертификатами и шифрованием имела непонятные нюансы, которые делала на автомате. У Вас же получила разъяснение. Приятно также, что Вы доброжелательны и незаносчивы. Только один момент - Вы не знаете, как правильно произносить английские слова. Режет ухо. Это вечная проблема для российских IT-специалистов. Прослушайте американцев/англичан. Спасибо за Ваши старания.
вот уж неправда. в большинстве случаев он всё правильно произносит, и сильно выбивающегося ничего нет. ну может совсем иногда. бывает в десятки раз хуже. здесь все относительно неплохо.
хорошо изложен материал по цифровой подписи. Что касается SSL есть недопонимание которое может ввести в заблуждение или привести к вопросу что задавал "webdeveloper" ниже (Возможно скорее всего ето я чего то не понял). Поетому на счет SSL советую прочесть еще какую то литературу. Google вам поможет. Автору огромное спасибо продолжай. Хотелось еще чтобы автор поделился опытом работы в администрировании баз даных. Ну карты ему в руки, и ещераз спасибо за его роботу.
Все понятно и просто супер. А как на никсах все Например если свой внутрикорпаративный сервис подымем и самоподписной ключ на него повесим и пользователям генерить для входа Тулкит интересно было бы посмотреть
24:20 что мешает тому же злодею подделать всю цепочку вышестоящих сертификатов в т.ч. рута? Или как вообще убедиться что РУТ сертификат это подлинный РУТ сертификат?
И в цепочке сертификатов имена центров сертификации не совпадают. Issued by видимо тут используется не просто имя, а какой-то уникальный идентификатор ?
"самый главный плюс ассим - что не надо передавать ключ по сети". Ну так и при симметр если не передавать то будет все ок. Дело то не в этом, а в том что нам надо попасть в ситуацию когда на обоих концах будет возможность шифровать/дешифровать не пересылая ключ по сети с этого надо начинать.
не пересылая ключ по сети - это по телефону звонить что-ли?) ассиметричное шифрование как раз позволяет передавать открытый ключ по сети, при этом сам ключ не компрометируется, так как расшифровать без закрытого ключа (который никуда не передается) все равно ничего не получится
Еще на счет EFS, когда закончится срок действия сертификата, то мы потеряем доступ к данным? Менять время на ПК назад? )) Или надо успеть убрать шифрование и перешифровать заново, чтобы выпустился новый сертификат?
Есть неясность : когда шифруем файл 2.txt (59:35) Вы говорите, что он зашифрован симметричным ключом, а симметричный зашифрован закрытым ключом. Затем, когда мы экспортируем сертификат, мы зачем-то экспортируем закрытый ключ. Но ведь закрытым нельзя расшифровать то, что было зашифровано закрытым (1:01:50) ... Еще непонятно зачем шифровать симметричным, а потом асимметричным, когда можно использовать только асимметричный (а где тогда лежит ключ от симметричного шифрования? )
Действительно, это ошибка в видео. Симметричный ключ шифруется открытым ключем. Вот схемка: upload.wikimedia.org/wikipedia/commons/thumb/a/a6/EFS_operation_scheme.png/400px-EFS_operation_scheme.png По второму вопросу, отвечал еще в видео. Асимметричное шифрование требует намного больше вычислительных ресурсов, нежели симметричное шифрование, поэтому даже SSL/TLS (например HTTPS) асимметрично шифруют только симметричный ключ, но не сами данные.
Не очень понял у нас есть рутовый центр сертифиаций и он отдает свой откртый ключ другому центру сертификаций что бы он был доверенным? и получается если человек хочет проверить действительный ли этот сертификат он его отравить для его проверки в рутовый центр сертификаций или как?
Чтобы CA стал доверенным, рутовый CA подписывает серт дочернего CA закрытой частью своего ключа. Далее любой человек может проверить доверенность дочернего CA путем проверки подписи открытым ключем рутового CA.
8:25 - Действительно не ясно откуда у второго пользователя ключ для расшифровки и что это за ключ - публичный? Выходит любой может открыть это сообщение. Я думаю механизм хорошо описан здесь: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-NmM9HA2MQGI.html (дискламер - это на английском.) 12:56 Получается цифровая подпись только проверяет не было ли изменено сообщение и не было ли оно подменено кем-то, но само сообщение она не защищает.
1. ключ для расшифровки уже есть у пользователя (закрытый ключ). пользователь передает открытый ключ тому, кому нужно что-то зашифровать, данные шифруются открытым ключем и далее могут быть открыты только пользователем с закрытым ключем. то есть для шифрования, отправитель сначала получает открытый ключ адресата. 2. все верно, она только покажет если сообщение изменилось при передаче
16:39 Сертификат + открытый ключ в нем, передается в структуре эцп, получатель не запрашищает ключ у сервера, клиент (почта, ворд, адоби) извлекает сертификат проверяет его на валидность делает проверки касающиеся сетртификата, потом извлекает из сертификата открытый ключ, обрабатывает сообщение получает хэш сообщения/файла, расшифровывает открытым ключем зашифрованный отправителем на его закрытом ключе хэш в структуре эцп, сравнивает хэши с тем что получил ранее с сообщения или файла, если хэши совпадают валидность сообщения/файла подтверждается, если нет то сообщение/файл былo скомпрометированно и, сообщение/файл было изменено по дороге, и не проходит валидацию по эцп. Таким образом понятно, было-ли сообщение/файл скомпрометированно/н.
Добрый день. Как ситуация на текущий мент с актуальной областью администрирования. Я смотрю в сторону системного архитектора и виртуализации. Как на Ваш взгляд это перспективно или лучше пересмотреть направление? Спасибо за урок.
Добрый! Лично я бы пошел в разработку, если бы мог выбрать вновь :) ИМХО, через 15-20 лет 95% администрирования тупо уйдет в облака, которые будут админить привязанные к вендору специалисты. Хотя сейчас проблем с трудоустройством нет (по крайней мере в мск)
@@TrainITHard Я как раз начал с Java, но администрирование показалось проще и понимания побольше изначально, поэтому временно переключился. Т.е. Java, PYTON и например С# перспективнее на Ваш взгляд?
@@TrainITHard ну и отпугнуло в программировании вероятность стать "аутистом", все таки у админов задач побольше и разнообразные. Сам по последним размышлениям думал двигать в сторону системного архитектора.
@@tyyyyuuuuuuuuijjjiio по программированию ничего не знаю, поэтому не подскажу :) по поводу задач, очень сомневаюсь, что у админов их больше и они разнообразнее.
Публичный ключ формируется на основе приватного (по крайней мере в openssl). Если это не математическое соотношение, то что это? И сомнительно, что публичным ключом можно расшифровать сообщение, зашифрованное приватным ключом. Что же это получается? У всех есть публичный ключ сервера (на то он и публичный), и все (включая ФСБ) могут расшифровать то, что сервер шифрует приватным ключом и шлет исключительно Маше? Хуйня собачья. Публичный ключ используется только для шифрования. Далее только сервер может расшифровать это своим приватным ключом. И насколько я успел разобраться (отнюдь не благодаря этому видео), так браузер передает симметричный сессионный ключ, который он сгенерировал, и который будет использован в дальнейшем уже симметричном шифровании, т.к. асимметричное слишком вычислительно-затратное. Хотелось бы узнать, как работает сертификат, с помощью которого браузер убеждается, что человек посередине не подменил публичный ключ сервера, но, что-то подсказывает мне, что в этом говно-видео это вряд ли освещается.
Тогда какая тут безопасность, если открытый ключ может расшифровать то, что зашифровано закрытым? Ладно, вопрос безопасности пока не важно, потом сам разберусь, почитав что-нибудь)
TrainIT Hard, вот тут момент объясните, плиз. Получается мы шифруем хэш закрытым ключем и отправляем. Хакер это перехватывает. Он сможет закрытый ключ извлечь из этого и потом перехватить и открытый, который свободно гуляет и расшифровывать вообще что угодно у этого пользователя?
Все, что нужно знать - SSL это древний протокол и сейчас почти нигде не используется. Все что сейчас называют SSL, на самом деле является TLS в 99% случаев.
Стоп! Я ещё смотрю видео. насчет цифровой подписи. как же пользователи узнаёт, что открытый ключ, который у него имеется, действительно принадлежит тому, Чьи данные он хотел бы получить?
Потому что, если он попытается расшифровать подпись чужим открытым ключом, у него ничего не выйдет, так как пара открытый-закрытый ключ математически взаимосвязана.
Никак, если не выпускать сертификат с помощью публичного платного центра сертификации. Цвет строки определяет браузер в зависимости от сертификата. Сам сертификат верифицируется публичными ЦС разными способами: например можно только валидировать домен по почте в этом домене - тогда ни о какой зеленой строке речи не будет, а можно валидировать домен и организацию, предоставив бухгалтерские документы - это уже расширеная валидация и такой сертификат будет показан зеленым. Погуглите услуги extended validation certificate у публичных ЦС.
TrainIT Hard я помню что нужно поди создать политику в AD CS а потом в меню Extended Validation их добавить, делаем для EV Subordinate CA во все шаблоны политику и доп.поля и готово!
Я бы даже и 4 кб ключ посоветовал, различие в том, что ясно понятно что RSA-1024 не защищен, но для поиска ключа 2048 бит нужно найти 2 пары открытых и закрытых, а для поиска 4096 бит, тут уже будет очень не сильно просто, в рекомендации ECC-521 и DES-1024
EV никогда не делал - зачем он, если серт непубличный? :) По ключу можно и 4096, только не забываем про обратную совместимость - например старые циски не умели в ключи длиннее 2048.
