diff options
Diffstat (limited to 'content/posts/2023-07-24-tls/index.md')
| -rw-r--r-- | content/posts/2023-07-24-tls/index.md | 68 |
1 files changed, 53 insertions, 15 deletions
diff --git a/content/posts/2023-07-24-tls/index.md b/content/posts/2023-07-24-tls/index.md index 0a025a8..da413dc 100644 --- a/content/posts/2023-07-24-tls/index.md +++ b/content/posts/2023-07-24-tls/index.md @@ -5,29 +5,63 @@ tags = ['it', 'Россия', 'TLS'] title = 'Немного мыслей о TLS (HTTPS) в России' +++ -Накопилось немного мыслей относительно того, что может грозить нам (и мне) в связи с трендом на “балканизацию” рунета. +Накопилось немного мыслей относительно того, что может грозить нам (и мне) в +связи с трендом на “балканизацию” рунета. -И самое болезненное место — HTTPS который нынче стандарт де-факто в современных интернетах. А болезненное оно потому, что целиком и полностью контролируется другой стороной нынешного противостояния. Все доверенные удостоверяющие центры принадлежат странам “коллективного запада”. Помню, были ещё какие-то китайские, вроде, но с ними был какой-то скандал и не факт что они есть. +И самое болезненное место — HTTPS который нынче стандарт де-факто в современных +интернетах. А болезненное оно потому, что целиком и полностью контролируется +другой стороной нынешного противостояния. Все доверенные удостоверяющие центры +принадлежат странам “коллективного запада”. Помню, были ещё какие-то китайские, +вроде, но с ними был какой-то скандал и не факт что они есть. -Есть относительно [доверенный УЦ от Минцифры](https://www.gosuslugi.ru/tls). Это здорово и я это всецело поддерживаю. Вот только есть момент. Он не для нас, простых людей, и при попытке его получить видим то, что на скриншоте ниже. А сранный Firefox вообще хочет его внести в черный список, чтобы даже специально его нельзя было установить. В общем, пока его я поставить не могу даже при всём желании. +Есть относительно [доверенный УЦ от Минцифры](https://www.gosuslugi.ru/tls). Это +здорово и я это всецело поддерживаю. Вот только есть момент. Он не для нас, +простых людей, и при попытке его получить видим то, что на скриншоте ниже. А +сранный Firefox вообще хочет его внести в черный список, чтобы даже специально +его нельзя было установить. В общем, пока его я поставить не могу даже при всём +желании. - + Какие ещё альтернативы есть, если нас вдруг прокинет Let’s encrypt? -1. Не использовать HTTPS вообще. Я же не магазин и у меня нет форм логина, которые требуют шифрования. Так-то оно так, да не так. Браузеры уже сейчас очень косо смотрят на “обычные”, не HTTPS сайты, а в дальнейшем, не удивлюсь если перестанут открывать вообще. Так же на HTTP сайтах не работают прикольные браузерные API типа геолокации (наверное, это в каком-то роде даже плюс 😉 ). Ну и ещё проблема, что, например, этот сайт без HTTPS вообще не может работать, ибо для доменов зоны .dev насильно включено HSTS и они не могут работать не по HTTPS. Последнее то я решу старым добрым доменом neonxp.ru, но тем не менее. -2. Самоподписанные сертификаты. Вот это уже более менее похоже на правду! Да, такие сайты надо добавлять в исключения и мороки с сертификатами чуть больше. Но тут та же история с доменами .dev. Для них самоподписаные не катят. Выход — опять таки старый добрый neonxp.ru. +1. Не использовать HTTPS вообще. Я же не магазин и у меня нет форм логина, + которые требуют шифрования. Так-то оно так, да не так. Браузеры уже сейчас + очень косо смотрят на “обычные”, не HTTPS сайты, а в дальнейшем, не удивлюсь + если перестанут открывать вообще. Так же на HTTP сайтах не работают + прикольные браузерные API типа геолокации (наверное, это в каком-то роде даже + плюс 😉 ). Ну и ещё проблема, что, например, этот сайт без HTTPS вообще не + может работать, ибо для доменов зоны .dev насильно включено HSTS и они не + могут работать не по HTTPS. Последнее то я решу старым добрым доменом + neonxp.ru, но тем не менее. +2. Самоподписанные сертификаты. Вот это уже более менее похоже на правду! Да, + такие сайты надо добавлять в исключения и мороки с сертификатами чуть больше. + Но тут та же история с доменами .dev. Для них самоподписаные не катят. Выход + — опять таки старый добрый neonxp.ru. -К чему я всё это? А то что в случае “балканизации” мы остаемся без нормального валидного HTTPS. Для себя я выбрал второй путь, с самоподписанными сертификатами. Чекнуть как работает можно на зеркале блога на <https://neonxp.ru> . Там я выпустил сам себе сертификат на домен от своего собственного удостоверяющего центра 🙂 А доверять ему или не доверять — дело посетителей сайта. +К чему я всё это? А то что в случае “балканизации” мы остаемся без нормального +валидного HTTPS. Для себя я выбрал второй путь, с самоподписанными +сертификатами. Чекнуть как работает можно на зеркале блога на +<https://neonxp.ru> . Там я выпустил сам себе сертификат на домен от своего +собственного удостоверяющего центра 🙂 А доверять ему или не доверять — дело +посетителей сайта. -Если доверяете мне то [вот сертификат моего УЦ](/files/root_ca.crt), а установка такая же как сертификата Минцифры 🙂 +Если доверяете мне то [вот сертификат моего УЦ](/files/root_ca.crt), а установка +такая же как сертификата Минцифры 🙂 Ну и совсем краткая инструкция как выпустить сертификат для себя: -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` — генерируем файл запроса для конкретного сайта +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] @@ -36,11 +70,15 @@ title = 'Немного мыслей о TLS (HTTPS) в России' DNS.1 = neonxp.ru DNS.2 = *.neonxp.ru ``` -6. И, наконец, создаем сертификат для сайта, который будет подписан ключами server.key и root\_ca.key (то есть и своим удостоверяющим центром тоже): +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 в доверенные для себя. +В общем, всё. Полученные root_ca.crt (но не root_ca.key!), server.key и +server.crt можно вносить в конфигурацию используемого вебсервера. А так же +внести root_ca.crt в доверенные для себя. -Так у меня выглядят [сертификат на сайт](/img/posts/20230724_204209.webp) и [сертификат УЦ](/img/posts/20230724_204325.webp).
\ No newline at end of file +Так у меня выглядят [сертификат на сайт](/img/posts/20230724_204209.webp) и +[сертификат УЦ](/img/posts/20230724_204325.webp).
\ No newline at end of file |