initial commit

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

@@ -0,0 +1,40 @@
+# Думки стосовно 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