dxdt.blog: занимательный интернет-журнал

Кстати, в продолжение Certificate Transparency. Регулярно приходится сталкиваться с вопросами или предположениями относительно того или иного TLS-сертификата, которые сопровождаются недостаточным количеством “иллюстративных” данных. (Эта записка – рекомендации для обычных пользователей.)

Предположим, что вы где-то встретили или обнаружили “подозрительный TLS-сертификат” и хотите получить комментарии специалиста про этот сертификат. Как поступить?

Прежде всего: необходимо сохранить сам файл сертификата непосредственно и полностью. Скриншот окна Windows с информацией “об издателе” и со сроками действия – никак не позволяет что-то содержательное сказать о сертификате: по этим данным даже нельзя судить о том, разные сертификаты вы просматриваете или один и тот же. Сохранить сертификат можно при помощи функции экспорта. К сожалению, реализации этой функции существенно различаются от приложения к приложению. Например, в браузере нужно кликнуть на “замочек в адресной строке” или на вкладку панели веб-разработчика, соответствующую настройкам безопасности сайта, или ещё куда-то, но логика данного действия общая – нужно найти, где сертификат сервера (веб-сайта) экспортируется в файл. Файл может иметь разные форматы (Base64, “двоичный”) и разные расширения в имени (.pem, .cer, .der, .bin, .cert и др.), но это, обычно, не важно – для специалиста это редко является проблемой. Главное – получить сам сертификат полностью в файле. Если функция экспорта позволяет сохранить “цепочку сертификатов” – тем лучше, сохраните цепочку. Основная причина, по которой нужен именно файл, в том, что сертификат содержит значение подписи, а это значение является доказательством того, что сертификат действительно был выпущен и подписан с использованием того или иного ключа. Кроме того – можно удобным способом просматривать все поля сертификата (серийный номер, расширения, ключ и пр.).

Если вам по каким-то причинам удаётся просмотреть только значения конкретных полей сертификата, то, во-первых, нужно сразу отметить, что ценной информации будет очень мало, и, во-вторых, попытаться сохранить серийный номер, отпечаток сертификата (значение хеш-функции для сертификата), имена, – то есть, название УЦ и имя, для которого сертификат выпущен (Issuer, Subject, Subject Alternative Name), – значение ключа (или отпечаток ключа; в сертификате публикуется открытый ключ) и тип криптосистемы, значение подписи с указанием на тип криптосистемы, сроки действия и сведения о цепочке сертификатов (серийные номера, имена, отпечатки), использованной для валидации.

Но, опять же, файла сертификата эта информация не заменит. Сохраняйте и показывайте сертификат в файле (необходимая оговорка: в теории, конкретный сертификат, который встречен “где-то на сайте”, может содержать сведения о вашем подключении к этому сайту, однако, это редкая ситуация).

На сайте ТЦИ (Технический Центр Интернет) опубликована моя статья о технологии Certificate Transparency (CT) и её роли в современном Интернете. Статья рассказывает не столько о базовых принципах построения CT (они достаточно широко известны), сколько об особенностях реального применения данной технологии – о проблемах, связанных с неверной интерпретацией значения меток в сертификатах, о полноте CT-логов.

Certificate Transparency […] лишь предоставляет инструмент для наблюдения за деятельностью УЦ, но никак не ограничивает эту деятельность на техническом уровне.

Ещё немного окололингвистических рассуждений. Про Чарльза и Карла. Как известно, прескриптивный подход привёл к тому, что Чарльз (принц) превратился в русскоязычном пространстве в Карла (короля). Этому есть историческое словарное обоснование (“имена монархов некоторых стран – на немецкий манер”), но замена имени произошла несколько неожиданным для современной аудитории образом, тем более, что Чарльз регулярно упоминался в русскоязычной прессе. Этот процесс, существенным образом связанный со СМИ, занятно отразился в русскоязычной “Википедии”: там, например, пишут, буквально, что принц “Чарльз будет использовать тронное имя Карл III”. Это создаёт расщепление смысла, которого в изначальном событии не было (подобное “слоение” – важная особенность “Википедии”). Конечно, если придерживаться предложенной схемы именования, то написать следовало бы, что это принц Карл (в скобках: Чарльз) будет использовать тронное имя Карл III.

