Category: it

Category was added automatically. Read all entries about "it".

Я

Заглавный пост

Пишу обо всем, что меня интересует. А на данный момент, хотя интересы меняются довольно редко, это: путешествия, банковские и житейские вопросы, IT и разработка. Лытдыбра с котиками мало (но котики могут появиться в любой момент!). Стараюсь делать посты информативными и полезными. Если кратко, то фотографии пляжей Таиланда или перепост "у маленького Вани пиздецома, срочно нужна пересадка бабла" вы здесь вряд ли найдете, а вот расписание общественных автобусов в Доминикане, выбор рюкзака или инструктаж по влезанию в ипотечную кабалу - это запросто. Как уже, наверное, поняли, ругаться в меру можно. Мера определяется на глазок владельца журнала.
Основные тэги журнала:
Инфо о стране - быстрая информация о посещенной мной стране: где жить, как передвигаться, как оставаться на связи, что там с деньгами, чем заняться, какие особенности и т.д.
Ликбез - обычно пошаговая инструкция для достижения какого-либо блага или его дотошное описание. Может касаться как вопросов путешествия, так и получения различных документов и прохождения бюрократических процедур.
Полезное - если на момент написания казалось, что пост будет полезным.
IT - все, что касается IT (логично, правда?)
Банки - все про банки.
Вылазка - путешествия, туризм и т.д.
Если хотите что-то написать о себе, узнать обо мне, сообщить мне свое мнение о чем-либо или ком-либо, включая автора журнала - велкам в комментарии к этому посту. Также можно отписаться при желании зафрендиться (страдаю взаимофрендингом).

Анонс
И чтобы полезность данного поста зашкалила все возможные полезностиметры, тут же буду делать анонсы будущих записей. Если тема, которая в скором времени обещает появиться, интересна, ждите. Надоело ждать - можете потыкать меня палкой в этом посте, увеличив мотивацию.
Я

Мнимая и настоящая борьба с мошенниками

Как выглядит мнимая борьба:

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

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

— надо на пятьдесят третьей странице общих банковских правил, менять которые банк может хоть каждый день, написать обвинительный текст для клиента, если он передал хоть какие-то данные карты третьим лицам, даже если клиента уже убили. Не забыть при этом провоцировать этого же клиента рекламой о том, как же удобно делать переводы по номеру карты, ведь всего-то передать номер карты незнакомцу на Авито. Привет, Сбер!

— надо запретить денежные переводы больше X рублей в день. А потом заблокировать на n-ом переводе клиента, потому что он что-то много переводов делает, когда пытается вывести деньги с зарплатного банка в нормальный. 

— у вас более 600 000 в переводе? Извините, у нас руки связаны, мы вместе с государством с терроризмом боремся, так что даже если ФИО полностью совпадает, мы заставим вас подержать ваши деньги у нас.

— блокировка всего сервиса смс при смене симки. 

— обязательность паспорта для оформления симкарты. Привет, МТС!

Тысячи их.


Как выглядит настоящая борьба с мошенниками:

— банк Авангард каждому клиенту выдает: бесплатную услугу смс-паролей, скрэтч-карту и флэшку с электронной подписью. Даже если вы открыли бесплатную карту.

— любая компания, предоставляющая удаленный доступ для сотрудника, не считает смс краеугольным и единственным камнем безопасности. Google Authenticator, белый список IP, сертификаты и т.д.

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

— при входящем звонке от банка уведомление, что если вы не верите этому входящему звонку, то перезвоните сами в этот банк с набором добавочного номера.

Кто что еще может добавить?

Триггером этого поста послужили два письма от «Reg.ru». К КДПВ отношения не имеют, наоборот, они рассчитаны на работяг. Ну ок, офисных работяг. 

Итак, эти письма заявили, что сегодня в полночь мой домен превратится в тыкву, и ведь дата совпадает. Спам-фильтр пропустил. Ссылка для оплаты вела на доверенный домен яндекс денег. Для человека, который читает это письмо с мобильного, выглядит очень реалистично. Тем более, что с мобильного обычно в дороге. А там не до концентрации внимания. Даже проверка через хуиз говорит, что таки да, сегодня все. А на год внимание можно и не обратить — ведь любимый домен отбирают!

Так вот, чтобы отсеять подобных мошенников разработчикам мобильной почты надо всего-то дать возможность выставить настройку «я хочу видеть все технические детали письма», и тогда мошенники влёт вычисляются по домену mail.account в адресе отправителя. Но забота о клиентах, которые у производителей мобил и софта давно уже ассоциируются с опеканием умственно отсталых, не дает ход такой фривольности. Сказано в имени отправителя «Владимир Владимирович Путин» — верь и повинуйся!


Я

DPI уже с нами

