Мне казалось, что рекомендации и правила описанные ниже всегда были очевидны и логичны для сотрудников ИТ-компаний. Но удручающая практика показывает, что есть масса людей, которые не задумывались и не смотрели со стороны на то, как они общаются с коллегами. Ведь чуть поднапрягшись, можно существенно улучшить эффективность взаимодействия с ними. Опытные разработчики всё это уже знают, но, зачастую, не молодёжь, не заставшая никаких средств общения кроме real-time IM-ов. А форсированный уход на удалёнку во время COVID, показал как не много людей (целых компаний!) способны эффективно работать без живого общения.

Я использую GnuPG (реализацию OpenPGP и LibrePGP) каждый день на протяжении более чем десяти лет. У меня накопилось почти две сотни публичных ключей разных людей с которыми я общался и общаюсь по почте. Почти три сотни публичных ключей для проверки дистрибутивов операционных систем и архивов исходного кода программ. И это не считая более чем полутора тысяч публичных ключей из ключниц GNU, Linux, Debian, FreeBSD и других проектов. Я был постоянным популяризатором OpenPGP экосистемы и рекомендовал её использовать для массы задач, возникающих даже в банальных домашних условиях. Но за последние пару лет я ощутимо поменял своё мнение насчёт её рекомендации. Перестал всё это использовать почти везде где можно.

Расскажу про эволюцию формата зашифрованных пакетов в store-and-forward утилитах NNCP, о которых я уже писал на Хабре. Что может быть проще, чем передать пакет данных в зашифрованном виде? Но всё возникающие дополнительные потребности и пожелания пользователя, заставляют усложнять и исхитряться с форматом пакета.

Статья-продолжение первой части, в которой не уместилось всё что хотел описать. Напомню, что в ней я начал описывать своё рабочее окружение и dotfiles.

Приветствую! Я люблю рассматривать чужие dotfiles и рассказы об устройстве рабочего места и окружения. Во-первых, любопытно как работают другие люди. Во-вторых, нередко находишь какой-нибудь полезный трюк или идею. А повышение продуктивности разработчика ПО часто идёт за счёт, казалось бы, мелочей (много кто помнит, что Ctrl-T посылает SIGINFO сигнал, показывающий прогресс копирования cp или dd?). Вот и решил рассказать про своё рабочее окружение, в том числе dotfiles. Перечислю список секций этой статьи, чтобы было примерное представление о чём пойдёт речь: Ввод, ОС, ФС, X11, MRA и MDA, Сеть, Jail, Демоны, MTA, MUA, WWW, PGP, IRC, st, tmux, cd, git, zsh, zsh completion, zsh history, ZLE, zsh prompt, zsh misc, less, grep, .zshenv, autoenv, .zprofile, t, Музыка, mpv, Картинки, Архивы, Feeds, Hjson, *tex*, File transfer, Games, БД, ЯП, Python, Go, C, redo, TAI64, Vim, tags, .vimrc, ~/.vim/pack, ~/.vim/plugin, ~/.vim/ftplugin. Безусловно будут спорные holywar высказывания, так что везде иметь в виду и добавлять фразу «по моему личному мнению».

Приветствую! Очень хочется рассказать про устройство современного стэка IPsec протоколов ESPv3 и IKEv2. IPsec, как мне кажется, незаслуженно обходится многими стороной и детального разбора его работы, его протоколов и возможностей я не видел на русском языке. Кроме того, сделаю странное — сравню IPsec ESPv3 и IKEv2 (оба 2005-го года) с современным, модным, state-of-art TLS 1.3 2018-го года.


Почему я вообще так увлечён темой IPsec — возможно самого сложного стэка протоколов для защиты сетей? Ведь сложность это главный враг надёжности и безопасности! Во-первых, чем больше узнаёшь про его протоколы, особенно IKEv2, тем больше понимаешь как много возможностей в него закладывалось и впечатляешься его продуманностью, в отличии от распространённого подхода разработчиков «костыль костылём погоняет» и решением серьёзных проблем «пока гром не грянет». Во-вторых, IPsec протоколы хорошо продуманы с криптографической точки зрения и, даже старые ESP/IKEv1, фактически являются единственными промышленными массово используемыми протоколами в которых не было сколь либо серьёзных уязвимостей. Тот же SSL (1995-ый год) стал достойно продуманным только с версии 1.3. А нелюбовь к IPsec у многих связана с монструозной сложностью IKEv1, которой больше нет в v2.

