Поделюсь настройками TLS на веб-сервере dxdt.ru. Я использую связку Apache+mod_ssl (стандартное решение). Важнейшие параметры – это используемые протоколы, “шифронаборы” (Cipher Suites – часто переводят как “наборы шифров”), а также их приоритет. Например, сейчас не рекомендуется использовать SSLv3 (и более ранние версии, которые, конечно, экзотика, но всё ещё встречаются в “живой природе”). Соответственно, в ssl.conf (файл конфигурации mod_ssl) для хоста dxdt.ru указаны следующие строки:

SSLProtocol -ALL +TLSv1 +TLSv1.1 +TLSv1.2
SSLHonorCipherOrder on
SSLCipherSuite “EECDH+AESGCM EDH+AESGCM EECDH+AES EDH+aRSA !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4”

Первая директива (SSLProtocol) разрешает только TLS (в трёх версиях, как несложно догадаться). Протоколы семейства SSL – не поддерживаем. Вторая директива (SSLHonorCipherOrder) указывает, что mod_ssl должен использовать приоритеты наборов шифров, заданные сервером (а не клиентом, то есть браузеру не удастся навязать свои предпочтения).

Директива SSLCipherSuite – это самое сложное место в настройках. Она определяет допустимые криптографические наборы (“шифронаборы”: алгоритмы обмена ключами и аутентификации, шифр, режим шифрования, алгоритм дайджеста). Условные имена наборов разделены пробелами. Конкретный набор согласуется клиентом и сервером во время установления соединения. Если договориться о подходящем наборе не удалось – TLS-соединение не устанавливается (именно это и происходит в случае IE8 под Windows XP).

В mod_ssl используются сокращённые имена для обозначения групп шифронаборов. Например: EECDH+AESGCM означает, что для генерации сеансового ключа будет использоваться алгоритм Ephemeral elliptic-curve Diffie-Hellman (разновидность алгоритма Диффи-Хеллмана на эллиптических кривых), а в роли алгоритма шифрования выступит AES в режиме GCM (Galois/Counter Mode – Режим счётчика с “аутентификацией Галуа”: один из современных “продвинутых” режимов блочных шифров, обеспечивающий, в том числе, аутентификацию данных; Галуа там возникает потому, что алгоритм аутентификации работает в конечном поле).

Сайт dxdt.ru использует серверный сертификат с ключом RSA; соответственно, аутентификацию сеансовых ключей можно проводить только при помощи криптосистемы RSA. Это некоторым образом экономит нам пространство в конфигурационной строке mod_ssl: вовсе не обязательно вписывать туда подробные указания вроде EECDH+ECDSA+AESGCM, как нередко рекомендуют, – DSA всё равно не поддерживается.

Несложно догадаться, что подстроки в SSLCipherSuite, начинающиеся с ‘!’, обозначают запрет на использование определённых криптосистем или криптографических примитивов. Всегда полезно прямо запретить заведомо неподходящие алгоритмы. Отмечу, что, в соответствии с современными традициями, запрещён RC4 (хотя он всё равно не предлагался бы сервером с указанными шифронаборами – не подходит).

Update (23/12/2014): в комментариях подсказали изящный вариант, с отключением всего ненужного одной директивой -ALL в SSLCipherSuite; такой вариант требует более точного описания шифронаборов, но зато он лаконичен:

SSLCipherSuite “-ALL:EECDH+aRSA+AESGCM:EDH+aRSA+AESGCM:EECDH+aRSA+AES:EDH+aRSA+AES”

(Обратите внимание, что пробелы заменены на двоеточия.)

В HTTP-ответ добавлено поле HSTS (HTTP Strict Transport Security – требование “принудительной безопасности” для HTTP):

Header add Strict-Transport-Security “max-age=15552000”

Данное поле означает, что, грубо говоря, браузер должен запомнить, что к данному сайту доступ необходимо осуществлять только по HTTPS, в течение времени, указанного в параметре max-age поля HSTS. Это позволяет защититься от множества атак, основанных на подмене протокола HTTPS на HTTP.

Вот. Так работает TLS на dxdt.ru.



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

На снимке, собранном из четырёх фотографий аппарата Rosetta, – комета Чурюмова-Герасименко, достаточно крупным планом:

67P/C-G, Credit: ESA

Источник фото – блог ESA, там же есть некоторые подробности и комментарии (англ.)



Comments Off on Фото: комета Чурюмова-Герасименко

На фото – штатовский истребитель F-35C, во время испытаний:

F-35C

(Фото: Lockheed Martin.)

Это посадка на авианосец, с аэрофинишёром. Хорошо виден тормозной гак, современной конструкции (с гаком, как известно, были проблемы: его пришлось исправлять).

F-35C hook



Comments Off on Фото: F-35C и авианосец

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

