SSLv2Hello vs TLSv1

котэ-то напеши!

такжэ попробуй употребить нечто -Dhttps.protocols=«TLSv1,SSLv3» иле в server.xml настроить sslEnabledProtocols=«TLSv1,SSLv3,SSLv2Hello» в JSSE коннекторе. Только шото одно из этого, или -D или коннектор

алсо можно заиспользовать такого котэ:

public static SchemeRegistry buildSchemeRegistry() throws Exception {
    final SSLContext sslContext = SSLContext.getInstance("TLSv1.2");
    sslContext.init(createKeyManager(), createTrustManager(), new SecureRandom());
    final SchemeRegistry schemeRegistry = new SchemeRegistry();
    schemeRegistry.register(new Scheme("https", 443, new SSLSocketFactory(sslContext)));
    return schemeRegistry;
}

я вообще пьян и упорот в хлам, но совет выглядит достаточно забавно, чтобы запостить!

Привет.

Если я правильно понимаю, то настройки коннектора должны влиять только на входящие соединения Tomcat'а и не должны влиять на других. И я забыл упомянуть, что веб-приложение устанавливает свою дефолтную фабрику сокетов в HttpClient, но эта фабрика не меняет список протоколов для создаваемых сокетов (я еще специально проверял через SSLSocket.getEnabledProtocols() поддерживает ли новый сокет SSLv2Hello - поддерживает).

Для информации: в Java 6 нет поддержки ни TLSv1.2, ни TLSv1.1 из коробки

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

может как-небудь через вайершарк поймать, што они говорят па сети, и пасматреть, кто придложил непатребный пратакол?

вот шта нагуглилась сразу: http://support.citrix.com/article/CTX116557

да, ты праф, канектор заработает только на 7, а вот -D канает и на 6, и да - канектор это на входящие только

Вопрос не о том на каком протоколе они сойдутся, а о том почему для первого пакета ClientHello используется TLSv1 если логику запускать из под Tomcat'а и SSLv2Hello если из консоли.

Добавлю что «https.protocols» нигде в стартовых скриптах Tomcat'а не обнаруживается.

проверь не установленно ли у тебя несколько версий jre

Только одна.

тогда встраивай в свою логику код который выводит в лог: все переменные окружения и Systems.getProperties() запускай в томкате и с консоли и ищи разницу

другой вариант - отладка в недрах sslконтекста но там проприетарное апи без отладочных символов занятие неинтересное

Включи debug вывод на ssl в jvm, скорее всего там ясно будет что происходит.

Пробовал до этого, но ничего подозрительного не нашел. А сейчас еще раз проанализировал и глаз зацепился вот за такие строчки, если запускать из под Tomcat'а:

%%% Client cached [Session-1, TLS_RSA_WITH_AES_128_CBC_SHA]
%% Try resuming [Session-1, TLS_RSA_WITH_AES_128_CBC_SHA] from port 43287
*** ClientHello, TLSv1

Судя по всему Java умеет кешировать параметры SSL для хостов, а в консоли я этого не мог заметить потому что строго один запрос посылал. Сейчас переделал на три запроса подряд из консоли: для первого запроса ClientHello через SSLv2Hello идет, а для двух последующих ClientHello уже сразу через TLSv1.