Класс SSLEngine

public abstract class SSLEngine
extends Object

Класс, который позволяет осуществлять защищенное общение с использованием таких протоколов, как Secure Sockets Layer (SSL), или протокол IETF RFC 2246 "Transport Layer Security" (TLS), но является независимым от транспорта.

Режимы защищенного обмена данными включают:

• Защита целостности. SSL/TLS/DTLS защищают от изменения сообщений активным перехватом.
• Аутентификация. В большинстве режимов SSL/TLS/DTLS обеспечивает аутентификацию участников. Серверы обычно аутентифицируются, а клиенты могут быть аутентифицированы по запросу сервера.
• Конфиденциальность (защита конфиденциальности). В большинстве режимов SSL/TLS/DTLS шифрует данные, передаваемые между клиентом и сервером. Это защищает конфиденциальность данных, поэтому пассивные перехватывающие данные не увидят конфиденциальную информацию, такую как финансовые данные или личную информацию многих типов.

Эти типы защиты определяются «набором шифров», который представляет собой комбинацию криптографических алгоритмов, используемых заданным соединением SSL. Во время процесса переговоров два конечных узла должны договориться о наборе шифров, доступном в обеих средах. Если нет такого набора, общее соединение SSL не может быть установлено, и данные не могут быть обменены.

Используемый набор шифров устанавливается процессом переговоров, называемым «рукопожатием». Цель этого процесса — создать или повторно подключиться к «сессии», которая может защищать множество соединений со временем. После завершения рукопожатия вы можете получить доступ к атрибутам сессии, используя метод getSession().

Класс SSLSocket предоставляет большую часть той же функциональности безопасности, но все входные и выходные данные автоматически передаются с использованием базового Socket, который по дизайну использует блокирующий режим. Хотя это подходит для многих приложений, эта модель не предоставляет масштабируемость, необходимую для больших серверов.

Основное отличие SSLEngine заключается в том, что он работает с входными и выходными потоками байтов, независимо от механизма транспорта. Ответственность пользователя SSLEngine заключается в организации надежной транспортной системы ввода-вывода к партнёру. Разделив абстракцию SSL/TLS/DTLS от механизма транспортного ввода-вывода, SSLEngine может использоваться для самых разных типов ввода-вывода, таких как non-blocking I/O (polling), selectable non-blocking I/O, Socket и традиционные потоки ввода/вывода, локальные ByteBuffers или массивы байтов, будущие асинхронные модели ввода-вывода и т. д.

На высоком уровне SSLEngine выглядит следующим образом:

app data

                |           ^
                |     |     |
                v     |     |
           +----+-----|-----+----+
           |          |          |
           |       SSL|Engine    |
   wrap()  |          |          |  unwrap()
           | OUTBOUND | INBOUND  |
           |          |          |
           +----+-----|-----+----+
                |     |     ^
                |     |     |
                v           |

                   net data

Данные приложения (также известные как текстовые или нешифрованные данные) — это данные, которые производятся или потребляются приложением. Их аналогом являются сетевые данные, состоящие либо из данных рукопожатия и/или зашифрованных данных и предназначенные для передачи через механизм ввода-вывода. Входные данные — это данные, полученные от партнера, а выходные данные предназначены для партнера.

(В контексте SSLEngine, термин «данные рукопожатия» понимается как любые данные, обмениваемые для установления и управления защищенным соединением. Данные рукопожатия включают сообщения SSL/TLS/DTLS «alert», «change_cipher_spec» и «handshake».)

Существует пять различных фаз для SSLEngine.

1. Создание — SSLEngine был создан и инициализирован, но еще не использовался. На этой стадии приложение может установить любые настройки, специфичные для SSLEngine (активные наборы шифров, необходимость SSLEngine выполнить рукопожатие в режиме клиента или сервера и т. д.). Однако, как только начнется рукопожатие, любые новые настройки (кроме режима клиента/сервера, см. ниже) будут использоваться для следующего рукопожатия.
2. Первичное рукопожатие — начальное рукопожатие — это процедура, в ходе которой два партнера обмениваются параметрами связи до тех пор, пока не будет установлено SSLSession. Данные приложения не могут быть отправлены на этой стадии.
3. Данные приложения — после того, как параметры связи были установлены, а рукопожатие завершено, данные приложения могут проходить через SSLEngine. Выходные сообщения приложения шифруются и защищаются от подмены, а входные сообщения выполняют обратный процесс.
4. Повторное рукопожатие — любая сторона может запросить повторное согласование сеанса в любое время во время фазы Данные приложения. Новые данные рукопожатия могут быть смешаны среди данных приложения. Прежде чем начать фазу повторного рукопожатия, приложение может сбросить параметры связи SSL/TLS/DTLS, такие как список включенных наборов шифров и использование аутентификации клиента, но не может изменить между режимами клиент/сервер. Как и прежде, после начала рукопожатия любые новые настройки конфигурации SSLEngine не будут использоваться до следующего рукопожатия.
5. Закрытие — когда соединение больше не требуется, приложения клиента и сервера должны закрыть обе стороны своих соединений. Для объектов SSLEngine приложение должно вызвать closeOutbound() и отправить любые оставшиеся сообщения партнеру. Аналогично, приложение должно принять все оставшиеся сообщения от партнера перед вызовом closeInbound(). После закрытия обеих сторон SSLEngine можно закрыть базовый механизм транспорта. Если соединение не закрыто должным образом (например, closeInbound() вызывается до получения уведомления о закрытии записи партнёра), будут подняты исключения, чтобы указать, что произошла ошибка. После закрытия движка он больше не может быть повторно использован: должен быть создан новый SSLEngine.

