Alerts ошибок

В расширении протокола определены новые Alerts ошибок, использующиеся вместе с данными расширениями TLS.

Во избежание нарушения работы существующих клиентов и серверов эти Alerts не должны посылаться до тех пор, пока отправляющий их участник не получит расширенное сообщение Hello от другого участника.

• unsupported_extension – данный Alert посылается клиентом, который получил расширенный Server Hello, содержащий расширение, которое он не указывал в соответствующем Client Hello. Данное сообщение всегда фатально.
• unrecognized_name – данный Alert посылается сервером, который получил запрос с расширением server_name, но не распознал имя сервера. Данное сообщение может быть фатальным.
• certificate_unobtainable – данный Alert посылается сервером, который не может получить цепочку сертификатов из URL, предоставленного клиентом. Данное сообщение может быть фатальным – например, если серверу требуется аутентификация клиента для продолжения Рукопожатия и сервер не может восстановить цепочку сертификатов, он может послать фатальный Alert.
• bad_certificate_status_response – данный Alert посылается клиентом, который получил ответ с недействительным статусом сертификата. Данное сообщение всегда фатально.
• bad_certificate_hash_value – данный Alert посылается сервером, если хэш сертификата не соответствует предоставленному клиентом certificate_hash. Данное сообщение всегда фатально.

Процедура определения новых расширений

Традиционно IANA руководит определением новых значений, RFCs обычно определяют процедуру, используемую IANA. Однако могут возникнуть трудности при взаимодействии в данном протоколе между новыми и существующими возможностями, что может привести к снижению общей безопасности.

Следовательно, запросы на определение новых расширений должны утверждаться стандартными действиями IETF.

При определении новых расширений следует помнить:

• Все расширения следуют соглашению, в соответствии с которым для каждого расширения, которое запросил клиент и которое понимает сервер, сервер отвечает расширением того же типа.
• Расширения должны быть разработаны с учетом того, чтобы предотвращать атаки, связанные с манипулированием сообщениями Рукопожатия.

Часто бывает достаточно того, что поля расширения включаются в вычисление хэша в сообщении Finished. Всегда следует помнить, что пока Рукопожатие не аутентифицировано, активные атакующие могут модифицировать сообщения и вставить, удалить или заменить расширения.

• Технически возможно использовать расширения для изменения главных аспектов разработки TLS, например при разработке переговоров о наборе шифрования. Этого делать не рекомендуется, лучше определить новую версию TLS, так как алгоритмы Рукопожатия TLS имеют специальную защиту против атак rollback, основанных на номере версии, и возможность обратной передачи версии следует тщательно обдумать.

Обсуждение проблем безопасности

Проанализируем безопасность для каждого расширения, определенного в данном документе.

Безопасность server_name

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

Обязательно нужно гарантировать, что не происходит переполнения буфера, независимо от значения поля длины в server_name.

Хотя в настоящий момент неконкретизировано представление для интернационализации hostnames в расширении server_name, это не связано с проблемами безопасности, сопряженными с использованием интернационализированных hostnames – в частности, "выдуманными" именами, которые неотличимы от другого имени при просмотре или печати. Рекомендуется, чтобы сертификаты сервера не выпускались для интернационализированных hostnames, если существует риск выдуманных имен.

Безопасность max_fragment_length

Максимальная длина фрагмента должна учитываться уже сообщениями Рукопожатия. Однако это не приводит к каким-то дополнительным проблемам безопасности, так как существует требование, чтобы реализации имели возможность фрагментировать сообщения Рукопожатия.

Реальная максимальная длина фрагмента зависит от набора алгоритмов шифрования и метода сжатия. Это должно учитываться и при определении размера буферов и проверки буфера на предмет переполнения.

Безопасность client_certificate_url

Для данного расширения существует две проблемы.

Первая проблема связана с тем, что необходимо определить, должен ли клиент включать хэши сертификатов при посылке URLs сертификатов.

Если в аутентификации клиента используется *without* в расширении client_certificate_url, цепочка сертификатов клиента охватывается хэшем сообщения Finished. Цель включения хэшей и проверки их при получении цепочки сертификатов состоит в том, чтобы гарантировать, что определенное свойство, указанное в данном расширении, используется, например, что вся информация в цепочке сертификатов, полученная сервером, соответствует той, что посылал клиент.

С другой стороны, у клиента могут быть ежедневно выпускаемые сертификаты, которые хранятся по фиксированному URL, и нет необходимости предоставлять их клиенту. Клиенты, которые решили опускать хэши сертификатов, должны учитывать возможность атак, при которых злоумышленник посылает действительный сертификат ключа клиента, отличный от сертификата, который предоставляет клиент.

Вторая проблема состоит в том, что для client_certificate_url сервер начинает действовать от имени клиента. Таким образом сервер становится источником проблем, связанных с безопасностью, как и клиент для схемы с URL. Кроме того, следует помнить, что клиент может попытаться заставить сервер соединяться с некоторым, возможно несуществующим, URL.

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

Заметим, что сервер может быть расположен за firewall или иметь возможность доступа к хостам, которые не имеют прямого выхода в Internet. Это может обострить потенциальные проблемы безопасности и проблемы, связанные с отказом сервиса, при существовании внутренних хостов, от которых требуется получать подтверждение и которые могут быть недоступны.

Таким образом, рекомендуется, чтобы необходимость расширения client_certificate_url указывалась администратором сервера, а не по умолчанию.

URLs, которые указывают порты, отличные от заданных по умолчанию, могут иметь различные проблемы, так же, как и очень длинные URLs (что может быть связано с переполнением буфера).

Кроме того, следует заметить, что в Internet часто используются НТТР кэширующие proxy, и некоторые из них не проверяют самую последнюю версию. Если запрос, использующий НТТР (или другой кэширующий протокол), сконфигурирован неправильно или прерван proxy, proxy сервер может возвратить ответ, не соответствующий текущему запросу.

Безопасность trusted_ca_keys

В некоторых случаях ключи корневых СА, которые предоставил клиент, могут рассматриваться как конфиденциальная информация. Следовательно, ключ корневого СА в расширении должен применяться с осторожностью.

Использование в качестве альтернативы SHA-1 хэшей сертификатов гарантирует недвусмысленность каждого сертификата.

Безопасность truncated_hmac

Очевидно, что урезанные МАСs в целом являются более слабыми, чем полные МАСs. Тем не менее, на сегодня неизвестны особенно уязвимые места для НМАС как с MD5, так и с SHA-1, урезанных до 80 бит.

Заметим, что длина выхода НМАС не должна быть такой же, как длина ключа симметричного шифрования, так как подделка значений МАС не может быть выполнена off-line: в TLS единственный неверный МАС приводит к немедленному завершению сессии TLS.

Безопасность status_request

Если клиент запросил ответы OCSP, он должен предполагать, что сервер атакующего, используя скомпрометированный ключ, может притвориться, будто он не поддерживает расширение. Клиент, которому требуется проверка действительности сертификатов с помощью OCSP, должен либо сам контактировать с сервером OCSP, либо прервать Рукопожатие.

Использование расширения запроса nonce OCSP может усилить защиту в отношении атак, при которых осуществляется попытка повторить ответы OCSP.