gemlog/public/uk/thoughts-on-tls-on-yggdrasil-and-mycelium-networks.gmi

# Думки стосовно TLS в мережах Yggdrasil та Mycelium

В середовищі оверлейних мереж чомусь прийнято вважати, що якщо ключі вузлів перманентні, а з'єднання між вузлами захищене TLS, то додатковий шар SSL ніби як і не потрібний. Утім, останнім часом я починаю у цьому сумніватись.

## Компрометація ключа

В мережах типу Yggdrasil / Mycelium немає рівня складності при генерації приватних ключів, а отже теоретично (хоча і малоймовірно) можлива колізія. З цієї причини, рекомендується використовувати основні адреси замість підмереж, а останні - розробники планують, але ніяк не випиляють. Та й зручні вони в рамках шейред хосту. Все одно це не виключає можливості випадкового видобутку копії, або не випадкового, враховуючи потенційні можливості криптоіндустрії, питання лише доречності використання супер-комп'ютера для цієї мети; скільки ці мережі включатимуть користувачів і якого статку, для потенційних атак на роутинг, що базується на фіксованому алгоритмі побудови дерева з peer ID.

## Подвійний шар

Технічно, протокол транспорту Yggdrasil бере на себе роль шифрування трафіку тоді, коли це може бути не потрібно. Наприклад, у випадках:
* заощадження електроенергії та ресурсів CPU при пересиланні великих медіа файлів
* коли вже використовується шар SSL / HTTPS на програмному рівні - з метою уникнення перехоплень логіну/паролю чи просто конфіденційного пересилання запитів GET через проксі

Практичний приклад: вимога щодо шифрування трафіку Gemini в рамках Yggdrasil, бо перший хоче бути захищеним для Інтернет, але я використовую його не там, де задумував автор. З цієї причини, певний час користувався альтернативою Nex, але згодом усвідомив, що деякі дані потенційно можуть таки потребувати сертифікату, а отже, мені потрібна стара-добра модель HTTP+HTTPS на чутливих формах.

Якщо від клієнта до сервера передаються чутливі дані, то на мою думку, варто користуватись сертифікатом SSL, що слугуватиме запобіжником, але маршрутизатор вже про все "подбав", створивши зайві проблеми.

## Сертифікація в локальних мережах

Через ізоляцію локальних мереж, в Yggdrasil є проблемою налаштувати валідний сертифікат, наприклад з Let's Encrypt. Але у випадку протоколу Gemini - центри сертифікації не використовуються взагалі. Натомість застосовується принцип TOFU (Trust on First Use), що значно зменшує ризик перехоплення даних у часі - до моменту виявлення витоку. В мене навіть були такі думки стосовно організації внутрішньомережного центру сертифікації, чому б і ні; чому б навіть не зробити такий сервіс платним?

## Висновки

Коли і як саме шифрувати дані - має вирішувати користувач / адміністратор мережі, на ті потоки / дані які того потребують. Тоді як Yggdrasil та Mycelium - роблять це "добровільно-примусово" як, власне, й інші новомодні софти з лейблом "абсолютно сек'юрно". Сучасний софт, розробники якого конкурують за право називатись "захищеним" нагадує крипто-капусту з коефіцієнтом безпеки було == стало.

Чомусь вже починає дратувати, коли за мене щось хтось починає вирішувати там, де того не просять. Маркетинг - маркетингом, слогани - слоганами, але досвідчені юзери йдуть через подібний дискомфорт, а туристи й без того не затримуються.

А ще висновки такі, що ефективні мережні рішення були винайдені повоєнними спеціалістами пів сторіччя тому, які мусили виживати, а не гратись в комерційні експерименти. Нічого принципово нового за цей час не винайдено. Можливо, наступним проривом стане квантова передача даних, а не подібний нонсенс: прокладати автоматичний маршрут до ймовірно компрометованих вузлів, при цьому шифрувати тони сміття, що ходить ним.

## Посилання

=> https://devzone.org.ua/post/dumky-stosovno-tls-v-merezakh-yggdrasil-ta-mycelium Веб-версія цього матеріалу з коментарями на DevZone
=> https://en.wikipedia.org/wiki/Trust_on_first_use
=> https://github.com/threefoldtech/mycelium

### Дивіться також

=> yggdrasil-is-network-with-distributed-routing.gmi Yggdrasil - мережа з децентралізованою маршрутизацією
=> nex-lightweight-gemini-alternative.gmi Протокол NEX - легка альтернатива Gemini