Похоже тесты DPI закончились успешно, и теперь тот же rutracker.org с помощью старой доброй прокси уже не откроешь. Сама прокси при этом точно не заблокирован.

Кто какие хорошие докер-образы VPN серверов знает, чтобы не трахаться в куче настроек, а просто задать логин/пароль и вперед с правильным плагином для браузера?

Как настроение у тех, кто уже поднял себе такой VPN? Плюсы, минусы, подводные камни? Скорость норм? 

Что нас ждет дальше? 

UPD: это очень смешно! Пока я тут боролся с нашими товарищами майорами, им на помощь пришли итальянские товарищи майоры, которые как раз и закрыли доступ на своей стороне! Выяснил я это, когда попытался вгетнуть тот самый рутрекер на самом прокси-сервере.
Но радует, что итальянцам телеграм по барабану.

Но тайна, хрен ли SOCKS5 прокси недоступны с любой другой машины, кроме той, на которой они и установлены, все еще остается не раскрытой.

Я

Ну что, теперь ЯМЫ NGINX?

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

  Если кто вспомнит историю про GitLab и его дискриминацию по стране проживания, то на самом деле абсолютно ничего не поменялось. Очередные маски-шоу в России для захвата бизнеса — это совсем не новость. Как и то, что Россия далеко не единственная практикующая такой подход страна. Как и пиздеж в манифесте ГитЛаба. Как и принятие ими решений с оглядкой на национальность основателя.

Я

И еще немного про географию и мир без границ или back to the basics

Support Engineer Job family country-of-residence block

SRE Job family country-of-residence block

Если кратко, GitLab более не нанимает на определенные позиции людей из Китая и России, а также не позволит переехать уже работающим сотрудникам в эти страны и сохранить при этом должность. Делает он это из-за большой озабоченности некоторых крупных клиентов, а также, потому что считает это нормой для IT индустрии в условиях текущего геополитического климата. Про норму — это вот внезапно. 

Вот тут вроде бы стало ясно, что одной из причин решения был забаненный в Китае Гугл, что якобы не позволяет полноценно работать: https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/32606
Так что Китай вроде как не по высосанной из пальца причине. Если, конечно, считать разумной причиной, что потенциальные работники настолько тупые, что про VPN не слышали. Россия же в списке остается, потому что «это просто решение руководства». Эта фраза уже исчезла из обсуждения, которое заодно и залочили, видимо, для обдумывания, как теперь разгрести все это говно.

Как минимум в одном из решений сначала была указана еще и Украина, отчего удивились вообще все. Защитники блокировок пытались что-то сказать про высокий уровень кибер-преступности во всех указанных странах, но тут им сразу указали, что так-то США номер два в этом списке, и вообще давайте статистику, где будет видно, что все эти страны в топчике. На этом Украину исключили.

На самом деле решение вряд ли принято окончательно. Его уже изменили с формата «мы вам сообщаем» на формат WIP (work in progress). Внутри звучат как адекватные мысли, так и обычный срач. Украинцы и россияне, конечно же, больше всех отличились, но и китайцы с тайваньцами тоже присутствуют. Но радует, что большинство все-таки сохраняют разум и выступают против этих запретов.

Open Source, который мы заслужили.

Я

Ответ на загадку

Сама задачка здесь

  Проблема в том, что в InnoDB уровень изоляции по умолчанию REPEATABLE READ. Если две транзакции одновременно сделают селект фор апдейт по одному и тому же предикату, а такой записи не будет, то первая транзакция, которая попытается вставить эту запись, будет заблокирована, так как другой транзакции уже было обещано, что такой записи нет, и никто на нее блокировку не поставит. Вторая же транзакция потом тоже захочет сделать такой же инсерт и тут уже она будет заблокирована инсертом первой транзакции. Па-бам, у нас дедлок на ровном месте!

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

Я

Что будет завтра или немного понастрадамлю

В 2017, когда побывал на Хайнане и вкусил китайских традиций обезопасивания граждан от всякой непотребщины, пророчил, что у нас в России будет то же самое через пять лет. Промазал на четыре года. Я законченный оптимист, видимо.

Попробую еще раз. https://meduza.io/news/2019/07/19/zhiteley-kazahstana-obyazali-ustanovit-sertifikat-bezopasnosti-dlya-zaschity-ot-hakerskih-atak-i-prosmotra-protivopravnogo-kontenta — это нас ждет в более причесанном виде в ближайшие три года.
Для непосвященных: предлагается установить сертификат, после чего казахские товарищи майоры будут иметь доступ к TLS трафику, используя атаку man-in-the-middle. Исключения составят те ресурсы, которые имеют дополнительные проверки, а точно ли клиент доверился именно тому сертификату, который выпустил именно сам ресурс. Тут, если честно, я немного плаваю в нюансах, но общий смысл такой.

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

