Класс 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 и традиционные Input/OutputStreams, локальные 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() сообщает движку, что приложение больше не будет отправлять данные.

Узел-партнёр сообщит о намерении закрыть соединение, отправив собственное сообщение рукопожатия о закрытии. После получения и обработки этого сообщения вызовом unwrap() метода SSLEngine локального узла приложение может обнаружить закрытие, вызвав unwrap() и проверив, что статус SSLEngineResult равен «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")) {
        ...
    }

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

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

   Например:

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

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