summaryrefslogtreecommitdiff
path: root/content/posts/2023-07-24-tls/index.md
diff options
context:
space:
mode:
Diffstat (limited to 'content/posts/2023-07-24-tls/index.md')
-rw-r--r--content/posts/2023-07-24-tls/index.md79
1 files changed, 79 insertions, 0 deletions
diff --git a/content/posts/2023-07-24-tls/index.md b/content/posts/2023-07-24-tls/index.md
new file mode 100644
index 0000000..edcf4c3
--- /dev/null
+++ b/content/posts/2023-07-24-tls/index.md
@@ -0,0 +1,79 @@
+---
+categories:
+ - Без рубрики
+date: "2023-07-24T20:04:17Z"
+tags:
+ - it
+ - Россия
+ - TLS
+title: Немного мыслей о TLS (HTTPS) в России
+---
+
+Накопилось немного мыслей относительно того, что может грозить нам (и мне) в
+связи с трендом на “балканизацию” рунета.
+
+И самое болезненное место — HTTPS который нынче стандарт де-факто в современных
+интернетах. А болезненное оно потому, что целиком и полностью контролируется
+другой стороной нынешного противостояния. Все доверенные удостоверяющие центры
+принадлежат странам “коллективного запада”. Помню, были ещё какие-то китайские,
+вроде, но с ними был какой-то скандал и не факт что они есть.
+
+Есть относительно [доверенный УЦ от Минцифры](https://www.gosuslugi.ru/tls). Это
+здорово и я это всецело поддерживаю. Вот только есть момент. Он не для нас,
+простых людей, и при попытке его получить видим то, что на скриншоте ниже. А
+сранный Firefox вообще хочет его внести в черный список, чтобы даже специально
+его нельзя было установить. В общем, пока его я поставить не могу даже при всём
+желании.
+
+Какие ещё альтернативы есть, если нас вдруг прокинет Let’s encrypt?
+
+1. Не использовать HTTPS вообще. Я же не магазин и у меня нет форм логина,
+ которые требуют шифрования. Так-то оно так, да не так. Браузеры уже сейчас
+ очень косо смотрят на “обычные”, не HTTPS сайты, а в дальнейшем, не удивлюсь
+ если перестанут открывать вообще. Так же на HTTP сайтах не работают
+ прикольные браузерные API типа геолокации (наверное, это в каком-то роде даже
+ плюс 😉 ). Ну и ещё проблема, что, например, этот сайт без HTTPS вообще не
+ может работать, ибо для доменов зоны .dev насильно включено HSTS и они не
+ могут работать не по HTTPS. Последнее то я решу старым добрым доменом
+ neonxp.ru, но тем не менее.
+2. Самоподписанные сертификаты. Вот это уже более менее похоже на правду! Да,
+ такие сайты надо добавлять в исключения и мороки с сертификатами чуть больше.
+ Но тут та же история с доменами .dev. Для них самоподписаные не катят. Выход
+ — опять таки старый добрый neonxp.ru.
+
+К чему я всё это? А то что в случае “балканизации” мы остаемся без нормального
+валидного HTTPS. Для себя я выбрал второй путь, с самоподписанными
+сертификатами. Чекнуть как работает можно на зеркале блога на
+<https://neonxp.ru> . Там я выпустил сам себе сертификат на домен от своего
+собственного удостоверяющего центра 🙂 А доверять ему или не доверять — дело
+посетителей сайта.
+
+Ну и совсем краткая инструкция как выпустить сертификат для себя:
+
+1. `openssl genrsa -out root_ca.key 4096` — создание секретного ключа УЦ (должен
+ храниться в безопасности!)
+2. `openssl req -x509 -new -key root_ca.key -days 3650 -out root_ca.crt` —
+ создаем сам сертификат УЦ (он НЕ секретный). Я указал срок действия 10 лет,
+ но это потому что я ленивый и не хочу его перегенеривать каждый год. Так
+ делать не советую.
+3. `openssl genrsa -out server.key 4096` — создаем секретный ключ уже для
+ конкретного сайта (и поддоменов)
+4. `openssl req -new -key server.key -subj "/CN=neonxp.ru/CN=*.neonxp.ru" -out
+server.csr` — генерируем файл запроса для конкретного сайта
+5. Создаем файл `openssl.cnf` с примерно таким содержимым:
+ ```
+ [SAN]
+ subjectAltName = @alt_names
+ [alt_names]
+ DNS.1 = neonxp.ru
+ DNS.2 = *.neonxp.ru
+ ```
+6. И, наконец, создаем сертификат для сайта, который будет подписан ключами
+ server.key и root_ca.key (то есть и своим удостоверяющим центром тоже):
+ ```
+ openssl x509 -req -in server.csr -CA root_ca.crt -CAkey root_ca.key -CAcreateserial -out server.crt -days 365 -extensions SAN -extfile openssl.cnf
+ ```
+
+В общем, всё. Полученные root_ca.crt (но не root_ca.key!), server.key и
+server.crt можно вносить в конфигурацию используемого вебсервера. А так же
+внести root_ca.crt в доверенные для себя.