JEP 288: Disable SHA-1 Certificates

Аннотация

Улучшить конфигурацию безопасности JDK, предоставив более гибкий механизм отключения цепочек сертификатов X.509 с подписями на основе SHA-1.

Что не является целью

Цель механизма не в том, чтобы отключить все случаи использования сертификатов SHA-1. Ограничения распространяются только на цепочки сертификатов X.509, которые проверяются реализацией PKIX API CertPathValidator и CertPathBuilder и реализациями SunX509 и PKIX API TrustManagerFactory. Другие случаи использования сертификатов X.509 (разбор и т. д.) в JDK не затрагиваются. Сторонние реализации CertPathValidator, CertPathBuilder и TrustManagerFactory сами непосредственно отвечают за применение собственных ограничений.

Мотивация

Использование алгоритмов цифровой подписи на основе SHA-1 вызывает всё больше опасений с точки зрения безопасности из-за риска атак на основе коллизий. NIST в SP 800-57, Part 1 рекомендует больше не использовать SHA-1 для цифровой подписи данных. В документе CA/Browser Forum Baseline Requirements for Publicly-Trusted SSL Certificates указано, что начиная с 1 января 2016 года удостоверяющие центры не должны выпускать с использованием SHA-1 никакие сертификаты подчинённых удостоверяющих центров или сертификаты подписчиков. Другие производители программного обеспечения (Google, Microsoft, Mozilla, Apple) опубликовали планы отказа от SHA-1 в сертификатах. В JDK цепочки сертификатов X.509 используются для аутентификации серверов и клиентов в TLS, а также для проверки целостности и авторов подписанного кода.

Описание

Использование сертификатов SHA-1 продолжает сокращаться, особенно для публично доверенных серверов SSL/TLS (по состоянию на 3 марта 2017 года SHA-1 по-прежнему используют 0,0 % популярных SSL-сайтов). Однако многие предприятия используют частные удостоверяющие центры, которым, как правило, требуется больше времени, чтобы приспособиться к новым ограничениям на алгоритмы. Кроме того, код, ранее подписанный и снабжённый меткой времени с использованием сертификатов SHA-1, должен ещё некоторое время продолжать работать. Поэтому отключение всех сертификатов SHA-1 может нарушить работу многих приложений. Следовательно, этот JEP улучшит механизм ограничений на алгоритмы, чтобы можно было реализовывать более гибкие политики ограничения SHA-1.

В частности, в спецификацию свойства безопасности jdk.certpath.disabledAlgorithms были внесены следующие улучшения:

1. Новое ограничение jdkCA: если оно задано, алгоритм ограничивается, когда он используется в цепочке сертификатов, корнем которой является доверенный корневой сертификат (trust anchor), предустановленный в хранилище ключей JDK cacerts. Это условие не применяется к цепочкам сертификатов, корнем которых являются другие сертификаты, в том числе добавленные в хранилище ключей cacerts позднее. Также обратите внимание, что ограничение не применяется к самим доверенным корневым сертификатам, поскольку им доверяют напрямую.

2. Новое ограничение denyAfter: если оно задано, алгоритм ограничивается, когда он используется в цепочке сертификатов после указанной даты. Ограничение не применяется к доверенным корневым сертификатам, поскольку им доверяют напрямую. Кроме того, цепочки сертификатов для подписи кода, используемые в подписанных JAR-файлах, обрабатываются особым образом:

   a. если цепочка сертификатов используется с подписанным JAR-файлом без метки времени, она будет ограничена после указанной даты

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

3. Новое ограничение usage: если оно задано, алгоритм ограничивается, когда он используется в цепочке сертификатов для указанного назначения (или назначений). Изначально поддерживаются три назначения: TLSServer для цепочек сертификатов серверов TLS/SSL, TLSClient для цепочек сертификатов клиентов TLS/SSL и SignedJAR для цепочек сертификатов, используемых с подписанными JAR-файлами.

Спецификация свойства безопасности jdk.certpath.disabledAlgorithms после описанных выше улучшений выглядит так (определения каждого ограничения см. в файле java.security):

