Класс 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() и поиска SSLEngineResult со статусом "CLOSED", или если isInboundDone() возвращает true. Если по какой-то причине узел закрывает канал связи, не отправив соответствующее сообщение о завершении SSL/TLS/DTLS, приложение может обнаружить конец потока и сигнализировать движку через closeInbound(), что больше не будет поступающих сообщений для обработки. Некоторые приложения могут потребовать упорядоченных сообщений о завершении от узла, в этом случае они могут проверить, было ли завершение вызвано сообщением о рукопожатии, а не состоянием конца потока.

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

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

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

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

Значения ApplicationProtocol String, возвращаемые методами в этом классе, находятся в сетевом представлении байтов, отправленном узлом. Байты можно напрямую сравнивать или преобразовать в формат Unicode {code 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()) одновременно, поскольку нет способа гарантировать последующую упорядоченность пакетов.