У меня есть сервер Tomcat 8.5, работающий на инстансе Amazon Linux EC2 Linux. Tomcat работает на порту 8443, и IPTables переназначает на него 443.
Я изменил предложение коннектора sslProtocol, указав протокол TLS 1.2. И это изменение не работает: он по-прежнему принимает TLS 1.0 и 1.1, а также 1.2. Кто-нибудь знает, в чем может быть проблема?
Коннектор выглядит так (конфиденциальная информация удалена):
<Connector port="8443" proxyPort="443" protocol="org.apache.coyote.http11.Http11NioProtocol"
compression="on" compressionMinSize="2048" noCompressionUserAgents="gozilla, traviata" compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,text/json,application/x-javascript,application/javascript,application/json"
maxThreads="1000" socket.appReadBufSize="1024" socket.appWriteBufSize="1024" bufferSize="1024" SSLEnabled="true" scheme="https" secure="true"
keystoreFile="/etc/tomcat8/dev.REDACTED.net.ks" keyAlias="REDACTED" ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA"
clientAuth="false" sslProtocol="TLSv1.2" />
(ранее предложение sslProtocol было sslProtocol = "TLS")
То же предложение «sslProtocol» отлично работает в теге коннектора сервера Tomcat 7, работающего на клиентской AS / 400, ограничивая его TLS 1.2.
Из документация для Connector (форматирование упрощено, потому что делать HTML в стеке слишком сложно)
sslProtocol Это псевдоним для атрибута sslProtocol элемента SSLHostConfig с именем hostName дефолт. Если этот элемент SSLHostConfig не определен явно, он будет создан.
и для SSLHostConfig (то же самое)
Только sslProtocol JSSE. Используемые протоколы SSL (одно значение может включать несколько протоколов - подробности см. В документации JVM). Если не указан, по умолчанию используется TLS. Допустимые значения могут быть получены из документации JVM для разрешенных значений для алгоритма при создании экземпляра SSLContext, например. Oracle Java 7. Примечание. Этот атрибут и протоколы частично совпадают.
Другими словами, это значение, переданное в SSLContext.getInstance(). Поскольку вы не идентифицируете свою Java, я буду использовать имена контекста для текущая версия Oracle LTS, 11 (курсив мой):
TLSv1.2 поддерживает RFC 5246: TLS версии 1.2; может поддерживать другие версии SSL / TLS
И реализация этого контекста в провайдере SunJSSE включает TLSv1 (что означает 1.0), TLSv1.1 и TLSv1.2 - другими словами, это означает "максимум 1.2 ". В более старых версиях Java он также включал SSLv3, но он был удален как небезопасный после атаки POODLE несколько лет назад. (Я люблю говорить« атака POODLE », это звучит так глупо. :-)
Атрибут, который выборочно контролирует список включенных протоколов protocols в SSLHostConfig - упоминается (кратко) в приведенной выше цитате - или эквивалентно, но написано по-другому sslEnabledProtocols в соединителе. В более старых версиях (до 8.5 «объединяли» конфигурации) это было SSLProtocol в коннекторе только при использовании OpenSSL / APR.
Тот же самый пункт sslProtocol прекрасно работает в теге коннектора сервера Tomcat 7, работающего на клиентской AS / 400, ограничивая его TLS 1.2.
AS / 400 почти наверняка использует IBM Java, а не Sun-now-Oracle-now-OpenJDK. IBM лицензировала исходный код от Sun еще когда и гарантирует совместимость со спецификацией Java, определенной Sun, которая явно не входит, и до сих пор это делают криптопровайдеры. У IBM есть свои собственные криптопровайдеры, которые отличаются (хотя функционально очень похожи на) Sun / Oracle / Open, поэтому, чтобы знать, что он делает для конкретных SSLContext, вам нужно найти документацию IBM на (или некоторых) веб-сайтах IBM, которые Я всегда считаю несудоходным. Это может реализовать TLSv1.2 как "минимум 1,2 ".
PS: у вас правда оба RSA и Сертификаты ECC в вашем хранилище ключей? Если нет, то большая часть той огромной ценности, которую вы используете для шифров, будет бесполезной, бесполезной тратой времени. Кроме того, ни один здравомыслящий клиент нигде не хочет использовать наборы шифров static-ECDH (или static-DH тоже). Вы понимаете очень важное различие между ECDH и ECDHE в терминологии TLS?
Правильный ответ пришел на выходных из списка пользователей Tomcat прямо от двух разработчиков:
sslEnabledProtocols = "TLSv1.2"