Я размещаю сайт, который позволяет пользователям подключаться по протоколу HTTP или HTTPS. Конфигурация apache по умолчанию создает отдельный файл журнала для запроса, сделанного через HTTPS, с двумя дополнительными сведениями, а именно протоколом (например, TLSv1) и шифром (например, DHE-RSA-CAMELLIA256-SHA). Мне было интересно, в чем польза регистрации этих двух дополнительных сведений, или мне следует просто объединить их с журналом доступа без этих двух столбцов для упрощения устранения неполадок.
Для максимальной совместимости с браузерами Apache позволяет использовать широкий спектр протоколов и шифров HTTPS.
Однако, если вы хотите обеспечить хорошую безопасность своего HTTPS-трафика, вам нужно отключить некоторые из этих протоколов (например, SSLv2) и шифров (например, RC2-CBC-MD5). Особенно с течением времени, поскольку против некоторых протоколов / шифров появляется все больше и больше эффективных атак. Браузеры обычно подключаются к более надежному протоколу / шифру, если они могут, и этот протокол / шифр будет отображаться в ваших журналах.
Потенциальная проблема заключается в том, что если вы отключите эти менее безопасные протоколы / шифры, И браузеры вашей пользовательской базы не поддерживают разрешенные вами протоколы / шифры, тогда некоторые люди, просматривающие ваш сайт (со старым ПК или мобильным телефоном ) может вообще не получить HTTPS-соединение! В частности, если, подобно Google или другим сайтам, вы заставляете людей использовать только HTTPS из соображений безопасности (например, для защиты файлов cookie сеанса от прослушивания беспроводных сетей), это может быть проблемой.
Как вы узнаете, безопасно ли отключить их; как вы могли оценить этот бизнес-риск? Что ж, если вы зарегистрировали фактические шифры, используемые вашей пользовательской базой, вы могли бы легко увидеть, пострадали ли ваши клиенты или какой процент трафика будет затронут при удалении доступа к этим протоколам / шифрам. Или, по крайней мере, получить хорошее представление об этом воздействии. Браузеры обычно подключаются к более надежному протоколу / шифру, если они могут, и этот протокол / шифр будет отображаться в ваших журналах.
(Существуют также более тонкие причины, например, убедиться, что ваш сервер использует протокол / шифр, который вы думаете, и по причинам судебной экспертизы, если есть какая-то атака с понижением уровня MITM SSL.)
У меня нет твердого мнения о том, чтобы журналы были объединены или разделены, но, регистрируя вещи отдельно, вы можете получить небольшой журнал, который фокусируется исключительно на разрешении этого анализа, а не на увязке с ним вашего основного большого журнала. И он может вращаться с другой частотой и т. Д.