Тут возник небольшой конфуз. Реверсер для ретро нужен был в GOG, куда пробовал устроиться я, а DrMefistO рассказывает об опыте собеседования на реверсера в Wargaming, там про ботов и античиты.
Меня в общем даже не рассматривали, просто присылали письмо с отказом в ответ на резюме) Но в это есть смысл потому что у меня нет профессионального опыта ни в реверсе ни в геймдеве в целом, сюда же необходимось релокации и оформления для кандидата который явно не стоит того.
Нет, это был блог big evil corporation. Там парень параллельно с блогом делал игру под сегу. Сейчас ради интереса проверил, летом он её доделал, вроде как даже на картриджах выходила.
Приятно увидеть, так сказать, земляка, да ещё и со схожими интересами. Хотя я относительно недавно заинтересовался реверсом, это была моя борьба с прокрастинацией на работе, тогда начал практиковаться на простеньких crackme, потом пробовал писать кейген к Adobe Audition 1.5 (неудачно), потом пробовал в программирование и отладку под Sega Mega Drive (чуть более удачно), и в конце концов занялся портом одной досовской игрушки.
Интересно насчёт первой работы вирусным аналитиком, уж не ВирусБлокАда ли?) Пожалуй из тех мест где в нашей стране ищут реверс-иженеров я знаю только её и CheckPoint.
Раскрывал тему сжатия Хаффмана в одной из своих статей по реверс-инжинирингу досовской игры. С разбором реализации оригинального сжатия на ассемблере и декодера на С. Там этот алгоритм (несколько модифицированный) активно применялся для сжатия ресурсов.
Гуманитарии пришедшие в программирование почему-то очень любят рассказывать всем о том КАК они пришли в программирование, чем, собственно, о самом программирование. И чуть ли не в каждом случае это прям такая тирада о превозмогании. Это действительно похоже на курильщика, который пытается выделиться, перед никогда особо не курящими, тем, что бросил, вызывая всеобщее недоумение, ведь можно было и не начинать. Иными словами, всем плевать на то, что ты гуманитарий, важно лишь насколько ты хорош в деле.
Внедрение вредоносного приложения на доверенный сервер — это совсем другая угроза, не связанная с PKI в принципе. Но тут признаю свою ошибку, действительно аутентификация приложения на сервере это о другом.
Про «автоматически» мы по-моему уже решили, доверие любым клиентским сертификатам, кем бы они не были подписаны, ДОЛЖНО проверятся, если это не так, то проблема не в PKI как таковой, а в её некорректной реализации.
Разработчик в состоянии гарантировать возмещение ущерба, если таковой был. Это вполне себе организационная мера защищающая клиента.
Эти фразы идентичны. Для построения безопасного канала связи между клиентом (браузером) и приложением используем TLS. Перед установкой шифрованного канала приложение должно аутентифицироваться перед браузером, таким образом клиент может удостоверится в том, что приложение именно то за кого себя выдаёт. Аутентификацию мы проводим с помощью сертификатов открытого ключа. Приложение отправляет браузеру свой сертификат, подписанный неким доверенным сертификатом УЦ, клиент принимает сертификат, и проверяет подпись при помощи открытого ключа доверенного УЦ (я опускаю цепочки сертификатов). Успешная проверка подписи означает, что владелец присланного сертификата и есть приложение. Приложение подтвердило свою подлинность, после этого стороны могу переходить к установке шифрованного канала.
Замени TLS на IPsec, и принципиально ничего не изменится.
Другой разговор. Тут на товарищ доказывает что PKI на X.509 сломано в принципе. X.509 вполне себе позволяет сделать всё достаточно безопасно, но так как X.509 это, строго говоря, не стандарт, то реализации плавают. И это, увы, проблемы реализации.
Электронная подпись это криптографический примитив, как и симметричное шифрование. А TLS это криптографический протокол который, в том числе, применяет ЭЦП, аутентифицируя стороны.
Вот скажите, можно ли сделать так, чтобы элемент списка корневых сертификатов применялся только к одной конкретной программе?
Можно. Вариант первый — я сам владелец УЦ обслуживающего только одно моё приложение. Вариант второй, для сертификатов УЦ разрешено специальное расширение Name Constrains, которое ограничивает пространство имён дочерних сертификатов.
А про «завладевание» секретным ключом УЦ, так это совсем другая угроза, и для её устранения применяются совсем другие, комплексные методы, в том числе и упомянутое лицензионное соглашение. Программа может и не идеальна, но все риски я беру на себя.
Вы говорите немного о другом. То что другое приложение может нанести вам вред либо никак, либо очень косвенно связано с доверием центру сертификации. Мы здесь говорим о «доверии» не в том смысле, что программы не сделают вам ничего плохого, а в том, что эта программа именно та за кого себя выдаёт, и если по задумке автора она должна вам навредить, то, безусловно, так и будет.
И опять же, не путайтесь в терминологии, в контексте PKI вы автоматически доверяете только корневому сертификату, доверие к дочерним сертификатам всякий раз проверяется когда вы устанавливаете соединение.
Не нужно строить теорию заговора, кто-то где-то собрался, что-то за кого-то порешал, о чём ты вообще? Очень часто УЦ представляют собой нормальные такие государственные структуры. С работниками, кабинетами и бюрократией.
И вот я например выпустил приложение. И моё приложение должно аутентифицироваться перед твоим браузером с помощью SSL сертификата. И я такой прихожу в УЦ в своём городе, то есть прям физически прихожу, ногами. Пишу заявление, мне выпускают сертификат. Я, как разработчик, доверяю этому УЦ, просто потому что я там был, всё там видел. И я говорю своим пользователям, что если вы хотите пользоваться моим приложением, то подгрузите себе сертификат этого УЦ, потому что Я, РАЗРАБОТЧИК, ЕМУ ДОВЕРЯЮ. А ТЫ, ПОЛЬЗОВАТЕЛЬ, доверяй мне, или не пользуйся моим приложением. Так в чём твоя проблема?
1. На основании чего я этим товарищам доверяю? Я с ними на брудершафт не пил. Об их репутации мне неизвестно ровным счётом ничего.
Ты доверяешь не им, ты доверяешь мне/разработчику. У меня это прописано в лицензионном соглашении.
2. Как так получилось, что я принужден им доверять?
Не принуждён — не доверяешь, не пользуйся приложением.
3. Кто гарантирует, что это моё безоговорочное доверие не станет для меня источником серьёзных проблем? И, главное, чем это гарантировано?
Я/разработчик тебе это гарантирую. Опять же, лицензионное соглашение. Если я его нарушу — можешь меня засудить.
Я спецом для тебя частично процитирую RFC 5280 п.6.1 который определяет всю процедуру:
6.1. Basic Path Validation
6.1.1. Inputs
…
(d) trust anchor information, describing a CA that serves as a trust anchor for the certification path…
В данном случае trust anchor-ами являются все твои 274 корневых сертификата. Это просто Inputs, то бишь входные данные. Ты просто берёшь чей-то самоподписанный корневик и называешь его доверенным.
Да ты даже сам можешь выпустить себе самоподписанный сертификат и подгрузить его в браузер, и всё, для тебя он станет доверенным. Можешь раздать его своим друзьям, и для них он тоже станет доверенным. Вот и вся история.
Это основы. Смотри стандарт X.509, раздел про верификацию маршрута сертификации. Прикол в том что доверенный корневой сертификат, он же trusted anchor выбирается произвольно. Это просто исходные данные.
Если по-простому, то переписывать и распространять код можно, ресурсы — нельзя, т.к. они, зачастую, лицензируется.
Меня в общем даже не рассматривали, просто присылали письмо с отказом в ответ на резюме) Но в это есть смысл потому что у меня нет профессионального опыта ни в реверсе ни в геймдеве в целом, сюда же необходимось релокации и оформления для кандидата который явно не стоит того.
Нет, это был блог big evil corporation. Там парень параллельно с блогом делал игру под сегу. Сейчас ради интереса проверил, летом он её доделал, вроде как даже на картриджах выходила.
Интересно насчёт первой работы вирусным аналитиком, уж не ВирусБлокАда ли?) Пожалуй из тех мест где в нашей стране ищут реверс-иженеров я знаю только её и CheckPoint.
Гуманитарии пришедшие в программирование почему-то очень любят рассказывать всем о том КАК они пришли в программирование, чем, собственно, о самом программирование. И чуть ли не в каждом случае это прям такая тирада о превозмогании. Это действительно похоже на курильщика, который пытается выделиться, перед никогда особо не курящими, тем, что бросил, вызывая всеобщее недоумение, ведь можно было и не начинать. Иными словами, всем плевать на то, что ты гуманитарий, важно лишь насколько ты хорош в деле.
Про «автоматически» мы по-моему уже решили, доверие любым клиентским сертификатам, кем бы они не были подписаны, ДОЛЖНО проверятся, если это не так, то проблема не в PKI как таковой, а в её некорректной реализации.
Разработчик в состоянии гарантировать возмещение ущерба, если таковой был. Это вполне себе организационная мера защищающая клиента.
Замени TLS на IPsec, и принципиально ничего не изменится.
Можно. Вариант первый — я сам владелец УЦ обслуживающего только одно моё приложение. Вариант второй, для сертификатов УЦ разрешено специальное расширение Name Constrains, которое ограничивает пространство имён дочерних сертификатов.
А про «завладевание» секретным ключом УЦ, так это совсем другая угроза, и для её устранения применяются совсем другие, комплексные методы, в том числе и упомянутое лицензионное соглашение. Программа может и не идеальна, но все риски я беру на себя.
И опять же, не путайтесь в терминологии, в контексте PKI вы автоматически доверяете только корневому сертификату, доверие к дочерним сертификатам всякий раз проверяется когда вы устанавливаете соединение.
Не нужно строить теорию заговора, кто-то где-то собрался, что-то за кого-то порешал, о чём ты вообще? Очень часто УЦ представляют собой нормальные такие государственные структуры. С работниками, кабинетами и бюрократией.
И вот я например выпустил приложение. И моё приложение должно аутентифицироваться перед твоим браузером с помощью SSL сертификата. И я такой прихожу в УЦ в своём городе, то есть прям физически прихожу, ногами. Пишу заявление, мне выпускают сертификат. Я, как разработчик, доверяю этому УЦ, просто потому что я там был, всё там видел. И я говорю своим пользователям, что если вы хотите пользоваться моим приложением, то подгрузите себе сертификат этого УЦ, потому что Я, РАЗРАБОТЧИК, ЕМУ ДОВЕРЯЮ. А ТЫ, ПОЛЬЗОВАТЕЛЬ, доверяй мне, или не пользуйся моим приложением. Так в чём твоя проблема?
Ты доверяешь не им, ты доверяешь мне/разработчику. У меня это прописано в лицензионном соглашении.
Не принуждён — не доверяешь, не пользуйся приложением.
Я/разработчик тебе это гарантирую. Опять же, лицензионное соглашение. Если я его нарушу — можешь меня засудить.
В данном случае trust anchor-ами являются все твои 274 корневых сертификата. Это просто Inputs, то бишь входные данные. Ты просто берёшь чей-то самоподписанный корневик и называешь его доверенным.
Да ты даже сам можешь выпустить себе самоподписанный сертификат и подгрузить его в браузер, и всё, для тебя он станет доверенным. Можешь раздать его своим друзьям, и для них он тоже станет доверенным. Вот и вся история.
И никто никого не заставляет, не доверяешь — сноси корневые, в этом случае ты, конечно, сломаешь себе интернет, но зато не будет проблем с доверием.
Это основы. Смотри стандарт X.509, раздел про верификацию маршрута сертификации. Прикол в том что доверенный корневой сертификат, он же trusted anchor выбирается произвольно. Это просто исходные данные.