8.3.5 Reusing SSL Sessions — MySQL 9.2

8.3.5 Использование повторных сессий SSL

Программы-клиенты MySQL могут возобновить предыдущую сессию SSL, при условии, что сервер имеет эту сессию в кэше. Этот раздел описывает условия, благоприятствующие повторному использованию сессий SSL, переменные сервера, используемые для управления и мониторинга кэша сессий, и параметры командной строки клиента для хранения и повторного использования данных сессии.

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

В общем случае, прежде чем можно будет повторно использовать сессии SSL, должны быть выполнены следующие условия:

Сервер должен хранить свой кэш сессий в оперативной памяти.
Время ожидания кэша сессий на стороне сервера не должно истечь.
Каждый клиент должен поддерживать кэш активных сессий и хранить его в безопасности.

Приложения C могут использовать возможности API C для включения повторного использования сессий для зашифрованных соединений (см. ).

Настройка и мониторинг кэша сессий SSL на стороне сервера для повторного использования

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

Таблица 8.13 Системные и переменные состояния для повторного использования сессий

Таблица 8.13 Системные и переменные состояния для повторного использования сессий
Название системной переменной	Соответствующее название переменной состояния
`ssl_session_cache_mode`	`Ssl_session_cache_mode`
`ssl_session_cache_timeout`	`Ssl_session_cache_timeout`

Примечание

Когда значение переменной сервера ssl_session_cache_mode равно ON, что является режимом по умолчанию, значение переменной состояния Ssl_session_cache_mode равно SERVER.

Переменные кэша SSL-сессий применяются как к каналам mysql_main, так и к каналам mysql_admin TLS. Их значения также отображаются в качестве свойств в таблице Performance Schema tls_channel_status, вместе со свойствами любых других активных контекстов TLS.

Чтобы переконфигурировать кэш SSL-сессий во время выполнения, используйте эту процедуру:

Установите каждую системную переменную, относящуюся к кэшу, которую необходимо изменить, на новое значение. Например, измените значение тайм-аута кэша с значения по умолчанию (300 секунд) до 600 секунд:
```
mysql> SET GLOBAL ssl_session_cache_timeout = 600;
```
Члены каждой пары системных и переменных состояния могут временно иметь разные значения из-за того, как работает процедура переконфигурации.
```
mysql> SHOW VARIABLES LIKE 'ssl_session_cache_timeout';
+---------------------------+-------+
| Variable_name             | Value |
+---------------------------+-------+
| ssl_session_cache_timeout | 600   |
+---------------------------+-------+
1 row in set (0.00 sec)

mysql> SHOW STATUS LIKE 'Ssl_session_cache_timeout';
+---------------------------+-------+
| Variable_name             | Value |
+---------------------------+-------+
| Ssl_session_cache_timeout | 300   |
+---------------------------+-------+
1 row in set (0.00 sec)
```
Дополнительную информацию о настройке значений переменных см. в разделе Назначение системных переменных.
Выполните ALTER INSTANCE RELOAD TLS. Эта команда переконфигурирует активный контекст TLS на основе текущих значений системных переменных, относящихся к кэшу. Она также устанавливает переменные состояния, относящиеся к кэшу, для отражения новых активных значений кэша. Для выполнения команды требуется привилегия CONNECTION_ADMIN.
```
mysql> ALTER INSTANCE RELOAD TLS;
Query OK, 0 rows affected (0.01 sec)

mysql> SHOW VARIABLES LIKE 'ssl_session_cache_timeout';
+---------------------------+-------+
| Variable_name             | Value |
+---------------------------+-------+
| ssl_session_cache_timeout | 600   |
+---------------------------+-------+
1 row in set (0.00 sec)

mysql> SHOW STATUS LIKE 'Ssl_session_cache_timeout';
+---------------------------+-------+
| Variable_name             | Value |
+---------------------------+-------+
| Ssl_session_cache_timeout | 600   |
+---------------------------+-------+
1 row in set (0.00 sec)
```
Новые подключения, установленные после выполнения ALTER INSTANCE RELOAD TLS, будут использовать новый контекст TLS. Существующие подключения останутся без изменений.

Конфигурация клиента для повторного использования сеанса SSL

Все программы-клиенты MySQL могут повторно использовать предыдущий сеанс для новых защищённых соединений с тем же сервером, при условии, что данные сеанса были сохранены, пока оригинальное соединение было активным. Данные сеанса сохраняются в файле, и этот файл указывается при повторном вызове клиента.

Для сохранения и повторного использования данных сеанса SSL используйте эту процедуру:

Вызовите mysql для установления защищённого соединения с сервером MySQL 9.2.
Используйте команду ssl_session_data_print для указания пути к файлу, где можно безопасно сохранить текущие данные активного сеанса. Например:
```
mysql> ssl_session_data_print ~/private-dir/session.txt
```
Данные сеанса получаются в виде ANSI-строки с нулевым завершением и кодировкой PEM. Если вы опустите путь и имя файла, строка будет выведена в стандартный вывод.
Из командной строки вызовите любую программу-клиент MySQL для установления нового защищённого соединения с тем же сервером. Для повторного использования данных сеанса укажите командную опцию --ssl-session-data и аргумент файла.

Например, установите новое соединение с помощью mysql:
```
mysql -u admin -p --ssl-session-data=~/private-dir/session.txt
```
а затем с помощью клиента mysqlshow:
```
mysqlshow -u admin -p --ssl-session-data=~/private-dir/session.txt
Enter password: *****
+--------------------+
|     Databases      |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
| world              |
+--------------------+
```
В каждом примере клиент пытается возобновить оригинальный сеанс при установлении нового соединения с тем же сервером.

Чтобы подтвердить, что mysql повторно использовал сеанс, см. вывод команды status. Если текущее активное соединение mysql возобновило сеанс, информация о статусе включает SSL session reused: true.

Помимо mysql и mysqlshow, повторное использование сеансов SSL применимо к mysqladmin, mysqlbinlog, mysqlcheck, mysqldump, mysqlimport, mysqlslap, mysqltest, mysql_migrate_keyring и mysql_secure_installation.

Несколько условий могут препятствовать успешному получению данных сеанса. Например, если сеанс не полностью подключён, это не сеанс SSL, сервер ещё не передал данные сеанса или сеанс SSL просто не может быть повторно использован. Даже с должным образом сохранёнными данными сеанса, кэш сеанса сервера может истечь. Независимо от причины, по умолчанию возвращается ошибка, если вы указываете --ssl-session-data, но сеанс не может быть повторно использован. Например:

mysqlshow -u admin -p --ssl-session-data=~/private-dir/session.txt
Enter password: *****
ERROR:
--ssl-session-data specified but the session was not reused.

Чтобы подавить сообщение об ошибке и установить соединение, молча создав новый сеанс вместо этого, укажите --ssl-session-data-continue-on-failed-reuse в командной строке вместе с --ssl-session-data. Если таймаут кэша сервера истек, вы можете снова сохранить данные сеанса в тот же файл. Таймаут кэша сервера по умолчанию можно увеличить (см. Настройка и мониторинг серверной части для повторного использования сеансов SSL).