На тестовом сервере TLS 1.3, который я реализовал и некоторое время поддерживаю по адресу tls13.1d.pw, пришлось тоже перейти на TLS-сертификаты Let’s Encrypt. А это привело к замене цепочки с ECDSA на цепочку с RSA, что, конечно, не очень хорошо. Вообще, так как сервер экспериментальный и полностью самописный, замена сертификатов требует ручного вмешательства, поэтому “долгие” сертификаты удобнее, чем трёхмесячные. Но, в принципе, можно процесс автоматизировать.

Я как-то перестал описывать изменения тестового сервера на dxdt.ru: прошлая записка на эту тему датирована январём 2020 года. При этом сервер продолжают использовать, он даже помогает находить ошибки и неточности в реализациях TLS стороны клиента. Конечно, ошибки обнаруживаются и в самом сервере – их я стараюсь исправлять.



Комментировать »


Комментировать »

Иногда открытый ключ нужно буквально вводить руками, например, через “воздушный зазор”. Открытый ключ в ECDSA (и, кстати, в ГОСТ-подписи, но не только там) – это точка на кривой, заданной в параметрах. Речь тут про кривые, используемые в криптосистемах на практике, например, P-256. Координаты точки – это два числа X, Y (сторого говоря, два элемента соответствующего конечного поля, но это технические детали). Если разрядность 256 бит, то может показаться, что для передачи ключа придётся руками вводить 2*32 == 64 байта, что в hextext составит аж 128 знаков. Однако обычно можно ограничиться одной координатой X, а Y – вычислить из уравнения кривой. Такой способ кодирования называется сжатым представлением ключа. Единственная хитрость в том, что, так как в уравнение кривой Y входит в квадрате, координат, соответствующих данному X, пара. Это обратные по сложению элементы (всем привычные +/-). Поэтому нужно передать знак элемента, но для передачи знака достаточно одного дополнительного бита. Поэтому сжатое представление в два раза короче, но “разрядность ключа” при этом никак не страдает (страдают вычислительные затраты на принимающей ключ стороне, но этим часто можно пренебречь; иногда, впрочем, приключаются проблемы с обработкой заведомо неверных значений). Кстати, по этим же причинам ключи криптосистем с ed25519 короче в записи – они изначально “в сжатой форме”.



Комментировать »

Проверка: число

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



Комментировать »

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

Таблицы Unicode – весьма богатое нововведение. Unicode позволяет записывать в тексте числа древними шумерскими цифрами, вот так: 𒁹 𒌍𒐋 𒌋𒌋𒐈. (Если на вашем устройстве эти цифры не отображаются, то, вероятно, устройство не содержит подходящих шрифтов; такое всё ещё возможно; более того, мне пришлось столкнуться с существенными трудностями при размещении этой записки в WordPress – стандартный редактор данной CMS отказывался принимать соответствующие символы, пришлось применять некоторые хитрости).

В принципе, шумерская (вавилонская) система записи – позиционная, по основанию 60, но имеет свои особенности, создающие неоднозначности при интерпретации: там используется плавающая “шестидесятеричная точка”, которая не обозначается; кроме того, в классическом варианте, нет цифры для нуля. 𒁹 𒌍𒐋 𒌋𒌋𒐈, в зависимости от контекста, можно интерпретировать не только очевидным способом, как 5783 (1*60^2 + 36*60 + 23), но и, например, как 96.38333(3) (1*60 + 36 + 23/60). Клинописные цифры, соответствующие числам от 1 до 59, записывались засечками; так, 𒐈 – это 3, а 𒌋𒌋 – это 2*10, то есть, 20 (𒌋 обозначает 10). Unicode, – по крайней мере, в теории, – позволяет все эти засечки напечатать и вывести на экран компьютера в виде текста, благодаря наличию разнообразных кодовых таблиц, среди которых есть и таблица с шумерскими древними цифрами.

Именно засечки, штрихи и прочие дополнительные “чёрточки” (умляуты и тому подобные знаки) Unicode создают исключительные проблемы при преобразовании символов. Рассмотрим в качестве примера кириллическую букву “И” с “краткой”, то есть, “Й” (“кратка” – это чёрточка над “И”). Правила Unicode позволяют обозначить данную букву как одним кодом (Й), так и комбинацией из двух – из сочетания кода буквы “И” (без “кратки”) и отдельного кода, обозначающего “кратку”, который предусмотрен в Unicode. То есть, одна буква расщепляется на два представления! Фольклорное фонетическое восприятие букв сталкивается с универсальным “чисто топологическим” и с треском прогрывает последнему. Результат, вообще говоря, может доставить неожиданных проблем разработчику программного кода, выполняющего преобразования кодировок. Поэтому в тех случаях, когда нужно запись Unicode приводить к другим кодировкам, которые не сохраняют разделение по принципам начертания, используются те или иные соглашения о нормализации, предназначение которых состоит в том, чтобы согласованным способом привести наборы кодов к единому символу. Это один из самых нетривиальных моментов в практике Unicode.



Комментировать »

В ноябре 2012 года, десять лет назад, регистраторы RU-CENTER и R01 включили поддержку DNSSEC для имён в доменных зонах .su, .com, .net. В этом перечне важен домен .su – открытое внедрение DNSSEC в российских реестрах началось именно с него. А включение поддержки означало, что все клиенты даных регистраторов смогут настроить DNSSEC для своих зон. (К сожалению, за прошедшие десять лет слишком многое изменилось, а в результате перемен – утрачена масса полезных исторических веб-страниц, поэтому не могу привести ссылку на текст исходной новости; впрочем, копию пока что можно найти в web.archive.ru.)

