Класс 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(). Таким образом, входные и выходные ByteBuffer должны иметь размер, достаточный для хранения максимального пакета, который может быть произведён. Для определения соответствующих размеров буферов следует использовать вызовы 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()) {
   case 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;
   case BUFFER_UNDERFLOW:
       int netSize = engine.getSession().getPacketBufferSize();
       // Resize buffer if needed.
       if (netSize > src.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 могут потребовать результаты задач, выполнение которых может занять значительное время или даже заблокироваться. Например, TrustManager может потребоваться подключиться к удалённой службе проверки сертификатов, или KeyManager может потребоваться попросить пользователя определить сертификат, который нужно использовать в рамках аутентификации клиента. Кроме того, создание и проверка криптографических подписей может быть медленным и, похоже, блокирующим процессом.

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

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

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

Узел сигнализирует о намерении закрыться, отправив собственное сообщение рукопожатия закрытия. После получения и обработки этого сообщения локальным SSLEngine's unwrap() вызовом, приложение может обнаружить закрытие, вызвав unwrap() и поиска статуса "CLOSED" или, если isInboundDone() возвращает true. Если по какой-то причине узел закрывает соединение без отправки соответствующего сообщения закрытия SSL/TLS/DTLS, приложение может обнаружить конец потока и сигнализировать движку через closeInbound(), что больше нет входящих сообщений для обработки. Некоторые приложения могут потребовать упорядоченных сообщений закрытия от узла, в этом случае они могут проверить, было ли закрытие сгенерировано сообщением рукопожатия, а не состоянием конца потока.

Существует две группы наборов шифрования, о которых вам необходимо знать при управлении наборами шифрования:

• Поддерживаемые наборы шифрования: все наборы, которые поддерживаются реализацией SSL. Этот список сообщается с помощью getSupportedCipherSuites().
• Включенные наборы шифрования, которые могут быть меньше полного набора поддерживаемых наборов. Эта группа устанавливается с помощью метода setEnabledCipherSuites(String[]) и запрашивается с помощью метода getEnabledCipherSuites(). Изначально на новом движке будут включены набор по умолчанию наборов шифрования, представляющих минимальную рекомендуемую конфигурацию.

По умолчанию реализации требуют, чтобы только наборы шифрования, которые аутентифицируют серверы и обеспечивают конфиденциальность, были включены по умолчанию. Только если обе стороны явно согласны на неаутентифицированные и/или неконфиденциальные (незашифрованные) коммуникации, такой набор шифрования будет выбран.

Каждое SSL/TLS/DTLS-соединение должно иметь одного клиента и одного сервера, поэтому каждый конечная точка должна решить, какую роль принять. Этот выбор определяет, кто начинает процесс рукопожатия, а также какой тип сообщений должны отправлять каждая сторона. Метод setUseClientMode(boolean) настраивает режим. Обратите внимание, что режим по умолчанию для нового SSLEngine специфичен для поставщика. Приложения должны явно установить режим перед вызовом других методов SSLEngine. После того как началось начальное рукопожатие, SSLEngine не может переключаться между режимами клиента и сервера, даже при повторных переговорах.

Значения ApplicationProtocol String, возвращаемые методами в этом классе, находятся в сетевом представлении байтов, отправленном узлом. Байты можно сравнивать напрямую или преобразовывать в формат Unicode String для сравнения.

     String networkString = sslEngine.getHandshakeApplicationProtocol();
     byte[] bytes = networkString.getBytes(StandardCharsets.ISO_8859_1);

     //
     // Match using bytes:
     //
     //   "http/1.1"                       (7-bit ASCII values same in UTF-8)
     //   MEETEI MAYEK LETTERS "HUK UN I"  (Unicode 0xabcd->0xabcf)
     //
     String HTTP1_1 = "http/1.1";
     byte[] HTTP1_1_BYTES = HTTP1_1.getBytes(StandardCharsets.UTF_8);

     byte[] HUK_UN_I_BYTES = new byte[] {
         (byte) 0xab, (byte) 0xcd,
         (byte) 0xab, (byte) 0xce,
         (byte) 0xab, (byte) 0xcf};

     if ((Arrays.compare(bytes, HTTP1_1_BYTES) == 0 )
             || Arrays.compare(bytes, HUK_UN_I_BYTES) == 0) {
        ...
     }

     //
     // Alternatively match using string.equals() if we know the ALPN value
     // was encoded from a String using a certain character set,
     // for example UTF-8.  The ALPN value must first be properly
     // decoded to a Unicode String before use.
     //
     String unicodeString = new String(bytes, StandardCharsets.UTF_8);
     if (unicodeString.equals(HTTP1_1)
             || unicodeString.equals("\uabcd\uabce\uabcf")) {
         ...
     }
 

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

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

1. Методы wrap() и unwrap() могут выполняться параллельно друг другу.
2. Протоколы SSL/TLS/DTLS используют упорядоченные пакеты. Приложения должны позаботиться о том, чтобы сгенерированные пакеты доставлялись последовательно. Если пакеты приходят в неупорядоченном порядке, могут возникнуть непредвиденные или фатальные результаты.

   Например:

                 synchronized (outboundLock) {
                     sslEngine.wrap(src, dst);
                     outboundQueue.put(dst);
                 }
         

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