Неясно, как так могло получиться, но атаковавшим ICANN удалось получить администраторский доступ к некоторым сервисам. Это удивительно потому, что авторизация в системах подобного уровня должна бы быть защищена от простого перехвата почты сотрудников. Хотя, конечно, никто не застрахован от ошибок. В итоге, из сервиса Centralized Zone Data System – это полезный инструмент, позволяющий получать файлы зон доменов New gTLD, – утекли контактные данные пользователей, а также пароли, но в хэшированном виде.

(Кстати, самое громкое дело было бы, если бы у ICANN, а точнее – у IANA и VeriSign, утянули бы секретный корневой ключ KSK от DNSSEC. Понятно, что, в текущей ситуации с поддержкой DNSSEC, катастрофы бы не случилось, но случай был бы весьма показательный. Дело в том, что до сих пор не разработана процедура ротации корневого ключа KSK, так что DNSSEC, разве что, оставалось бы просто выключить.)



Comments Off on Взлом сервисов ICANN

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

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



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

С DNSSEC связано немалое число хитрых особенностей, которые не так очевидны, как базовые принципы этой технологии. Например, часто приходится сталкиваться с неверной трактовкой назначения DS-записи. Между тем, DS-запись (Delegation Signer) – важнейший элемент DNSSEC, так как с её помощью выстраиваются цепочки доверия. Эта запись указывает на ключ, который зона, расположенная на уровень ниже (делегируемая зона), должна использовать для удостоверения (подписывания) адресной информации.

Одна из хитростей состоит в том, что если в родительской (делегирующей) доменной зоне присутствует DS-запись для дочерней (делегируемой) зоны, и родительская зона безопасна (то есть, подписана DNSSEC), то это означает, что дочерняя зона тоже должна быть безопасной. То есть, валидирующий резолвер ожидает, что дочерняя зона содержит, во-первых, подходящие к DS ключи, нужные для проверки подписей, во-вторых – сами подписи на ответах об адресации внутри зоны. Соответственно, если DS-запись присутствует, а дочерняя зона не подписана, валидирующий резолвер будет возвращать сообщение об ошибке. Это совершенно правильное поведение, потому что иначе смысла в DNSSEC нет: подделать ответы без подписей не составляет труда; если резолвер не имеет возможности отличить подписанную зону от неподписанной по наличию DS-записи в доверенной (безопасной) зоне, то подписи можно вообще не проверять.

Другой важный момент: если авторитативный сервер родительской (делегирующей) зоны, подписанной DNSSEC, отвечает на рекурсивный запрос списком NS-ов и DS-записью, то подпись ставится только на значение DS. Казалось бы, нужно подписать и список NS-ов – как иначе узнать, что они правильные? Но если у нас есть доверенная DS-запись, то нет разницы, с каких серверов мы получим дополнительную информацию: главное, чтобы совпал ключ и его отпечаток в DS, а также сошлись значения подписей. Тут работает основной принцип DNSSEC: если данные об адресации аутентифицированы, то не имеет значения, из какого источника они получены.

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

Google Public DNS для зон, имеющих DS-запись, но не подписанных, возвращает ошибку (SERVFAIL), вне зависимости от того, какова природа этих DS-записей. Другие валидирующие резолверы ведут себя иначе. Например BIND, обнаружив неизвестный алгоритм генерации DS, считает, что DS-записи в родительской зоне вовсе нет (что не совсем корректно, но с практической точки зрения оправдано, и, конечно, соответствует рекомендациям RFC). Пример такого поведения можно наблюдать для зоны dotsu.su – здесь в .su специально указаны DS-записи с неизвестным алгоритмом (9).



Comments Off on Техническое: DS-запись в DNSSEC

На фото ниже – момент подготовки космического корабля Orion к установке теплового щита. Собственно, это часть корабля, обитаемый модуль. Можно разглядеть особенности конструкции и размещения агрегатов.

Orion

(Исходное фото: Lockheed Martin.)



Comments Off on Фотофакт: космический корабль Orion, без обшивки

На страницах dxdt.ru немало заметок про РЛС. Правда, сейчас новые заметки на эту тему появляются всё реже. Нужно будет попытаться исправить ситуацию. А пока что – небольшая подборка из опубликованного:



Comments Off on Подборка заметок про РЛС

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

Хотя, многое зависит от схемотехники и логической организации накопителя. Удачное попадание молотка может выбить сразу кучу байтов (или хотя бы битов), соответствующих разным участкам большого файла. Но это если попадание удачное. В противном случае, если удалось восстановить карту размещения блоков, можно будет собрать много полезного из уцелевших элементов. Понятно, что данные о местоположении блоков и их отображении в последовательную структуру файлов – это самые важные данные. Предположим, что у нас полностью сохранён файл, имеющий объём в 100 мегабайт, но этот файл разрезан на небольшие блоки, которые перемешаны – как собрать их обратно, соединив в нужной последовательности? Особенно сложно проделать такую операцию для зашифрованного файла. Тем не менее, не исключено, что пары ударов молотка может не хватить – всё зависит от архитектуры накопителя.



Комментарии (7) »
Навигация по запискам: « Позже Раньше »