Skip to content

Commit

Permalink
fix translation
Browse files Browse the repository at this point in the history
  • Loading branch information
@emp7yhead
emp7yhead committed Nov 2, 2022
1 parent dfc8d74 commit 0936686
Showing 1 changed file with 13 additions and 13 deletions.
26 changes: 13 additions & 13 deletions docs/ru/docs/deployment/https.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5,33 +5,33 @@
Но все гораздо сложнее, чем кажется.

!!! Подсказка
Если вы торопитесь или вам все равно, читайте следующие разделы пошаговой инструкции по настройке развертывания с использованием различных технологий.
Если вы торопитесь или вам неинтересно, читайте следующие разделы пошаговой инструкции по настройке развертывания с использованием различных технологий.

Чтобы **понять основы HTTPS** с точки зрения пользователя, изучите <a href="https://howhttps.works/ru/" class="external-link" target="_blank">https://howhttps.works/</a>.

Итак, **с точки зрения разработчика** есть несколько вещей, которые надо держать в уме, размышляя о HTTPS:
**С точки зрения разработчика** нужно учитывать следующие особенности работы функционирования HTTPS:

* При использовании протокола HTTPS, **сервер** должен **обладать "сертификатами"**, сгенерированными **третьей стороной**.
* На самом деле, третья сторона **выдает** сертификаты, а не "генерирует".
* У сертификатов есть **срок действия**.
* Он **истекает**.
* После этого сертификаты необходимо **обновить**, **вновь получить** от третьей стороны.
* Шифрование соединения происходит на **TCP-уровне**.
* Шифрование соединения происходит на **уровне протокола TCP**.
* Это на один уровень **ниже HTTP**.
* Так что **сертификация и шифрование** выполняется **перед HTTP**.
* **TCP не знает о "доменах"**. Только об IP-адресах.
* Информация **о конкретном запрашиваемом домене** содержится в **данных HTTP**.
* **HTTPS-сертификаты** "сертифицируют" **определенный домен**, но протокол и шифрование происходит на TCP-уровне, **не зная** с каким доменом ведется работа.
* **HTTPS-сертификаты** "сертифицируют" **определенный домен**, но выбор протокола и шифрование происходит на уровне протокола TCP, когда имя домена еще **неизвестно**.
* **По умолчанию**, это означает, что вы можете иметь только **один HTTPS-сертификат на IP-адрес**.
* Вне зависимости от того, насколько большой у вас сервер или насколько малы приложения, которые имеются на нем.
* Несмортря на это, имеется **решение** данной проблемы.
* Существует **расширение** протокола **TLS** (того, что управляет шифрованием на TCP-уровне, перед HTTP), которое называется **<a href="https://ru.wikipedia.org/wiki/Server_Name_Indication" class="external-link" target="_blank"><abbr title="Индикация имени сервера">SNI</abbr></a>**.
* Существует **расширение** протокола **TLS** (того, что управляет шифрованием на TCP-уровне, перед HTTP), которое называется **<a href="https://ru.wikipedia.org/wiki/Server_Name_Indication" class="external-link" target="_blank"><abbr title="Указание имени сервера">SNI</abbr></a>**.
* Расширение SNI позволяет одному серверу (**с одним IP-адресом**) иметь **несколько HTTPS-сертификатов** и обслуживать **несколько HTTPS-доменов/приложений**.
* Для работы SNI необходимо, чтобы **один** компонент (программа), запущенный на сервере и слушающий **публичный IP-адрес**, должен иметь доступ ко **всем HTTPS-сертификатам** на сервере.
* Для работы SNI необходимо, чтобы **один** компонент (программа), запущенный на сервере и слушающий **публичный IP-адрес**, имел доступ ко **всем HTTPS-сертификатам** на сервере.
* **После** установления защищенного соединения, в качестве протокола соединения все еще **используется HTTP**.
* Данные **шифруются**, даже несмотря на то, что они посылаются с использованием **протокола HTTP**.

Нормальной практикой является ситуация, при которой **одна программа/HTTP-сервер**, запущенный на сервере (машине, хосте, и т.д.) и **управлениющий всеми частями HTTPS**: получение **зашифрованных HTTPS запросов**, отправка **расшифрованных HTTP запросов** конкретному HTTP приложению, запущенному на данном сервере (в нашем случае приложение **FastAPI**), прием **HTTP ответа** от приложения, **его шифрование** при помощи соответствующего **HTTPS сертификата** и его дальнейшая отправка обратно клиенту, используя **HTTPS**. Такой сервер зовется **<a href="https://en.wikipedia.org/wiki/TLS_termination_proxy" class="external-link" target="_blank">прокси-сервер завершения TLS</a>**.
Нормальной практикой является ситуация, при которой **одна программа/HTTP-сервер**, запущенный на сервере (машине, хосте, и т.д.) и **управлениющий всеми частями HTTPS**: получение **зашифрованных HTTPS запросов**, отправка **расшифрованных HTTP запросов** конкретному HTTP приложению, запущенному на данном сервере (в нашем случае приложению **FastAPI**), прием **HTTP ответа** от приложения, **его шифрование** при помощи соответствующего **HTTPS сертификата** и его дальнейшая отправка обратно клиенту, используя **HTTPS**. Такой сервер называется **<a href="https://en.wikipedia.org/wiki/TLS_termination_proxy" class="external-link" target="_blank">прокси-сервер завершения TLS</a>**.