Вообще, если посмотреть на сайт под доменом nox.su, то там сказано, что “криптографическая информация, соответствующая домену nox.su, внесена в файл зоны .su 23.11.2011” – то есть, ровно 11 лет назад и годом ранее, чем доступ к DNSSEC появился у упомянутых регистраторов. Это объясняется тем, что с nox.su мне помогли специалисты ТЦИ и RU-CENTER (большая им благодарность!): соответствующую DS-запись в реестр внесли, так сказать, в обход общедоступного интерфейса.

За эти годы DNSSEC не обрела особой популярности. Не только в российских доменах, но и во всей глобальной DNS. Сейчас в зоне .ru лишь около 6 тыс. имён с DS-записью (статистика по другим TLD – картину улучшает не сильно). В моде другие направления и другие этапы доставки данных, а в качестве едва ли не единственного метода защиты информации, на прикладном уровне, используется TLS.

Например, если говорить про DNS, то это DoH (DNS-over-HTTPS) и DoT (DNS-over-TLS). Естественно, эти технологии не позволяют, на уровне клиента, проверить подлинность данных именно DNS-ответа, однако делают возможной аутентификацию узла-источника, который эти данные принёс (DNS-резолвер), защищают канал передачи от прослушивания и подмены. Обычно, всё это доступно только на “последней миле” (то есть, от резолвера до клиента). Использование DoH/DoT не отменяет, конечно, возможности проверки DNSSEC, как и не решает основной задачи DNSSEC – подтверждения подлинности адресной информации.



Комментировать »

В ноябре 2007 года на dxdt.ru выходили записки, касающиеся, например, современности авиации, а также технических аспектов радиолокации. Вот небольшая записка про систему стабилизации NOTAR:

Есть и относительно новая схема стабилизации вращения – NOTAR (от англ. No Tail Rotor), которая, несмотря на то что увековечена в фильмах о Джеймсе Бонде, в широких кругах известна мало.

А вот познавательная заметка про Активные Фазированные Антенные Решётки (АФАР), которая востребована и сейчас:

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



Комментировать »

Выпустил ежегодное обновление технического описания протокола TLS. Каких-то больших дополнений в этом году не вышло, но актуализировал весь текст. (Есть, впрочем, очень краткое новое приложение (В), посвящённое ГОСТ-TLS.)



Комментарии (2) »

Certificate Transparency – это набор связанных с иерархией Удостоверяющих Центров (УЦ) TLS технологий, который позволяет вести специальные логи выпускаемых и выпущенных сертификатов. Предполагается, что логи общедоступны, а их наличие позволит обнаружить сертификаты, выпущенные с нарушением правил. Чтобы усилить действие Certificate Transparency (CT), браузеры (или другие программы, которые выполняют валидацию сертификатов) могут требовать подтверждения того, что конкретный сертификат был учтён в том или ином логе CT. Удобная реализация такого требования подразумевает наличие некоторых подписанных ключами логов меток в составе самого сертификата. Такие метки называются SCT – Signed Certificate Timestamp.

Метку SCT выдаёт оператор CT-лога в ответ на добавление сертификата в лог. Когда Certificate Transparency первой версии только проектировали, то этот момент, к сожалению, не учитывали. Поэтому проявилась проблема “курицы и яйца”: чтобы выпустить сертификат с SCT-меткой – нужно получить метку, а чтобы получить метку – нужно выпустить сертификат (для того, чтобы отправить его в лог). В качестве некоторого “обходного решения” (“костыля” – скажут те, кто “хорошо в теме”) предложили ввести пресертификаты.

Пресертификат – он такой же, как и TLS-сертификат, но содержит специальное расширение (Poison), которое отмечено как критически важное (Critical), но при этом не должно распознаваться обычным валидатором. Хитрость, на которую делается расчёт, состоит в том, что, согласно рекомендациям, в случае обнаружения неизвестного расширения с флагом Critical процедура валидации должна считать сертификат не валидным. Все прочие поля пресертификата в точности совпадают с соответствующими полями сертификата, в этом весь смысл. Однако “отравленный” пресертификат как бы нельзя использовать на практике для аутентификации. И, обычно, это работает. Но, конечно, полагать, что все разнообразные валидаторы строго следуют рекомендациям по обработке расширений – слишком смело.

Тем не менее, пресертификаты широко используются в CT: УЦ, готовясь выпустить сертификат с SCT-меткой, прежде генерирует и подписывает пресертификат с теми же параметрами (имя, серийный номер и т.д.), но с poison-расширением, отправляет пресертификат в CT-лог, получает в ответ метку с подписью лога, которую уже размещает в полноценный сертификат. Таким образом в логе возникает отметка о пресертификате, которая позволяет получить все содержательные данные о сертификате. В сертификате же появляется SCT-метка, подтверждающая, что оператор лога видел сведения о сертификате. Валидность метки может проверить валидирующая программа – для проверки испрользуется ключ лога. Этот процесс нарушает рекомендации по работе УЦ, поскольку запрещено выпускать два сертификата с одним серийным номером (и одним именем УЦ), но этот момент принято выносить за скобки.

Впрочем, во второй версии Certificate Transparency от пресертификатов отказались – для размещения сведений о сертификате используются сообщения другого формата, их формирование не требует выпуска как бы настоящего, но “испорченного” сертификата.



Комментировать »
Навигация по запискам: Раньше »