Возобновление сеанса HTTPS иногда работает частично
У меня проблема с кешированием ssl-сеанса. Чтобы проверить, в порядке ли конфигурация сервера, я использую следующую команду:
echo | openssl s_client -connect <server.com>:443 -reconnect 2>/dev/null| egrep -iw "New|Reused|Session-ID:"
Она выводит «Новый» для первого запроса, а затем «Повторно используется». Итак, конфигурация сервера выглядит нормально.
Когда я смотрю на apache2 access.log, я вижу, что для некоторых клиентов он работает должным образом. Лучший способ, который я нашел до сих пор для диагностики возобновления сеанса ssl, - это посмотреть количество отправленных байтов (% O).
Пример рабочего журнала клиента:
IP - - [D:10:36:59] "GET /rest/instant_message/TEST HTTP/1.1" 200 13 5142 "-" "Dalvik/2.1.0 (Linux; U; Android 8.1.0; iot800n Build/OPM6.171019.030.K1)"
IP - - [D:10:37:00] "GET /rest/instant_message/TEST HTTP/1.1" 200 13 482 "-" "Dalvik/2.1.0 (Linux; U; Android 8.1.0; iot800n Build/OPM6.171019.030.K1)"
IP - - [D:10:37:03] "GET /rest/instant_message/TEST HTTP/1.1" 200 13 635 "-" "Dalvik/2.1.0 (Linux; U; Android 8.1.0; iot800n Build/OPM6.171019.030.K1)"
IP - - [D:10:37:04] "GET /rest/instant_message/TEST HTTP/1.1" 200 13 482 "-" "Dalvik/2.1.0 (Linux; U; Android 8.1.0; iot800n Build/OPM6.171019.030.K1)"
IP - - [D:10:37:06] "GET /rest/instant_message/TEST HTTP/1.1" 200 13 482 "-" "Dalvik/2.1.0 (Linux; U; Android 8.1.0; iot800n Build/OPM6.171019.030.K1)"
IP - - [D:10:37:09] "GET /rest/instant_message/TEST HTTP/1.1" 200 13 635 "-" "Dalvik/2.1.0 (Linux; U; Android 8.1.0; iot800n Build/OPM6.171019.030.K1)"
IP - - [D:10:37:11] "GET /rest/instant_message/TEST HTTP/1.1" 200 13 482 "-" "Dalvik/2.1.0 (Linux; U; Android 8.1.0; iot800n Build/OPM6.171019.030.K1)"
IP - - [D:10:37:13] "GET /rest/instant_message/TEST HTTP/1.1" 200 13 635 "-" "Dalvik/2.1.0 (Linux; U; Android 8.1.0; iot800n Build/OPM6.171019.030.K1)"
IP - - [D:10:37:15] "GET /rest/instant_message/TEST HTTP/1.1" 200 13 482 "-" "Dalvik/2.1.0 (Linux; U; Android 8.1.0; iot800n Build/OPM6.171019.030.K1)"
IP - - [D:10:37:17] "GET /rest/instant_message/TEST HTTP/1.1" 200 13 482 "-" "Dalvik/2.1.0 (Linux; U; Android 8.1.0; iot800n Build/OPM6.171019.030.K1)"
IP - - [D:10:37:19] "GET /rest/instant_message/TEST HTTP/1.1" 200 13 635 "-" "Dalvik/2.1.0 (Linux; U; Android 8.1.0; iot800n Build/OPM6.171019.030.K1)"
В журнале выше вы можете видеть, что первый запрос ответ составляет 5142 байта (длина 13 содержимого). И все последующие ответы на запросы имеют размер 482 или 635 байтов (одинаковая длина содержимого).
Однако для некоторых клиентов все ответы на запросы имеют размер ~ 5 КБ. Как показано в приведенном ниже примере журнала:
IP - - [D:10:30:45] "GET /rest/instant_message/BOM1 HTTP/1.1" 200 419 5549 "-" "Dalvik/2.1.0 (Linux; U; Android 9; SM-T395 Build/PPR1.180610.011)"
IP - - [D:10:31:00] "GET /rest/instant_message/BOM1 HTTP/1.1" 200 419 5549 "-" "Dalvik/2.1.0 (Linux; U; Android 9; SM-T395 Build/PPR1.180610.011)"
IP - - [D:10:31:15] "GET /rest/instant_message/BOM1 HTTP/1.1" 200 419 5549 "-" "Dalvik/2.1.0 (Linux; U; Android 9; SM-T395 Build/PPR1.180610.011)"
IP - - [D:10:31:30] "GET /rest/instant_message/BOM1 HTTP/1.1" 200 419 5549 "-" "Dalvik/2.1.0 (Linux; U; Android 9; SM-T395 Build/PPR1.180610.011)"
IP - - [D:10:31:45] "GET /rest/instant_message/BOM1 HTTP/1.1" 200 419 5549 "-" "Dalvik/2.1.0 (Linux; U; Android 9; SM-T395 Build/PPR1.180610.011)"
IP - - [D:10:32:00] "GET /rest/instant_message/BOM1 HTTP/1.1" 200 419 5549 "-" "Dalvik/2.1.0 (Linux; U; Android 9; SM-T395 Build/PPR1.180610.011)"
IP - - [D:10:32:15] "GET /rest/instant_message/BOM1 HTTP/1.1" 200 419 5549 "-" "Dalvik/2.1.0 (Linux; U; Android 9; SM-T395 Build/PPR1.180610.011)"
IP - - [D:10:32:30] "GET /rest/instant_message/BOM1 HTTP/1.1" 200 419 5549 "-" "Dalvik/2.1.0 (Linux; U; Android 9; SM-T395 Build/PPR1.180610.011)"
IP - - [D:10:32:45] "GET /rest/instant_message/BOM1 HTTP/1.1" 200 419 5549 "-" "Dalvik/2.1.0 (Linux; U; Android 9; SM-T395 Build/PPR1.180610.011)"
Иногда один и тот же клиент (тот же IP-адрес) иногда использует возобновление сеанса, затем прекращает его использование, затем повторно использует его и т. Д.
Все клиенты являются одними и теми же планшетами Android (SMT395) запуск того же приложения с использованием библиотеки Volley для HTTP-запросов. Они подключены к Интернету с помощью SIM-карты.
Конфигурация сервера:
SSLSessionCache shmcb:${APACHE_RUN_DIR}/ssl_scache(512000)
SSLSessionCacheTimeout 300
Что могло быть причиной невозобновления сеанса https? Какие инструменты я могу использовать для отладки сеанса https?
Лучший способ, который я нашел до сих пор, чтобы диагностировать возобновление сеанса ssl, — это посмотреть на количество отправленных байтов
Во-первых, включите mod_statusи установите ExtendedStatusна Вкл. Убедитесь, что эта страница состояния закрыта для общего доступа, возможно, с помощью ACLили базовой аутентификациис надежным паролем.
Вы должны увидеть использование кэша сеанса на странице состояния httpd, что-то вроде
SSL/TLS Session Cache Status:
cache type: SHMCB, shared memory: 512000 bytes, current sessions: 1
sub-caches: 32, indexes per sub-cache: 133
time left on oldest entries' SSL sessions: avg: 297 seconds, (range: 297...297)
index usage: 0%, cache usage: 0%
total sessions stored since starting: 1
total sessions expired since starting: 0
total (pre-expiry) sessions scrolled out of the cache: 0
total retrieves since starting: 1 hit, 1 miss
total removes since starting: 0 hit, 0 miss
Таким образом, вы получите общее представление об использовании кэша TLS/SSL. Это проверит, заполнен ли ваш кеш (высокое использование индекса и/или кеша), что потребует от вас увеличения размера кеша; или если у вас мало клиентов, плохой клиент.
Также проверьте совпадения и промахи кеша, чтобы убедиться, что ваш сервер и ваш клиент используют возобновление сеанса.
Затем включитеотладкуведение журналадля mod_ssl, чего-то вроде
<IfModule mod_ssl.c>
ErrorLog /var/log/apache2/ssl_engine.log
LogLevel ssl:debug
</IfModule>
должно хватить.
При этом будут выведены огромныеподробные журналы о модуле SSL в вашем экземпляре httpd, включая создание, возобновление и истечение сеанса. Протестируйте на своих исправных и неисправных клиентах, чтобы увидеть разницу.
Иногда один и тот же клиент (тот же IP-адрес) иногда использует возобновление сеанса, затем прекращает его использование, затем повторно использует его и т. д.
Сколько клиентов подключается к серверу? Сколько оперативной памяти на сервере? shmcb— это кеш с общей памятью, и 512 КБ должно быть достаточно для сервера с низким трафиком, но я подозреваю, что 512 КБ недостаточно для вашей реализации.
В чем может быть причина невозобновления сеанса https?
Много. Это зависит от вашей версии TLS (< 1.3, >= 1.3? Возобновление сеанса SSL уже включено в TLS, по крайней мере, с версии 1.1, но обновлено в версии 1.3), вашего клиентского приложения, вашей клиентской библиотеки SSL и т. д.