Pull to refresh
57
0
Изя Ц. Петров @muromec

User

Send message
>если бы я видел адекватное поведение сторон — согласился бы с вами без промедления

ну вот этим и отличается цивилизованная страна от дикого аула.

у цивилизованных людей работает право, а у вас — «понятия» и «адекватность»

> Но когда я вижу как соседи с криками «получите унтерменши» творят непотребства на международной арене

да вам в ООН выступать!
А религиозные ваши чувства не оскорбляю?
слушайте, вы придумали гипотетическую херню про теракты на гитхабе, а в реальности упоротые чинуши вам его отключили просто так.

и вы сейчас пытаетесь объяснить, что отключили правильно и сидеть без гитхаба — это норм.
>Нарушает он или нет не зависит от гражданства, места жительства или места нахождения хостинга.

то есть если я буду дуть коноплю в Калифорнии — я этим нарушу законы дикой северной страны и меня там при случае посадят?

интересное у вас понимание юрисдикции.
>Что касается muromec, единственное что он добьется, так того, что его репо в итоге заблочит по региональному признаку сам GH

Ну так я это им сам предлагал еще в октябре, когда мне их саппорт писал. Хотите цензурить интернет для диких русских — сами и цензурьте.
какая-то странная предъява. мое бездействие приводит к ущербу российской экономике и потенциальному отъезду из россии квалифицированного персонала. меня более чем устраивает такой результат.
>Когда мы узнаем о решении гитхаба, можно будет делать какие-то выводы.

а чего ждать — их уведомили месяц назад еще. решение гитахаба было связаться с пользователями, залившими контент, уведомить, что на контент была кляуза и предупредить, что это может привести к недоступности сервиса в отдельно взятом диком ауле.
>И в любом случае, вы либо выступаете плагином (тогда вам не нужен свой сайт, вы выпускаете именно плагин), либо делаете сайт с полным механизмом, но в этом случае вы вообще не передаете подпись/сертификат потребителю, а передаете сразу идентификационные данные, подписанные ключом вашего сайта (как делает та же ЕСИА).

Вы зачему-то путаете в одну кучу безопасность для пользователя, признание подписываемых данных государством и вопрос доверия сайта-инициатора.

* Первое решается вынесением работы с ключем в отдельный контекст (это есть)
* для второго нужна сертификация или экспертиза (этого сейчас нет и не всем нужно)
* вопрос доверия сайта-инициатора решается проверкой подписи на его стороне (это есть) и вводом ИНН в форме логина (это вопрос интеграции, я подумаю над ним)
Да, Все так быстро меняется, что на сайте АЦСК не успевают обновлять шапку.
>Во-первых, это далеко не единственная практика. А во-вторых, что в ней дырявого (если, конечно, апплет нормально написан)? Или вы судите по одному конкретному примеру?

В том, что запрашивает доступ к ключу через веб-интерфейс страницы. Правильность, доверенность и сертифицированность самого апплета при этом перестает играть какую-то роль.
>Сертифицированный (или, по крайней мере, доверенный) плагин

Ну вот таким доверенным плагином и хочется быть. Разница в том, как отделять контекст плагина от самого приложения — ставить на машину заранее, либо подгружать с доверенного домена.

В дальнейшем я планирую повысить уровень паранои и подписывать заранее установленным на машине пользователя кодом, либо мобильным приложением.

Существующая же сейчас практика интеграции ЭЦП, в виде жава-апплета, подключаемого прямо в страницу мне не нравится, поскольку это дыра. Поэтому и делаю, то что делаю.
>Так нет же никакого «входа». Библиотека общается с ключом через системные средства, к ним у приложения доступа нет, и перехватить ничего нельзя.

Окей, расскажите, как это будет выглядеть для веба.
>Во-первых, сертифицированная библиотека ни при каких условиях не выпускает приватный ключ наружу (без этого она вообще сертифицирована не будет).

все правильно, поэтому ключ надо перехватывать на входе.
>Вот именно поэтому в таких системах должны использоваться только сертифицированные средства криптографии, которые такого не позволяют.

Все так. Проблема в том, что в случае веба, вокруг сертифицированной библиотеки криптопреобразований будет висеть обычный код для ввода-вывода информации, а в запущенных случаях — тридцать пять скриптов на жквери, каждый из которых может перехватить ввод, подменить документ и увести приватный ключ.
Спасибо за фидбек (лала-лала-ла)!
Ну если вы *лучше* знаете, что все должно быть не так — сразу бы и сказали. Меньше бы потратили моего и вашего времени, извините.
>закрытый ключ используется только на клиенте, а сайту уходят только зашифрованные данные?

Пользователю приходится доверять, что это будет именно так. Это банальный фишинг — показать формочку для сброса ключа, а потом вместо создания подписи просто его утащить к себе.
>Вы определитесь, у вас подписание на сервере или на клиенте?

на клиенте, разумеется.
>В первом сценарии ничто не мешает вашему сервису использовать закрытый ключ известного ему сертификата для формирования подписи, и передавать тот же сертификат по ссылке, сайт-инициатор так и не узнает, что это не сертификат пользователя.

В таком сценарии вы можете в форме логина спрашивать у пользователя ИНН и потом сверять с тем, что написано в сертификате.

>Во втором сценарии просто нет никакой проверки подписи, пользователь не знает, что он подписывает.

Есть вариант лучше — я просто считываю приватный ключ, отправляю его на сервере и у всех все плохо. Это не решается технически, только аудитом, к сожалению.
Не доверять приватный ключ софтверу, который этим приватным ключем подписывает данные — это новое слово в криптографии.

При обострении паранои, разумеется можно отключать интернет в момент подписи, чтобы злой жаваскрипт ничего никуда не увел.

На самом деле это все серьезно, но вы как-то очень в недружелюбном и неприятном тоне все пишете, совершенно убивая желание вести с вами нормальную дискусси.

Information

Rating
Does not participate
Registered
Activity