Приветствую! Хочу рассказать о главных, не всегда очевидных, недостатках системы сборки Make, делающих её часто не пригодной для использования, а также рассказать о прекрасной альтернативе и решении проблемы — гениальнейшей по своей простоте, системе redo. Задумка известнейшего DJB, криптография которого где только не применяется. Лично меня, redo настолько впечатлил life-changing простотой, гибкостью и куда лучшим выполнением задач сборки, что я практически во всех своих проектах им полностью заменил Make (там где не заменил — значит ещё руки не дошли), у которого я не смог найти ни одного преимущества или причины оставлять в живых.

Продолжаю прошлую статью о PyDERASN — свободном ASN.1 DER/CER/BER кодеке на Python. За прошедший год, с момента её написания, кроме всяких мелочей, небольших исправлений, ещё более строгой проверки данных (хотя и прежде он был уже самым строгим из известных мне свободных кодеков), в этой библиотеке появился функционал для работы с большими объёмами данных — не влезающих в оперативную память. Об этом и хочу рассказать в данной статье.

Сравню FreeBSD с GNU/Linux системами. Всё это исключительно субъективное мнение! Многое это просто мой опыт. Почти 100% всего времени я провожу за компьютером и исключительно Unix системами, примерно поровну с FreeBSD и GNU/Linux, вот уже 20+ лет.

Большая часть достоинств FreeBSD также относится и к другим популярным свободным BSD системам: NetBSD, OpenBSD, DragonflyBSD. Что-то в этих системах будет получше, многое появилось впервые не в FreeBSD, но перекочевало в неё. FreeBSD многое наследует от NetBSD (различные драйвера и подсистемы), от OpenBSD (сетевые технологии), DragonflyBSD (лучшая масштабируемость на многопроцессорных платформах), от Solaris (DTrace, идея Jail-ов, ZFS), сочетая самое лучшее ото всех.

Если коротко, то FreeBSD это высокое качество, надёжность, удобство и простота работы. GNU/Linux это зоопарк, помойка малосвязанного кода, мало чего доделываемое до конца, отсутствие документации, хаос, базар.

Практически все статьи, которые я видел на тему «чем хорош IPv6 и почему на него стоит пошустрее переходить», говорят только о просто более широком адресном пространстве. В лучшем случае, упомянут автоматическую конфигурацию адресов и маршрутов (stateless address autoconfiguration (SLAAC)). Это удручает, а ведь IPv6 имеет много ещё других неявных плюшек, являясь очень продуманным стеком протоколов (IPv6 + ICMPv6 + NDP)! Создаётся впечатление, что IPv6 это просто тупо про расширение адресов, а дальше то особо никакого профита. Или же некоторые статьи плачутся о том, что они не видят сиюминутного профита от внедрения/перехода. Простоту и удобство, гибкость и расширенные возможности (из-за одного только избавления от NAT-а) не так то легко измерить, как какие-нибудь задержки и пропускную способность. Решил поэтому собрать моё видение прекрасного мира IPv6 протокола и его плюсы в этой статье.

Будучи разработчиком PyGOST библиотеки (ГОСТовые криптографические примитивы на чистом Python), я нередко получаю вопросы о том, как на коленке реализовать простейший безопасный обмен сообщениями. Многие считают прикладную криптографию достаточно простой штукой, и .encrypt() вызова у блочного шифра будет достаточно для безопасной отсылки по каналу связи. Другие же считают, что прикладная криптография — удел немногих, и приемлемо, что богатые компании типа Telegram с олимпиадниками-математиками не могут реализовать безопасный протокол.

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


В статье будет написан peer-to-peer, friend-to-friend, end-to-end зашифрованный instant messenger с SIGMA-I протоколом аутентификации и согласования ключей (на базе которого реализован IPsec IKE), используя исключительно ГОСТовые криптографические алгоритмы PyGOST библиотеки и ASN.1 кодирование сообщений библиотекой PyDERASN (про которую я уже писал раньше). Необходимое условие: он должен быть настолько прост, чтобы его можно было написать с нуля за один вечер (или рабочий день), иначе это уже не простая программа. В ней наверняка есть ошибки, излишние сложности, недочёты, плюс это моя первая программа с использованием asyncio библиотеки.