DisabledAlgorithms:
    " DisabledAlgorithm { , DisabledAlgorithm } "

DisabledAlgorithm:
    AlgorithmName [Constraint] { '&' Constraint }

AlgorithmName:
    (see below)

Constraint:
    KeySizeConstraint | CAConstraint | DenyAfterConstraint |
    UsageConstraint

KeySizeConstraint:
    keySize Operator KeyLength

Operator:
    <= | < | == | != | >= | >

KeyLength:
    Integer value of the algorithm's key length in bits

CAConstraint:
    jdkCA

DenyAfterConstraint:
    denyAfter YYYY-MM-DD

UsageConstraint: 
    usage [TLSServer] [TLSClient] [SignedJAR]

Кроме того, в спецификацию свойства безопасности jdk.jar.disabledAlgorithms были внесены следующие улучшения:

1. Новое ограничение denyAfter: если оно задано, алгоритм ограничивается, когда он используется в подписанном JAR-файле после указанной даты, следующим образом:

   a. если у JAR-файла нет метки времени, он будет ограничен (будет считаться неподписанным) после указанной даты

   b. если у JAR-файла есть метка времени, он не будет ограничен, если метка времени поставлена до указанной даты. Если метка времени JAR-файла поставлена после указанной даты, он будет ограничен.

Спецификация свойства безопасности jdk.jar.disabledAlgorithms после описанных выше улучшений выглядит так (определения каждого ограничения см. в файле java.security):

DisabledAlgorithms:
    " DisabledAlgorithm { , DisabledAlgorithm } "

DisabledAlgorithm:
    AlgorithmName [Constraint] { '&' Constraint }

AlgorithmName:
    (see below)

Constraint:
    KeySizeConstraint | DenyAfterConstraint

KeySizeConstraint:
    keySize Operator KeyLength

DenyAfterConstraint:
    denyAfter YYYY-MM-DD

Operator:
    <= | < | == | != | >= | >

KeyLength:
    Integer value of the algorithm's key length in bits

Вот несколько примеров:

Чтобы отключить сертификаты SHA-1, цепочки которых ведут к доверенным корневым сертификатам, предустановленным в файле cacerts, добавьте "SHA1 jdkCA" в свойство безопасности jdk.certpath.disabledAlgorithms:

jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, \
        DSA keySize < 1024, EC keySize < 224, SHA1 jdkCA

Чтобы отключить сертификаты SHA-1, которые используются для аутентификации серверов TLS и цепочки которых ведут к доверенным корневым сертификатам, предустановленным в файле cacerts, добавьте "SHA1 jdkCA & usage TLSServer" в свойство безопасности jdk.certpath.disabledAlgorithms:

jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, \
        DSA keySize < 1024, EC keySize < 224, SHA1 jdkCA & usage TLSServer

Чтобы отключить SHA-1 в подписанных JAR-файлах, за исключением JAR-файлов с меткой времени до 1 января 2017 года, добавьте "SHA1 usage SignedJAR & denyAfter 2017-01-01" в свойство безопасности jdk.certpath.disabledAlgorithms и "SHA1 denyAfter 2017-01-01" в свойство безопасности jdk.jar.disabledAlgorithms:

jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, \
        DSA keySize < 1024, EC keySize < 224, \
        SHA1 usage SignedJAR & denyAfter 2017-01-01

jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, \
        DSA keySize < 1024, SHA1 denyAfter 2017-01-01

Тестирование

Сейчас во многих регрессионных тестах библиотек безопасности используются сертификаты SHA-1. Эти тесты будут изменены так, чтобы снова включать SHA-1, или же сертификаты будут заменены сертификатами SHA-2.

Риски и допущения

В разделе «Описание» были описаны дополнительные ограничения, которые помогут снизить риск несовместимости в определённых сценариях использования. Мы также будем сообщать об изменениях через другие форумы и программы, чтобы пользователи знали о них и понимали, как настроить и протестировать свои приложения до того, как новые ограничения вступят в силу.

Зависимости

Этот JEP зависит от трёх улучшений существующего механизма ограничений на алгоритмы (8140422, 8154005, 8160655).