Сбой рукопожатия / отсутствие общих наборов шифров - SymmetricDS 3.1.5

Я обновляюсь с SymmetricDS (SDS) 2.5.13 до 3.1.5. У меня настроен TLS / HTTPS, и он работает должным образом в SDS 2.5.13. Однако, используя точно такие же сертификаты, файлы хранилища ключей / доверенных сертификатов и тот же JDK, я получаю следующую ошибку в SDS 3.1.5 в журнале оболочки службы (wrapper.log):

SEND TLSv1 ALERT: fatal, description = handshake_failure  
WRITE: TLSv1 Alert, length = 2  
called closeSocket()  
handling exception: javax.net.ssl.SSLHandshakeException: no cipher suites in common

У меня конфигурация с двумя узлами, один из которых настроен как сервер регистрации (родительский узел). Дочерний узел настроен на отправку и получение изменений. Я использую Sun (Oracle) JDK 7 update 5 с соответствующими файлами политики юрисдикции JCE Unlimited Strength (чтобы получить доступ к 256-битным шифрам).

Я использую SDS в автономной конфигурации в качестве службы Windows под сервером Server 2008. Брандмауэр Windows в настоящее время отключен.

Я передаю следующие параметры Java, связанные с TLS, в оболочку службы через файл sym_service.conf:

wrapper.java.additional.6=-Dsym.keystore.file=c:/java-keystore/bfvm01-w2ka.ks
wrapper.java.additional.7=-Djavax.net.ssl.keyStore=c:/java-keystore/bfvm01-w2ka.ks
wrapper.java.additional.8=-Djavax.net.ssl.trustStore=c:/java-keystore/bfvm01-w2ka.ks
wrapper.java.additional.9=-Djavax.net.ssl.keyStorePassword=letmein
wrapper.java.additional.10=-Djavax.net.ssl.trustStorePassword=letmein
wrapper.java.additional.11=-Dsun.net.client.defaultReadTimeout=1800000
wrapper.java.additional.12=-Dsun.net.client.defaultConnectTimeout=1800000
wrapper.java.additional.13=-Djavax.net.debug=ssl,handshake

Примечание. Как это стандартная практика для приложений Java, мы используем один и тот же файл хранилища ключей Java как для хранилища ключей, так и для трастора.

Вот как настраивается служебная оболочка для запуска SDS:

wrapper.app.parameter.1=org.jumpmind.symmetric.SymmetricLauncher
wrapper.app.parameter.2=--secure-server
wrapper.app.parameter.3=--secure-port
wrapper.app.parameter.4=25684
wrapper.app.parameter.5=--properties
wrapper.app.parameter.6=../conf/symmetric.properties

Записи в sym_node и simric.properties правильно настроены для использования HTTPS (вместо HTTP).

Дочерний узел SDS, который инициирует обмен данными с родительским, сообщает об этой ошибке:

WRITE: TLSv1 Handshake, length = 198  
READ: TLSv1 Alert, length = 2  
RECV TLSv1 ALERT: fatal, handshake_failure  
called closeSocket()  
handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

Родительский узел сообщает об этой ошибке:

SEND TLSv1 ALERT: fatal, description = handshake_failure  
WRITE: TLSv1 Alert, length = 2  
called closeSocket()  
handling exception: javax.net.ssl.SSLHandshakeException: no cipher suites in common

Как я уже упоминал ранее, та же самая конфигурация (серверы, сертификаты, файлы хранилища ключей / trustore, JDK) отлично работает для обеспечения безопасности TLS / HTTPS в SDS 2.5.13. Единственная дельта - это переход на SDS 3.1.5. Если я отключу конфигурацию TLS / HTTPS в SDS 3.1.5 и вместо этого использую HTTP, родительский и дочерний узлы смогут связываться друг с другом.

В качестве отчаянной проверки работоспособности я быстро закодировал клиент-серверное приложение «Hello World», чтобы создать SSLSocket на моем дочернем узле и отправить строку текста на серверный узел (используя тот же TCP-порт, который я использовал для SDS). Скомпилированная и запущенная программа с использованием того же JDK и тех же файлов хранилища ключей / доверенных сертификатов. Работал как чемпион.

Я в полном тупике. Любая помощь будет оценена по достоинству.


person Bruce Loth    schedule 14.12.2012    source источник


Ответы (1)


Ответил на свой вопрос. Судя по всему, кроме меня, никто не использует TLS между узлами SymmetricDS (SDS) (из-за полного отсутствия ответов). Исходное сообщение об ошибке сбило меня с толку и заставило искать не в тех местах.

Похоже, что версия SDS 3.x (по крайней мере, 3.1.5) теперь требует, чтобы вы указали «псевдоним» сертификата, который вы используете в своем хранилище ключей. Это значение предоставляется как параметр времени выполнения Java "sym.keystore.ssl.cert.alias". Для пользователей Windows он будет помещен в файл конфигурации служебной оболочки (sym_service.conf):

wrapper.java.additional.XX = -Dsym.keystore.ssl.cert.alias = foo

Этот параметр не является необходимым или не существует в SDS 2.5.13 и не задокументирован нигде в SDS 3.1.5 (или более поздних версиях). Его нет ни в каких конфигурационных файлах, которые поставляются с двоичной загрузкой SDS 3.1.5 (или SDS 3.2.0, я проверил).

Я смог выяснить мою проблему SDS TLS, посмотрев, как исходный код SDS устанавливает безопасное соединение.

org.jumpmind.symmetric.SymmetricWebServer использует псевдоним сертификата следующим образом:

sslConnectorFactory.setCertAlias ​​(System.getProperty (SystemConstants.SYSPROP_KEYSTORE_CERT_ALIAS, «символ»));

SystemConstants.SYSPROP_KEYSTORE_CERT_ALIAS установлен в "sym.keystore.ssl.cert.alias".

Как только я предоставил правильный псевдоним в sym_service.conf, я был готов к работе.

  • Брюс
person Community    schedule 21.12.2012