ASN.1 это стандарт (ISO, ITU-T, ГОСТ) языка описывающего структурированную информацию, а также правил кодирования этой информации. Для меня как программиста это просто ещё один формат сериализации и представления данных, наравне с JSON, XML, XDR и другими. Он крайне распространён в нашей обычной жизни, и с ним многие сталкиваются: в сотовой, телефонной, VoIP связи (UMTS, LTE, WiMAX, SS7, H.323), в сетевых протоколах (LDAP, SNMP, Kerberos), во всём, что касается криптографии (X.509, CMS, PKCS-стандарты), в банковских картах и биометрических паспортах, и много где ещё.

В этой статье рассматривается PyDERASN: Python ASN.1 библиотека активно применяющаяся в проектах связанных с криптографией в ФГУП «НТЦ „Атлас“.

В этой статье поднят вопрос удручающей ситуации с доступностью данных в Интернете, злоупотреблением цензурой и тотальной слежкой. Власти ли или корпорации в этом виноваты? Что поделать? Создавать собственные соцсети, участвовать в сетях анонимизации, строить mesh-сети и store-and-forward решения. Демонстрация NNCP утилит для создания этих store-and-forward friend-to-friend решений.

Сейчас в мире Интернета преобладающее количество всех служб работают в режиме online: то есть постоянное соединение с Интернетом и серверами. Если HTTP, FTP или IRC сервер недоступен, то вам об этом сразу же явно сообщат. Не всегда есть возможность иметь такую роскошь как постоянный online. Иногда это дорого, иногда просто технически невозможно. Есть опасность что появится Великий Российский Firewall который будет разрешать только whitelist доступ к ресурсам и доступность «полноценного» Интернета, в лучшем случае, будет только от места к месту. Режим работы при котором данные для отправки сохраняются и ожидают пока появится связь называется store-and-forward. Именно этот режим удобно позволяет работать в условиях непостоянного online.

На написание этой статьи меня навеял просмотр двух документальных фильмов от Jason Scott: BBS: The Documentary и GET LAMP. Первый рассказывает про мир Bulletin Board System (BBS), становление FidoNet, ASCII/ANSI-art сцены. Второй показывает мир interactive fiction (IF) игр (Adventure, Zork, ...). Сам я застал и BBS и FidoNet, застал их культуру и атмосферу.

После их просмотра создаётся впечатление что было столько прекрасных интересных и завлекающих технологий, игр и штук, а затем они внезапно канули в небытие. Было хорошо, а стало паршиво. Но вскоре дошло что ничего подобного. В процентном соотношении оно умирает, а в абсолютных числах как было, так и осталось.

Эта публикация является продолжением ранее написанной в нашем блоге: «Реализуем безопасный VPN-протокол». В этой статье мы не переделываем и не переписываем протокол, а только чуть дорабатываем его дальше. Реализация всего нижеописанного уже присутствует в версии GoVPN 3.1.



Для создания шума немного изменён транспортный протокол. Для аугментации рукопожатия и усиления паролей изменён протокол рукопожатия. Более подробно обо всём этом под катом.

Снова тема VPN, конфиденциальной передачи данных, безопасности и криптографии. Сейчас, в эру пост-Сноудена, стало модно клепать безопасные, уважающие приватность, невзламываемые, защищённые от спецслужб и цензуры программы. Однако эта статья – не очередной маркетинговый пиар, а, скорее, демонстрация того, как применяются криптографические примитивы и на что стоит обращать внимание при разработке подобного программного обеспечения.



Результатом этой работы предполагается создание работающего клиент-сервера, пригодного для review разработчиками (то есть немного кода на высокоуровневом языке), достаточно производительного, чтобы использоваться в промышленных условиях, имеющего высокий порог безопасности: GoVPN.

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

В данной публикации я сделаю сравнение Bitcoin, о котором многие уже слышали, с ранее созданными системами электронных денег, основу которых положил David Chaum ещё в начале 1980-х. Bitcoin в большинстве информационных источников представляется как нечто революционные, из ряда вон выдающееся. Продемонстрирую, что это просто навсего всего-лишь ещё одна система платежей, не сильно лучше PayPal, WebMoney и подобных, а во многом даже отстающая от них.