OpenSSL: пересмотр инициирован клиентом - PullRequest
0 голосов
/ 10 октября 2018

Я устанавливаю клиент-серверные соединения, используя mem-BIO.Я был в состоянии отправить данные без ввода-вывода сокета.Это была моя ссылка - http://roxlu.com/2014/042/using-openssl-with-memory-bios.

Вопрос 1: Для расшифровки он использовал BIO_write () и затем SSL_read ().Если через сокет IO запись превышает 2 пакета, что мне нужно позаботиться?Если SSL_read () возвращает SSL_ERROR_WANT_READ, означает ли это, что данные буферизируются в in_bio, и мне нужно снова вызвать BIO_write () и SSL_read () для второго пакета, и на этот раз SSL_read () вернет SSL_ERROR_NONE?

Вопрос2: я пытаюсь понять рукопожатие пересмотра SSL.Проходит ли это 4-х стороннее рукопожатие?Или он просто должен выполнить двустороннее рукопожатие, и клиент-привет снова может не понадобиться?Пожалуйста, поделитесь любой информацией об обмене рукопожатиями при перезаключении.

Теперь я добавил этот код в приведенный выше пример:

main() {
<snip - Initial handshake>
</snip>

  SSL_renegotiate(client.ssl);
  SSL_do_handshake(client.ssl);
  krx_ssl_handle_traffic(&client, &server);
  krx_ssl_handle_traffic(&server, &client);
  krx_ssl_handle_traffic(&client, &server);
  krx_ssl_handle_traffic(&server, &client);
}

Я вижу их с помощью обратных вызовов:

+ client:      HANDSHAKE START -  before connect initialization  - CINIT
+ client:                 LOOP -        SSL renegotiate ciphers  - UNKWN
+ client:                 LOOP -     SSLv3 write client hello A  - 3WCH_A
+ server:      HANDSHAKE START -   before accept initialization  - AINIT
+ server:                 LOOP -   before accept initialization  - AINIT
+ server:                 LOOP -      SSLv3 read client hello A  - 3RCH_A
+ server:                 LOOP -     SSLv3 write server hello A  - 3WSH_A
+ server:                 LOOP -      SSLv3 write certificate A  - 3WSC_A
+ server:                 LOOP - SSLv3 write certificate reques  - 3WCR_A
+ server:                 LOOP -      SSLv3 write server done A  - 3WSD_A
+ server:                 LOOP -               SSLv3 flush data  - 3FLUSH
+ client:                 LOOP -      SSLv3 read server hello A  - 3RSH_A
+ client:                 LOOP - SSLv3 read server certificate   - 3RSC_A
+ client:                 LOOP - SSLv3 read server certificate   - 3RCR_A
+ client:                 LOOP -       SSLv3 read server done A  - 3RSD_A
+ client:                 LOOP - SSLv3 write client certificate  - 3WCC_A
+ client:                 LOOP - SSLv3 write client key exchang  - 3WCKEA
+ client:                 LOOP - SSLv3 write certificate verify  - 3WCV_A
+ client:                 LOOP - SSLv3 write change cipher spec  - 3WCCSA
+ client:                 LOOP -         SSLv3 write finished A  - 3WFINA
+ client:                 LOOP -               SSLv3 flush data  - 3FLUSH
+ server:                 LOOP - SSLv3 read client certificate   - 3RCC_A
+ server:                 LOOP - SSLv3 read client key exchange  - 3RCKEA
+ server:                 LOOP - SSLv3 read certificate verify   - 3RCV_A
+ server:                 LOOP -          SSLv3 read finished A  - 3RFINA
+ server:                 LOOP -   SSLv3 write session ticket A  - UNKWN
+ server:                 LOOP - SSLv3 write change cipher spec  - 3WCCSA
+ server:                 LOOP -         SSLv3 write finished A  - 3WFINA
+ server:                 LOOP -               SSLv3 flush data  - 3FLUSH
+ server:       HANDSHAKE DONE - SSL negotiation finished succe  - SSLOK
+ client:                 LOOP - SSLv3 read server session tick  - UNKWN
+ client:                 LOOP -          SSLv3 read finished A  - 3RFINA
+ client:       HANDSHAKE DONE - SSL negotiation finished succe  - SSLOK

Спасибо.

1 Ответ

0 голосов
/ 11 октября 2018

Q1.Пакеты и _WANT_READ

Вам не совсем ясно, какие у вас пакеты.При использовании SSL / TLS через TCP (в обычном случае) запись SSL / TLS может содержать до 16 тыс. Октетов, тогда как на большинстве сетевых путей TCP обычно использует размер пакета (или сегмента) около1400. Для завершения одной записи может потребоваться более 10 из этих пакетов.И когда это происходит, эта запись не может быть записью ApplicationData;если это не так, SSL_read по-прежнему не будет иметь данных для возврата, а вместо этого будет действовать в соответствии с протоколом, что может потребовать дальнейшего чтения И / ИЛИ ЗАПИСИ, прежде чем он вернет данные.Вы не должны пытаться угадать, что будут делать неблокирующие SSL_read (или SSL_write);вы всегда должны смотреть на их возвращаемые значения и «расширенные» значения из SSL_get_error (это процедура, которая фактически возвращает SSL_WANT_{READ,WRITE} и т. д., НЕ SSL_read и SSL_write).Это объясняется на страницах руководства, которые я рекомендую вам прочитать, если вы еще этого не сделали.Если вы работаете в Windows без WSL, где страницы руководства не используются, см. веб-сайт .

Q2.Пересмотр

(Примечание: ответ только для TLS через 1.2; 1.3 определенно существенно меняет нормальное рукопожатие, и я верю также в повторное согласование, но я еще не прошел его подробно). За исключением того, что оно начинается покасеанс (криптографический контекст) уже используется, и может быть инициирован сервером с RequestHello и (что важно) может использовать расширение индикации повторного согласования (RFC5746) для предотвращения атаки "Apache-splice" (CVE-2009-3555), повторное согласование (почти) совпадает с первоначальным согласованием .Если полное рукопожатие занимает четыре рейса (две поездки туда и обратно);если сокращенное рукопожатие (возобновление ранее существовавшего сеанса) занимает три рейса, но последний может быть объединен с данными клиента, которые часто сокращают его до одного туда-обратно.Смотрите мой ответ в https://security.stackexchange.com/questions/91248/questions-about-triple-handshakes-considered-harmful-breaking-and-fixing-authen (чья значимость, по общему признанию, неочевидна), чтобы узнать об этом.См. RFC 5246 et pred для получения информации о рукопожатии

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...