SSLEngine создается путем вызова SSLContext.createSSLEngine() из инициализированного SSLContext. Любые параметры конфигурации должны быть установлены до первого вызова wrap(), unwrap(), или beginHandshake(). Эти методы все запускают начальное рукопожатие.

Данные перемещаются через движок путем вызова wrap() или unwrap() для выходных или входных данных соответственно. В зависимости от состояния SSLEngine, вызов wrap() может использовать данные приложения из исходного буфера и может создавать сетевые данные в буфере назначения. Выходные данные могут содержать данные приложения и/или рукопожатия. Вызов unwrap() будет проверять исходный буфер и может продвинуть рукопожатие, если данные являются информацией о рукопожатии, или поместить данные приложения в буфер назначения, если данные представляют собой данные приложения. Состояние базового алгоритма SSL/TLS/DTLS определит, когда данные будут потребляться и производиться.

Вызовы wrap() и unwrap() возвращают SSLEngineResult, который указывает статус операции и (необязательно) как взаимодействовать с движком для достижения прогресса.

SSLEngine производит/потребляет только полные пакеты SSL/TLS/DTLS и не хранит данные приложения внутри между вызовами wrap()/unwrap(). Таким образом, входные и выходные буферы должны быть соответствующего размера для хранения максимального пакета. Вызовы SSLSession.getPacketBufferSize() и SSLSession.getApplicationBufferSize() следует использовать для определения соответствующего размера буфера. Размер выходного буфера данных приложения обычно не имеет значения. Если условия буфера не позволяют правильно потреблять/производить данные, приложение должно определить (через SSLEngineResult) и исправить проблему, а затем повторить вызов.

Например, unwrap() вернет результат SSLEngineResult.Status.BUFFER_OVERFLOW, если движок определит, что доступного места в буфере назначения недостаточно. Приложения должны вызвать SSLSession.getApplicationBufferSize() и сравнить это значение с доступным пространством в буфере назначения, увеличив буфер при необходимости. Аналогично, если unwrap() вернет SSLEngineResult.Status.BUFFER_UNDERFLOW, приложение должно вызвать SSLSession.getPacketBufferSize() для обеспечения достаточного места в исходном буфере для пакета (увеличив, если необходимо), и затем получить больше входных данных.

SSLEngineResult r = engine.unwrap(src, dst);
   switch (r.getStatus()) {
   BUFFER_OVERFLOW:
       // Could attempt to drain the dst buffer of any already obtained
       // data, but we'll just increase it to the size needed.
       int appSize = engine.getSession().getApplicationBufferSize();
       ByteBuffer b = ByteBuffer.allocate(appSize + dst.position());
       dst.flip();
       b.put(dst);
       dst = b;
       // retry the operation.
       break;
   BUFFER_UNDERFLOW:
       int netSize = engine.getSession().getPacketBufferSize();
       // Resize buffer if needed.
       if (netSize > dst.capacity()) {
           ByteBuffer b = ByteBuffer.allocate(netSize);
           src.flip();
           b.put(src);
           src = b;
       }
       // Obtain more inbound network data for src,
       // then retry the operation.
       break;
   // other cases: CLOSED, OK.
   }

В отличие от SSLSocket, все методы SSLEngine являются неблокирующими. Реализации SSLEngine могут потребовать результатов задач, которые могут занимать значительное время для завершения, или даже могут блокироваться. Например, менеджер доверия может потребовать подключения к удаленной службе проверки сертификатов, или менеджер ключей может потребовать запросить у пользователя, какой сертификат использовать в рамках аутентификации клиента. Кроме того, создание и проверка криптографических подписей может быть медленным, как будто это блокирует работу.

Для любой операции, которая потенциально может заблокировать выполнение, SSLEngine создаст делегированную задачу Runnable. Когда SSLEngineResult укажет, что результат делегированной задачи необходим, приложение должно вызвать getDelegatedTask() для получения ожидающей делегированной задачи и вызвать ее метод run() (возможно, используя другой поток в зависимости от стратегии вычисления). Приложение должно продолжать получать делегированные задачи до тех пор, пока они не закончатся, а затем повторить исходную операцию.

В конце сеанса связи приложения должны правильно закрыть соединение SSL/TLS/DTLS. Протоколы SSL/TLS/DTLS имеют сообщения рукопожатия закрытия, и эти сообщения должны быть переданы партнеру перед освобождением SSLEngine и закрытием базового механизма транспорта. Закрытие может быть инициировано одним из: SSLException, сообщением входного рукопожатия закрытия или одним из методов закрытия. Во всех случаях сообщения рукопожатия закрытия генерируются движком, и wrap() должно быть вызываться повторно до тех пор, пока статус полученного SSLEngineResult не вернет «CLOSED», или isOutboundDone() не вернет true. Все данные, полученные методом wrap(), должны быть отправлены партнеру.

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