Просто скажите, что вы завершаете http SSL-соединения на промежуточном сервере, таком как Cloudflare, это расшифрует данные, а затем отправит их на сервер для обработки. Какая от этого выгода? Если вы расшифровываете данные на посреднике, а затем отправляете их на сервер, не означает ли это, что данные можно перехватить между ними? И если вы обойдете это, установив дополнительное SSL-соединение от посредника к серверу, не создаст ли это столько накладных расходов, что вообще не будет преимуществ в производительности для завершения на более раннем прыжке?
TL; DR: Это не так.
Переход от сети CDN на базе Интернета (например, Cloudflare) должен использовать HTTPS, иначе это будет небезопасно. Если у вас есть что-то вроде VPN для CDN, вы можете использовать это, или бывают случаи, когда внутренний обратный прокси-сервер используется для завершения SSL / TLS, а затем внутренний, за брандмауэром, переход к фактическим исходным серверам просто HTTP. Если Cloudflare не поддерживает подключение к исходным серверам, подобное VPN, он не будет полезен для разгрузки TLS (он по-прежнему полезен для других вещей, таких как обработка всплесков трафика и уменьшение задержки). В основном: «Гибкий SSL» - это не более безопасный чем "Выкл"; если вам нужен TLS для контента, который вы обслуживаете, я бы рекомендовал использовать «Полный строгий» с Cloudflare.
Важно отметить, что в этом сценарии Cloudflare по сути человек посередине. Это не атака как таковые, поскольку вы авторизовали их, но они могут делать все, что может сделать успешный злоумышленник типа «человек посередине»; его очень важно, что ты доверять им правильно исполнять свою роль! Это верно в любое время, когда TLS завершается вне вашей сферы контроля.
Граничный узел CDN предоставит клиенту сокращенное время установки HTTPS-соединения, если (вероятно) он находится ближе к клиенту, чем исходный сервер.
Другой прирост производительности связан с тем, что граничный узел CDN может кэшировать ответ исходного сервера на данный клиентский запрос, поэтому кэшированный ответ впоследствии может быть доставлен на аналогичные запросы от локальных конечных пользователей, быстрее, чем если бы он был доставлен источником. сервер.
Однако на граничном узле должен быть виден как запрос клиента (ключ кеша), так и ответ соответствующего источника (значение кеша). Завершение TLS - это единственный способ, которым граничный узел CDN может иметь необходимую видимость туннеля TLS.
Также обратите внимание, что граничные узлы CDN обычно могут быть настроены либо на (A) отправку простого HTTP обратно на ваш исходный сервер, либо (B) на использование HTTPS для формирования второй ветви зашифрованной связи с вашим исходным сервером.
Причина, по которой вам нужно раннее завершение SSL на границе, более близкой к клиенту, заключается в том, что это увеличивает производительность установления соединения для SSL за счет экономии времени приема-передачи. Но почему у SSL есть эта проблема? Обычное незашифрованное TCP-соединение имеет только одно рукопожатие. Это означает 1 обратный путь к исходному серверу. Допустим, поездка туда и обратно стоит 70 мс. Теперь у SSL-соединения есть трехстороннее рукопожатие. Это означает, что стоимость будет составлять 3 цикла туда и обратно, что увеличит задержку запроса до 210 мс. При использовании CDN или пограничного завершения SSL, как это, вы минимизируете эту задержку, потому что ваше время приема-передачи будет намного короче, в результате чего ваше трехстороннее подтверждение SSL будет быстрее по сравнению с переходом к исходному серверу.