🔒 Почему самоподписанные SSL-сертификаты в Unity — это просто красивый фантик

Привет, коллеги-разработчики! 🦊

Сегодня разберем больную тему: SSL-сертификаты в играх и почему ваш самоподписанный сертификат — это просто красивый фантик, а не магический щит безопасности.

Навеяно реальным диалогом:

— «А че ты внутри своей сети не сделаешь SSL? Ну, чтобы был httpS?»

— «...Опять объяснять.»

Мне надоело объяснять людям, что внутри приватных сетей (которые уже зашифрованы) это не имеет особого смысла, но давайте разберем почему самоподписанные сертификаты — это головная боль.

🤔 Как работает доверие в интернете?

Когда ваш браузер или Unity-клиент подключается к https://google.com, происходит магия:

1. Сервер показывает сертификат:

Привет, я Google, вот мой паспорт!

2. Клиент проверяет подпись:

А кто тебе этот паспорт выдал?

3. Центр сертификации подтверждает:

Это мы выдали, он настоящий Google!

Ваша ОС уже знает публичные ключи доверенных центров (Let's Encrypt, DigiCert и др.), так как предустановлены. Они могут проверить подпись и сказать: *«Да, этот сертификат выдан тем, кому мы доверяем. Это точно настоящий сервер.»*

🏠 А теперь про самоподписанные сертификаты

Вы решили сэкономить и сделать сертификат сами для my-game-server.local.

Что нужно сделать, чтобы это работало ПРАВИЛЬНО:

1. Создать собственный CA (Certificate Authority)
2. Выпустить сертификат для каждого сервера
3. Распространить корневой CA-сертификат на ВСЕ клиентские устройства
4. Добавить в доверенное хранилище каждой платформы (Windows/Android/iOS — везде по-разному!)
5. Настроить Unity правильно проверять цепочку доверия

Сложно? Еще как! И это только начало...

🤦‍♂️ Что обычно делают разработчики?

// Типичный "костыль":
ServicePointManager.ServerCertificateValidationCallback = 
    (sender, cert, chain, errors) => true; // ПРИНИМАЕМ ВСЁ ПОДРЯД!

Поздравляю! Вы только что превратили SSL в декорацию. Теперь любой может подсунуть вам поддельный сертификат.

⚠️ Как происходит MITM-атака?

Злоумышленник не просто "подменяет сертификат" — он создает два отдельных SSL-соединения:

Клиент
<--[SSL с фейковым сертом]-->
Атакующий
<--[SSL с настоящим]-->
Сервер

Что видит клиент: Зашифрованное соединение ✅
Что видит сервер: Зашифрованное соединение ✅
Что видит атакующий: Весь ваш трафик в открытом виде 💀

Он расшифровывает пакеты от клиента, читает/модифицирует их, зашифровывает заново и отправляет серверу. И наоборот.

🎯 Почему самоподписанные сертификаты уязвимы?

SSL решает две задачи:
- Шифрование (данные нечитаемы по пути) ✅
- Аутентификация (вы знаете, с кем говорите) ❌

Самоподписанный сертификат шифрует, но не аутентифицирует. Любой может создать сертификат для my-game-server.local и выдать себя за ваш сервер.

💡 Мое решение

Внутри WireGuard уже встроено шифрование с публичными/приватными ключами как для сервера, так и для клиента. Если хоть какой-то ключ расшифруется неверно — WireGuard мгновенно прервет сессию. Злоумышленник покажется сразу.

Внутри такой приватной сети SSL не имеет смысла — трафик уже защищен на уровне туннеля.

А для внешних портов?
- Публичный домен: обычный SSL от Let's Encrypt
- Чистый UDP/TCP: собственное асимметричное шифрование (RSA)

Но об этом — в следующем посте! 🔥

✅ Когда SSL имеет смысл?

Публичные серверы: Let's Encrypt или коммерческие CA (только для публичных доменов).

Корпоративные сети: Если есть PKI-инфраструктура и можете безопасно распространить корневые сертификаты.

🔥 Что дальше?

В следующем посте: собственное безопасное соединение в Unity — RSA-ключи, обмен ключами, шифрование AES, защита от replay-атак.

💭 А вы?

Сталкивались с "security theater" решениями? Жду истории в комментах!

#Unity3D #GameDev #InfoSec #SSL #HTTPS #MITM #Encryption #CSharp #Networking #ЛисыПишутКод