Hello! On Thu, Sep 20, 2018 at 01:31:53AM +0300, Gena Makhomed wrote:
> On 19.09.2018 21:56, Maxim Dounin wrote: > > >>> Цель "Must Staple", как она обсуждалась на cabforum'е - сделать > >>> обязательной проверку отзыва, не нагружая дополнительно > >>> инфраструктуру CA. > > >>> Проблема в том, что нельзя просто так взять механизм оптимизации и > >>> сделать из него механизм контроля, это две разные задачи, которые > >>> надо решать по-разному. > > >> Если задача стоит "сделать обязательной проверку отзыва, > >> не нагружая дополнительно инфраструктуру CA" - как же можно > >> решить эту задачу другими методами, без флага Must Staple? > > > Всё так, именно этой цели соответствует решение "must staple". > > Проблема тут во многом - в целеполагании. > > Правильной была бы цель "сделать обязательной проверку отзыва" > без каких-либо дополнительных условий? Именно так. Потому что мешать в одну кучу требование о проверке отзыва сертфиката и технические аспекты одного из вариантов этой проверки - это плохой путь. > Правильным решением в таком случае был бы флаг в сертификате > "обязательно проверять отзыв сертификата", так что если веб-сервер > прислал OCSP-ответ прикрепленный к сертификату сервером, браузер > использует его, а если веб-сервер ничего не прислал, тогда браузер > должен сам в обязательном порядке сделать OCSP-запрос и получить ответ? > И только если браузер не смог получить OCSP-ответ, только в этом случае > запрещать клиенту доступ к сайту с таким флагом в сертификате? И это было бы логично: именно так сейчас браузеры, использующие OCSP, и работают, с той лишь разницей, что по результатам неудачной проверки доступ - не запрещают. > Такое решение задачи наверное было бы наиболее удобным для создателей > веб-серверов, но значительно увеличило бы нагрузку на инфраструктуру CA, Не увеличило бы. Потому что по факту - OCSP сейчас и так включён по умолчанию во всех браузерах, его использующих. Более того: был бы однозначный мотив для таких сертификатов включать OCSP stapling, так как это повышало бы надёжность в ситуациях, когда OCSP-сервер оказывался бы по каким-то причинам недоступен. [...] > > В тот момент, когда от клиента пришло соединение с запросом > > certificate status и OpenSSL'ем был вызван соответствующий > > callback - у nginx'а нет возможности как-либо отложить обработку > > этого соединения. > > > > Соответственно либо к этому моменту у nginx'а уже есть > > соответствующий OCSP-ответ - и тогда он может его отправить > > клиенту, либо соответствующего OCSP-ответа нет - и тогда он не > > может его отправить, а максимум что может - это инициировать > > запрос к OCSP-серверу, чтобы этот ответ получить для последующих > > клиентов. > > У nginx есть отдельный процесс cache manager, который управляет кэшем > независимо от рабочих процессов nginx, может быть имеет смысл также > сделать ocsp cache manager, который будет заниматься получением > и кэшированием OCSP-ответов для всех присутствующих сертификатов? Можно сделать много всего. Но это не избавляет от ситуации, когда соединение, в котором надо вернуть OCSP-ответ, уже есть, а самого OCSP-ответа - ещё нет. [...] > > Эту проблему можно столь же успешно решить, просто не пытаясь > > включать "ssl_prefer_server_ciphers". Попытки же изобретать > > сложную логику - "здесь играем, здесь не играем, здесь рыбу > > заворачивали" - выглядят, скажем мягко, странно. > > Эта сложная логика уже изобретена и встроена в OpenSSL, > достаточно только указать флаг SSL_OP_PRIORITIZE_CHACHA. > > Получается очень красивое решение, так что и Forward Secrecy > можно получить с большинством браузеров и мобильные клиенты > будут использовать наиболее эффективный для них шифр ChaCha20. Это что угодно, но только не красивое решение. Люди потратили массу сил и времени на изобретение сложной логики (и теперь хотят, чтобы разработчики nginx'а и все пользователи nginx'а - присоединились к процессу, потому что встроить эту логику в существующий механизм выбора приоритета шифров - не осилили). И всё ради того, чтобы насильно обеспечить Forward Secrecy людям, сознательно забившим на обновление софта. Не говоря уже о том, что аналогичные проблемы - будут возникать в будущем снова и снова. -- Maxim Dounin http://mdounin.ru/ _______________________________________________ nginx-ru mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-ru