Ниже представлены варианты, которые вы можете использовать как прокси-сервер завершения TLS:

Expand Down Expand Up @@ -77,7 +77,7 @@

Во-первых, браузер проверяет с помощью **DNS-серверов**, какой **IP-адрес у домена**, в данном случае `someapp.example.com`.

DNS-сервера подскажут браузеру какой конкретный **IP-адрес** использовать. Это будет публичный IP-адрес, используемый вашим сервером, который вы настроили в DNS-серверах.
DNS-сервера подскажут браузеру, какой конкретный **IP-адрес** использовать. Это будет публичный IP-адрес, используемый вашим сервером, который вы настроили в DNS-серверах.

<img src="/img/deployment/https/https01.svg">

Expand All @@ -93,7 +93,7 @@ DNS-сервера подскажут браузеру какой конкре

### TLS с SNI расширением

**Только один процесс** на сервере может слушать определенный **порт** на определенном **IP-адресе**. Могут быть и другие процессы, слушающие на других портах тот же самый IP-адрес, но только один процесс для каждой комбинации IP-адреса и порта.
**Только один процесс** на сервере может слушать определенный **порт** на определенном **IP-адресе**. Могут быть и другие процессы, слушающие на других портах тот же самый IP-адрес, но может быть только один процесс для каждой комбинации IP-адреса и порта.

TLS (HTTPS) по умолчанию использует порт `443`. Так что, именно этот порт нам и нужен.

Expand Down Expand Up @@ -128,7 +128,7 @@ TLS (HTTPS) по умолчанию использует порт `443`. Так

### Расшифровка запроса

Прокси-сервер завершения TLS будет использовать выбранный способ шифрования для **расшифровки запроса**, и перенаправит **простой (расшифрованный) HTTP-запрос** процессу запущенного приложения (например процесс Uvicorn с запущенным приложением FastAPI).
Прокси-сервер завершения TLS будет использовать выбранный способ шифрования для **расшифровки запроса**, и перенаправит **простой (расшифрованный) HTTP-запрос** процессу запущенного приложения (например, процессу Uvicorn с запущенным приложением FastAPI).

<img src="/img/deployment/https/https05.svg">

Expand All @@ -140,9 +140,9 @@ TLS (HTTPS) по умолчанию использует порт `443`. Так

### HTTPS ответ

Прокси-сервер завершения TLS **зашифрует ответ** с использованием выбранного способа шифрования (that started with the certificate for `someapp.example.com`), и отправит его обратно браузеру.
Прокси-сервер завершения TLS **зашифрует ответ** с использованием выбранного способа шифрования (который начался с сертификата для `someapp.example.com`), и отправит его обратно браузеру.

Далее, браузер удостоверится что ответ валиден, зашифрован правильным криптографическим ключом и т.д. Затем он **расшифровывает ответ** и обрабатывает его.
Далее, браузер удостоверится, что ответ валиден, зашифрован правильным криптографическим ключом и т.д. Затем он **расшифровывает ответ** и обрабатывает его.

<img src="/img/deployment/https/https07.svg">

Expand Down Expand Up @@ -177,7 +177,7 @@ TLS (HTTPS) по умолчанию использует порт `443`. Так
* **Запуск в качестве сервера** (по крайней мере, на время получения сертификата) на публичном IP-адресе, связанном с доменом.
* Как было сказано выше, только один процесс может слушать определенный IP и порт.
* По этой причине удобно, когда прокси-сервер завершения TLS управляет процессом обновления сертификата.
* С другой стороны, you might have to stop the TLS Termination Proxy momentarily, start the renewal program to acquire the certificates, then configure them with the TLS Termination Proxy, and then restart the TLS Termination Proxy. This is not ideal, as your app(s) will not be available during the time that the TLS Termination Proxy is off.
* С другой стороны, вы можете остановить прокси-сервер завершения TLS и запустить программу обновления для получения сертификатов, насторить их для работы с прокси-сервером завершения TLS и после этого перезапустить его. Не лучший вариант, так как ваше приложение (приложения) будут недоступны пока отключен прокси-сервер завершения TLS.

Весь этот процесс обновления, во время обслуживания приложения, главная причина по которой важно иметь **отдельную систему управления HTTPS** с прокси-сервером завершения TLS вместо простого использования TLS-сертификатов с приложением напрямую сервером (например Uvicorn).

Expand Down

0 comments on commit 0936686

Please sign in to comment.