Я

А кто в NAS'ах рубит?

Давно уже пора обзавестись нормальным. До этого была какая-то железка от Agestar где-то за 400 рублей, которая, однако, умела в RAID 1 и, соответственно, два винта. И все бы ничего, но она похоже приказала долго жить. Пора что-то на замену и более менее нормальное.

Друг насоветовал выбирать из Synology, мол, ведущие собаководы. Другой друг советуют сделать самосбор под спец. дистрибом линукса. Я лично зашел на Я.Маркет и вижу там вот это: https://market.yandex.ru/catalog--setevye-nakopiteli/55415/list?hid=6042233&glfilter=16407942%3A16407949&onstock=1&local-offers-first=0&priceto=14000

К самосбору душа никак не лежит, потому что вряд ли получится дешевле 8 тысяч, которые просит Zyxel, и даже вряд ли 13-ти, которые хотят за Synology.

Что выбрать из ссылки на Маркет? Я так не вижу разницу в характеристиках между Zyxel и Synology. Так зачем платить больше? 

Для каких целей: просто локальный бэкап фоточек и более критичной информации. Чуть-чуть торрентов, чуть-чуть DLNA и/или медиа-сервера. Никаких терабайт информации, никакого онлайн-процессинга контента.

Я

HTTPS сервер на Java, PKCS#12 и серверный сертификат



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

Итак, нам надо выпустить серверный сертификат.
1. Сначала создаем секретный ключ и запрос на сертификат:

openssl req -utf8 -config openssl.cnf -newkey rsa:2048 -nodes -keyout private/cert_priv.key -out requests/cert.req

В процессе вводим пароль к секретному ключу. Не забываем его записать на стикер и приклеить на монитор.

2. Высылаем запрос специально обученному человеку, который создаст сертификат и подпишет его родительским сертификатом, чтобы клиент (например, браузер) мог выстроить цепочку сертификатов, добравшись до доверенного корневого и убедиться, что все ок, и никакой товарищ майор посередине трафик слушать не будет. Получаем сертификат.

3. Теперь надо создать PKCS#12 контейнер - хранилище ключей, который будет содержать полученный сертификат и секретный ключ. Этот контейнер уже будет использоваться в коде.

openssl pkcs12 -export -out cert_container.p12 -inkey private/cert_priv.key -in cert.cer

Для тех, кто считает, что хорошо знает криптографию, первый вопрос: что за пароль "Enter Export Password:" запросит OpenSSL во время выполнения этой команды?

4. Переходим к яве. Нам надо загрузить это хранилище ключей и проинициализировать SSLContext в яве, где мы делаем сервер с поддержкой HTTPS. Условный, но работающий код:

final char[] password = new char[]{'1', '1', '1', '1'};

final KeyStore ks = KeyStore.getInstance("PKCS12");
final InputStream keystore = SenderActorTest.class.getClassLoader().
        getResourceAsStream("cert_container.p12");
if (keystore == null) {
    throw new RuntimeException("Keystore required!");
}
ks.load(keystore, password);

final KeyManagerFactory keyManagerFactory = KeyManagerFactory.getInstance("SunX509");
keyManagerFactory.init(ks, password);

final TrustManagerFactory tmf = TrustManagerFactory.getInstance("SunX509");
tmf.init(ks);

final SSLContext sslContext = SSLContext.getInstance("TLSv1.2");
sslContext.init(keyManagerFactory.getKeyManagers(), tmf.getTrustManagers(), new SecureRandom());




Казалось бы все. Можно использовать. Почти.
Второй вопрос для тех, кто считает, что хорошо знает криптографию: что за пароль надо указать в строках с ks.load и keyManagerFactory.init? Только чур в исходники не подглядывать!

Третий вопрос для тех, кто считает, что хорошо знает криптографию: а где надо указывать пароль для доступа к секретному ключу из этого хранилища?

Четвертый вопрос уже для тех, кто считает, что хорошо знает явовскую инфраструктуру вокруг HTTPS: а что будет, если пароль для секретного ключа указан неверно?

[Ответы]
1. Ну это довольно просто: пароль для доступа к создаваемому PKCS#12 контейнеру

2. Тоже довольно просто: пароль для доступа к создаваемому PKCS#12 контейнеру. Или нет?

