Как определить версию TLS запроса HttpServletRequest?

Question

Я нахожусь в процессе прекращения поддержки TLS 1.0 и TLS 1.1 для веб-приложения.

Я хотел бы обнаружить пользователей, это повлияет на их соединения с моими серверами.

Я использую Tomcat 7 и Java 8.

Как определить версию TLS запроса HttpServletRequest?

Answer 1

Это не практично делать в Java. Это требует изменения реализации JSSE или подключения альтернативы.

В конце концов я решил эту проблему, развернув How's My SSL и используя междоменный AJAX со стороны клиента, чтобы проверить состояние SSL и сообщить об этом на сервер приложений.

У вас должны быть прямые запросы от клиента без прокси, чтобы правильно оценить состояние их SSL. НЕ устанавливайте балансировщик нагрузки HTTPS перед How's My SSL. Это сломает его и даст вам неверные результаты.

Вот фрагмент клиентского JavaScript, который должен работать с использованием общедоступного сервиса How's My SSL (я рекомендую развернуть свой собственный):

$.getJson('https://www.howsmyssl.com/a/check')
.done(function (result) {
    $.post('/logs', {
                    name: 'howsmyssl',
                    level: 'info',
                    message: result
    });
})
.fail(function(err) {
    $.post('/logs', {
                    name: 'howsmyssl',
                    level: 'error',
                    message: 'could not reach howsmyssl'
    });
});

Вам понадобится конечная точка REST, работающая в /logs на вашем сервере приложений, которая может получить POST для захвата этого. Вы можете изменить этот путь и формат сообщения в соответствии с вашим сердцем. Эта конечная точка должна быть аутентифицирована и должна обогащать журналы временем события, аутентифицированным участником (пользователем) и, возможно, другой информацией, такой как IP-адрес.

Содержимое результата выглядит так (красиво напечатано, чтобы его было легче читать):

{
    "given_cipher_suites": [
        "TLS_GREASE_IS_THE_WORD_8A",
        "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
        "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
        "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
        "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
        "TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256",
        "TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256",
        "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA",
        "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA",
        "TLS_RSA_WITH_AES_128_GCM_SHA256",
        "TLS_RSA_WITH_AES_256_GCM_SHA384",
        "TLS_RSA_WITH_AES_128_CBC_SHA",
        "TLS_RSA_WITH_AES_256_CBC_SHA",
        "TLS_RSA_WITH_3DES_EDE_CBC_SHA"
    ],
    "ephemeral_keys_supported": true,
    "session_ticket_supported": true,
    "tls_compression_supported": false,
    "unknown_cipher_suite_supported": false,
    "beast_vuln": false,
    "able_to_detect_n_minus_one_splitting": false,
    "insecure_cipher_suites": {
    },
    "tls_version": "TLS 1.2",
    "rating": "Probably Okay"
}

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