Блог

Главная - Вопросы по программированию - nginx TLSv1.3 резервный билет на сеанс после рукопожатия?

nginx TLSv1.3 резервный билет на сеанс после рукопожатия?

#nginx #ssl #tls1.3

#nginx #ssl #tls1.3

Вопрос:

Итак, я играл с TLSv1.3 в nginx и во время тестов с curl и openssl я увидел следующую картину:

curl -v https://domain-using-tls2 :

 ...
<request headers>
>
* TLSv1.2 (IN), TLS handshake, Newsession Ticket (4):
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 200
<response headers>
...

curl -v https://domain-using-tls3 :

 ...
<request headers>
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 200
<response headers>
...

И, копая openssl s_client -connect domain-using-tls3:443 , следующий блок появляется дважды (последовательно) с разными значениями:

 ...
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 819CA63CCA685293BDC0B45243F835AE891F55144218CB8FB35AA7F21C37B5AF
    Session-ID-ctx: 
    Resumption PSK: EC0F7DAEFA69EF162BDB2D23D7017D5E4D5F8B4E37461C016FFEE110EA7A9DB42B0C4E34558780CBDEE1827E2A70A0F7
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 62 b6 46 5a d2 1e f5 0d-6c 05 a1 00 f7 0d 5b bd   b.FZ....l.....[.
    0010 - bd 4e 27 96 cc ee 88 dd-a3 5f 03 6f fb 5b 0d 1f   .N'......_.o.[..

    Start Time: 1606408171
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
...

Итак, мой вопрос: есть ли что-то в протоколе TLSv1.3, что заставляет nginx отправлять билет сеанса дважды или это что-то особенное для nginx? потому что это выглядит просто чем-то избыточным, что будет проигнорировано клиентом….

Комментарии:

1. Билет отличается в TLS1.3 от предыдущих версий; он фактически задает имя для производного PSK, которое сохраняет прямую секретность, и их может быть несколько, см. RFC8446 . Nginx использует OpenSSL и, по-видимому, не изменяет значение по умолчанию 2 . Я не уверен, почему OpenSSL выбрал это значение по умолчанию, но вы также можете увидеть его с openssl s_sarver помощью and openssl s_client . Если вы хотите продолжить это, на самом деле это не вопрос или проблема программирования и было бы более подходящим для security.stackexchange.com .

2. Я столкнулся с аналогичной проблемой. Ссылка аналогична (nginx openssl tls 1.3). В моем случае есть авторизация через cookie, которая состоит из нескольких подзапросов, и в автоматическом режиме с сохранением cookie в файл ничего не работает. При следующем запросе файл cookie заменяется, что приводит к ошибке 403

Метки: