snik_1900

Да-а. Демка новой версии читает но не сохраняет. Жаль....

А кто знает чем можно снять слепок ключа выполненного под ГОСТ 12?

Кто что думает по поводу: Название документа Приказ Минкомсвязи России от 29.10.2018 N 573 "Об утверждении Требований к техническим и программным средствам информационных систем, содержащих базы данных абонентов оператора связи и предоставленных им услугах связи, а также информацию о пользователях услугами связи и о предоставленных им услугах связи, обеспечивающих выполнение установленных действий при проведении оперативно-розыскных мероприятий" (Зарегистрировано в Минюсте России 18.12.2018 N 53028) Источник публикации Официальный интернет-портал правовой информации http://www.pravo.gov.ru, 19.12.2018 Примечание к документу Начало действия документа - 30.12.2018.

Уже разобрались. С OpenSSL 1.0.2q 20 Nov 2018 заработало. Наш косяк. В скрипте не были указаны пути. По этому брался тот который п умолчанию стоит. 1.1*

Если ставить из портов то устанавливается: OpenSSL 1.0.2q 20 Nov 2018 Но он то же не работает И как дальше быть? В догонку: /usr/local/bin/openssl engine (rdrand) Intel RDRAND engine (dynamic) Dynamic engine loading support 34370961408:error:25066067:DSO support routines:dlfcn_load:could not load the shared library:crypto/dso/dso_dlfcn.c:117:filename(/usr/local/lib/engines-1.1/gost.so): Cannot open "/usr/local/lib/engines-1.1/gost.so" 34370961408:error:25070067:DSO support routines:DSO_load:could not load the shared library:crypto/dso/dso_lib.c:162: 34370961408:error:260B6084:engine routines:dynamic_load:dso not found:crypto/engine/eng_dyn.c:414: 34370961408:error:2606A074:engine routines:ENGINE_by_id:no such engine:crypto/engine/eng_list.c:334:id=gost 34370961408:error:260BC066:engine routines:int_engine_configure:engine configuration error:crypto/engine/eng_cnf.c:141:section=gost_section, name=default_algorithms, value=ALL 34370961408:error:0E07606D:configuration file routines:module_run:module initialization error:crypto/conf/conf_mod.c:174:module=engines, value=engine_section, retcode=-1

К стати о ключах: Решили поменять сервер. Поставили FreeBSD12. Делаем: openssl pkcs12 -in p12.pfx -out cert.pem -nodes -clcerts Enter Import Password: Вводим пароль. И получаем: Mac verify error: invalid password? 34367890484:error:2306B076:PKCS12 routines:PKCS12_gen_mac:unknown digest algorithm:p12_mutl.c:90: 34367890484:error:2307E06D:PKCS12 routines:PKCS12_verify_mac:mac generation error:p12_mutl.c:123: Пробовали установить openssl из портов. То же самое. На FreeBSD11 все отлично работает. Кто-то сталкивался?

Сразу следом за этапом усечения ведущих нулей. RFC - его-ж ЧИТАТЬ надо... Как бы они не начали сокращать по 2 группы нолей. С их IQ этого можно ожидать.

У нас одно время РКН катался по кафешкам и от туда по WIFI делал быстрые проверки минут по 10-15. Как сейчас дело обстоит с такими проверками не знаю.

Руководство не желает терять абонента, но штрафов быть не должно. А ревизор как на это реагирует?

Поставит ваш клиент dnscrypt и забудет про ваши днс и запросы, как страшный сон. И все же, хотелось бы услышать, кто какими методами блокирует домены.

Это конечно вариант. Но не все админы настолько умны (читай "не ленивы").

Возник вопрос: Кто как производит фильтрацию по доменам? Мы режим все обращения в 53 порт не наших DNS серверов (соответствующий пункт в договоре есть). Сегодня обратился наш клиент с просьбой доступа к корневикам. Чисто формально для фильтрации по доменам мы поступаем правильно (нельзя фильтровать то что проходит мимо системы фильтрации). Но и клиента понять можно. Может коллективный разум поможет выработать общий подход?

Может проверка в 24 часа не укладывается?

Теперь результаты можно смотреть только после прохождения полной проверки. У нас такая проверка идет примерно 20 часов. Так что реально можно посмотреть только выгрузку за прошлый день.

Может проще каждый день в газете печатать список "гениев словесного недержания"? И все. Популярность без затрат.

"Нет ничего более вечного и бесконечного чем человеческая глупость" (с).

Как говорил (кричал) один кот в не без известном мультфильме "Ура!!! Заработало!!!"

С 19.10.2018 не можем загрузить результаты тестирования. Это только мы такие счастливчики или есть кто-то ещё? Страница со списком выгрузок тормозит. Новые заявки висят не отработанными.

"Нет придела человеческому гению в решении сложных проблем. Но ещё больше гениальности в создании этих самых проблем." (с) ;)

Интересно, как они будут в урлах ipv6 писать? В "[]" или как получится? Интересен в принципе факт определения того что указано после последнего ":" № порта или последняя часть адреса. Добавили они защиту от дураков хотя бы примитивную или нет?

А в чем фантастичность идеи? Понятно что костыли, но идея в принципе выполнимая.

Первоначально хочется что бы клиент получал ответы сразу от обоих серверов. А не с основного.

Наши. Но через разных аплинков общаются с внешним миром. И получают соответственно разные ответы.

Возник вопрос: Есть 2 DNS сервера, которые выдают на один и тот же запрос разный набор IP адресов. На клиентских машинах прописаны оба DNS сервера основной и альтернативный. Клиентская машина опрашивает основной и если не получает ответа, тогда альтернативный. На основном сервере при опросе, допустим news.google.com, возвращаются IP адреса из заблокированной РКН сети, но при этом если тот же news.google.com запросить у альтернативного DNS сервера то получим не заблокированные адреса. Так как основной DNS отвечает чаще, то большенство ответов ссылаются на заблокированные адреса. Вопрос как сделать так что бы клиенты получали не заблокированные адреса? В идеале хочется что бы 1. опрашивались оба DNS сервера; 2. был некий фильтр, например файл со списком IP адресов которые РКН заблокировал как "ip" или "subnetip", и в ответе эти адреса никогда не появлялись.

Всех это в смысле обоих?