3. Хе-хе. Пароль для доступа к секретному ключу должен совпадать с паролем к PKCS#12 контейнеру! Я немного офигел. Или это действительно где-то в спецификациях прописано? Убедиться, что это так как минимум для алгоритма SunX509 можно, перейдя внутрь keyManagerFactory.init и добравшись до конструктора sun.security.ssl.SunX509KeyManagerImpl#SunX509KeyManagerImpl
И вроде бы это должно означать, что пароль для доступа к контейнеру надо указывать при вызове ks.load, а пароль для секретного ключа при вызове keyManagerFactory.init. Но если эти ключи не совпадает, то последний вызов падает. Додебажить декомпилированный код сегодня уже не могу, но там явно что-то не чисто.
У меня все это добро завести получилось только при одном условии: пароль для контейнера и пароль для секретного ключа должны совпадать.

4. А ничего не будет. Если в keyManagerFactory.init указать пароль не от контейнера, то этот вызов упадет. А если указать пароль от контейнера, но который не совпадает с паролем от секретного ключа, то инициализация пройдет отлично. Просто сервер на все HTTPS запросы будет выдавать херню, так как будет искренне думать, что использует правильный секретный ключ, а не фигню, получившуюся в результате применения неверного пароля при извлечении этого секретного ключа. И, соответственно, после обработки исходящего HTTP сообщения таким секретным ключом там будет белиберда.


Все-таки подозреваю, что я где-то что-то не так делаю. Может кто подскажет?

UPD: все в порядке. Это я в пятницу переработал, похоже. Не знаю, для чего именно я вводил пароль при создании запроса на сертификат, но повторное выполнение этой команды показало, что там никакого пароля не требуется. Возможно до этого копался с чем-то и ввел там, а запомнил, что как-будто вводил при создании секретного ключа и запроса на сертификат. Собственно, созданный секретный ключ с заголовком "RSA PRIVATE KEY" без слова ENCRYPTED тоже намекает, что ключ этот у меня создался без шифрования.
Итог: в приведенном куске кода оба раза надо использовать пароль от контейнера. В уже зашифрованном контейнере секретный ключ еще раз уже не шифруется. Так что все норм, все снова стало логично, и нечего копаться в таких темах по вечерам пятниц.
Я

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


Что-то я припозднился, ну да ладно, кому-то может и поможет. И на всякий случай, если кто еще не в курсе, напомню, как обойти эти умопомрачительно технологичные блокировки в обычном браузере: https://donz-ru.livejournal.com/227396.html

Для тех, кто сходу готов заявить, что "да телеграм и так работает!!!": нет, "и так работает" далеко не у всех. Например Мегафон таких вольностей Дурову не позволяет и без дополнительных телодвижений мобильный телеграм не пашет.

1. Инструкция для тех, кто ни в зуб ногой.
   1.1 Самый просто способ, если Телеграм еще работает - добавьте бота @socks5_bot и нажмите кнопку "Подключить".
   1.2 Если уже не работает, то вбейте tg://socks?server=telegram.vpn99.net&port=55655 и ентер.
Но в обоих случаях работоспособность не гарантируется - ресурсы халявные, никто ничего гарантировать не может и не будет.

2. Инструкция для тех, кто умеет или хочет уметь купить VPS (если не знаете, что такое VPS и не догадались погуглить, то этот пункт не для вас)
  2.1 Покупаем VPS от 2 баксов в год. Да, в год. http://lowendstock.com/ - тут. Но лично я по привычке воспользовался https://www.arubacloud.com/ за 1 евро в месяц. Как бы в семь раз дороже, но мне там все знакомо, и лично у меня проблем не было, в отличие от некоторых друзей/знакомых. В общем, ни по одному из этих хостеров я не могу дать гарантию качества, но за два бакса в год можно и самому попробовать. Исключение - Аруба. Если честно, я не понимаю, как там ловили проблемы. Да, есть некоторые шероховатости, но это точно не фатально и даже не особо дискомфортно. Но возможно у меня очень простой сценарий использования, и я не наткнулся на тот самый проблемный сценарий.
  2.2 Выбираем линукс в качестве ОС. Работаем из-под root (да, если сервер только сраного SOCKS5, то можно). Ставим docker. Чтобы его поставить надо вбить в гугл "<название выбранного линукса> how to install docker"
  2.3 docker run -d --name socks5 -p 1080:1080 -e PROXY_USER=your_user -e PROXY_PASSWORD=your_pass --restart always serjs/go–socks5–proxy
  2.4 профит. У вас собственный сокс5 сервер на IP вашего VPS с юзером и паролем, что вы указали вместо your_user и your_pass

Альтернативный путь для собственного VPS. Сам не проверял. https://github.com/Lozy/danted - отсюда запускаете скрипт.

Всем Телеграма и другой запрещеночки!

P.S. печаль все же есть - ни один из этих способов не поможет преодолеть явную проксю, если она присутствует между вами и интернетом. Но не отчаивайтесь! Есть VPN. Но взять на себя груз рассказать про него я не готов - не настолько компетентен.