Кстати, даже в немецкой прессе современный Чарльз остался Charles (то есть, в английском варианте), а в самой Великобритании эпоха правления называется (new) Carolean era, однако Чарльз там всё равно король Чарльз (не Карл, естественно, хоть это, понятно, одно и то же имя, а в английском расщепить его на два представления довольно сложно, как бы ни хотелось). При этом подходящих исторических периодов, названия которых образуются от карлов (латинское влияние), в локальной англоязычной традиции есть два, и их предлагается не перепутать: Caroline/Carolean.

На сайте Ватиканской апостольской библиотеки опубликовано большое количество старых манускриптов, в неплохо оцифрованном виде. Например, текст “Начал” Евклида, датируемый девятым веком. Конечно, девятый век нашей эры, но, как считается, это самый старый из известных подробный текст, в который не было внесено позднейших (относительно Евклида) изменений и дополнений. Посмотрим на фрагмент (обычно цитируют страницу с теоремой Пифагора, поэтому выберем другую – книга первая, Предложение 29 ):

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

То есть, для того, чтобы начать читать первоисточники, потребуется совершить экскурс в палеографию. Так, данный манускрипт не только использует алфавит, начертания букв которого не очень-то похожи на αβγ, но и насыщен специальными лигатурами и сокращениями, которые использовали при записи древнегреческого в соответствующий период (в данном случае – 9-10 вв., как я понимаю; Евклид был древним уже тогда).

Посмотрим, как выглядит “перевод” на более “привычный” древнегреческий. Я попробовал приписать соответствующий текст в режиме, близком к “буква под буквой”, насколько позволяют особенности исходника – потому что, например, ει схлопнуто в одну лигатуру. (В Предложении 29 речь про накрест лежащие углы, образуемые прямой, падающей на параллельные прямые, поэтому, как минимум, одно слово нетрудно узнать.)

Здесь на поле указан номер предложения: ΚΘ, под чертой, что имеет числовое значение 29.

Пришлось дополнительно притянуть μ к π, потому что оригинальное начертание имеет совсем другую ширину – не только хвост мю, но у пи широкая шляпа (к тому же, сыграла узкая йота).

Слово γωνίας (“углы”) здесь разделено между строками, пришлось дорисовать чёрточку. Обратите внимание, что не только λ выглядит необычно (про π уже можно не напоминать), но и ν слишком похожа на μ (спасает только хвостик справа, который, кстати, длинен не во всех случаях).

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

Ещё один короткий комментарий на тему форм английских слов и скрытого расслоения смыслов, полностью исчезающего при переходах между языками. В английском языке у слова antenna (антенна; в британском – aerial) две формы множественного числа: antennae и antennas. Форма antennae – кажется естественной, а вот antennas – для “литературного взгляда” смотрится несколько странно, но, тем не менее, тоже верная форма. Почему? Дело в том, что если речь идёт об антеннах для приёма радиосигнала, то использование формы antennas – сразу выдаёт в вас разбирающегося в вопросе человека, потому что antennae – это, с точки зрения радиоинженера, да и продвинутого филолога, усы на голове насекомого (но, впрочем, эту форму допустимо использовать и в электромагнитном контексте, вряд ли кто-то осудит строго).

Один из оксфордских словарей (Oxford Advanced Learner’s Dictionary) относит слово miaow к уровню C1 (это высокий уровень владения языком). Казалось бы, здесь miaow – это “мяу!”, а именно – подражание разговору котов. Почему же C1? Потому, что только на высоком уровне освоения языка обязательно узнавать подобные слова. Естественно, слово cat, в значении “кошка”, тот же словарь относит к начальному уровню A1. Но попробуйте показать начинающему изучать английский (как иностранный) слово miaow – скорее всего, с пониманием возникнут трудности; а вот на уровне C1 – трудностей возникать не должно.

Занятно, что moo (мычание коров) тот же словарь относит уже к уровню C2 (это максимально возможный, по данной шкале, уровень владения языком). Дети изучают, что “коровка говорит: му-у!”, в том числе, дети, для которых английский является родным и первым языком – moo. Это так. Но для тех, кто осваивает иностранный английский, конечно, moo может показаться незнакомым загадочным словом, поскольку для них и коровка могла говорить что-то другое, и сопоставить иностранное слово, записанное незнакомыми буквами, со знакомым звукоподражанием, в общем случае, не так-то просто. Кроме того, сортировка по шкале внутри одного языка должна происходить более или менее одинаковым способом для всех животных звукоподражаний, но с учётом того, что с коровой многие городские жители сталкиваются реже.

