Класс 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 могут потребовать результатов задач, выполнение которых может занять значительное время, или даже заблокироваться. Например, менеджер доверия может потребовать подключения к удаленной службе проверки сертификатов, или менеджер ключей может потребовать запросить у пользователя, какой сертификат использовать в рамках аутентификации клиента. Кроме того, создание и проверка криптографических подписей могут быть медленными, создавая видимость блокировки.

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

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

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

Узел будет сигнализировать о своем намерении закрыть соединение, отправив собственное сообщение закрытия. После получения и обработки этого сообщения локальным SSLEngine's unwrap() вызовом, приложение может обнаружить закрытие, вызвав unwrap() и найдя SSLEngineResult со статусом "ЗАКРЫТО", или если 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")) {
         ...
     }
 

Примечания по конкурентности: Следует учитывать две проблемы конкурентности:

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

   Например:

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

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