Класс 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()), поскольку невозможно гарантировать порядок отправки пакетов.