Теперь, что касается mew. Это слово здесь тоже означает “мяу”, но без восклицательного знака (даже, скорее, “миу”). Mew – как минимум, в британском английском, – тише и мягче, чем miaow (meow), поэтому может использоваться иначе.

На dxdt.ru много лет работает сервис, который позволяет отрисовывать предложения LaTeX, переданные в параметрах URL, в картинки GIF, тут же возвращаемые сервером – то есть, можно указать в коде страницы тег img и результат запроса картинки по URL из src отобразит формулу. Раньше это было очень актуально в вебе, сейчас – менее актуально: появились другие технологии для отображения формул на веб-страницах. Тем не менее, сервис продолжает использоваться, потому что на многих внешних сайтах и форумах указаны URL картинок. Я даже оставил для URL сервиса рисования LaTeX возможность использовать HTTP – без S. Это связано с тем, что старые ссылки, естественно, повсеместно используют http://, а HTTP-перенаправление, в теории, может помешать отображению картинки. Но, наверное, всё же придётся добавить перенаправление с заменой протокола на HTTPS и для этих URL. В принципе, современные браузеры могли бы автоматически пробовать подключиться по HTTPS, тем более, что в DNS присутствует соответствующая запись. Но есть сомнения насчёт вспомогательных сервисов, которые могут извлекать картинку по HTTP и потом куда-то её копировать локально – не факт, что они умеют в HTTPS.

Интересно, что иногда ссылку указывали даже с префиксом www., хотя, насколько я помню, он никогда не был основным адресом для сайта; видимо, вводили автоматически. Но с www. – несколько проще, там изначально перенаправление на dxdt.ru, как и сейчас, поэтому, если раньше работало, то должно сохраниться. Собственно, с префикса www. сейчас веб-сервер перенаправляет именно на https://.

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

С пресертификатами связано множество весьма неочевидных аспектов. Так, единственный смысл в пресертификатах – это создание “костыля” для получения метки времени от сервиса CT-лога, чтобы включить эту метку в сертификат. Метка (она называется SCT) связана с конкретным пресертификатом и подписывается лог-сервисом. Но включается метка уже в сертификат, который от пресертификата отличается в некоторых деталях. Напрмер, сертификат не должен содержать poison-расширение. При валидации сертификата проверяется и SCT-метка (ну, если валидирующая сторона, – скажем, браузер, – хочет проверить метку). Понятно, что если подпись вычислена для другого набора данных (пресертификат), то она не сойдётся. Как же устроены процессы подписывания и проверки подписи SCT-метки? Они устроены непросто.

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

Ракета в кубе:

Десять лет назад, в апреле 2013, я рассуждал о том, как бы перевести dxdt.ru на HTTPS в качестве основного протокола – процитирую ту краткую заметку полностью:

Можно бы перевести dxdt.ru целиком на HTTPS, но WordPress что-то не готов – генерирует для изображений небезопасные ссылки. Вообще, с HTTPS есть ещё одна проблема: поисковики. Я замечал, что Google умеет не только ходить по HTTPS, но и индексировать такие страницы, а вот насчёт “Яндекса” есть сомнения. В любом случае, ссылки для поисковиков станут другими, так как придётся их роботов перенаправлять с http на https, что ботов не порадует. Можно, конечно, вообще на другой домен всё перенести. Но это, думаю, перебор. Поэтому пока останемся на HTTP, хоть это и прошлый век.

HTTPS, конечно, тогда уже поддерживался на dxdt.ru, но без перенаправления и с сертификатом моего собственного УЦ. Уже в следующем, 2014, году я написал небольшой скрипт, который скорректировал все ссылки с указанием протокола прямо в дампе БД, что позволило победить эффекты WordPress, после чего HTTPS стал основным протоколом dxdt.ru. К проблемам с поисковиками такой переход не привёл, поскольку “Яндекс” тоже уже умел ходить по HTTPS, а сайты с безопасным протоколом чуть позже и ранжировать стали выше.

Сервис проверки настроек интернет-узлов ТЦИ теперь поддерживает TLS-сертификаты НУЦ и ТЦИ в качестве доверенных корневых сертификатов. То есть, теперь узлы, которые используют серверные сертификаты от этих корней, будут получать баллы рейтинга так же, как и с другими доверенными сертификатами.