Mastodon on ZHub

0 posts0 participants0 posts today

HabrАрхитектурные различия DNSSEC, DNS-over-TLS, HTTP-over-TLSНа вкус и цвет - все фломастеры разные. Это, впрочем, не мешает излишнему смешению технологий защиты DNS, с технологиями защиты трафика и с технологиями защиты DNS-данных. Рассмотрим, как и на каких уровнях используются криптографические протоколы при работе c DNS, выясним, можно ли всё свести к TLS для веба.<a href="https://habr.com/ru/articles/883910/" target="_blank" rel="nofollow noopener noreferrer" translate="no">https://habr.com/ru/articles/883910/</a><a href="https://zhub.link/tags/dns" class="mention hashtag" rel="tag">#dns</a> <a href="https://zhub.link/tags/tls" class="mention hashtag" rel="tag">#tls</a> <a href="https://zhub.link/tags/dnssec" class="mention hashtag" rel="tag">#dnssec</a> <a href="https://zhub.link/tags/%D0%B8%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F_%D0%B1%D0%B5%D0%B7%D0%BE%D0%BF%D0%B0%D1%81%D0%BD%D0%BE%D1%81%D1%82%D1%8C" class="mention hashtag" rel="tag">#информационная_безопасность</a> <a href="https://zhub.link/tags/%D0%B8%D0%BD%D1%84%D1%80%D0%B0%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%82%D1%83%D1%80%D0%B0" class="mention hashtag" rel="tag">#инфраструктура</a>

Christian🚨 Fixing the PKI Mess: CAA + Your Own CA via DNS 🚨 Right now, any CA can issue a certificate for your domain. Even if you set a CAA record (`issue "letsencrypt.org"`), it only controls *who* can issue, not what cert is valid. This is broken. 🔐 What if we could fix this using DNS? <a href="https://social.uggs.io/tags/Introducing" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Introducing</a> CAA+CA Fingerprint: Self-Sovereign Certificate Authority Instead of just saying *which CA can issue*, you publish your own CA's fingerprint in DNS. If your CA issues a cert for `awesomecars.com`, browsers should validate it against the DNS-published CA key. 🔥 How It Works You run your own CA (because why trust the cartel?). You then publish: 1️⃣ A CAA record specifying your own CA (with a fingerprint! 🔥) 2️⃣ A DNS record with your CA’s public key (like DKIM but for TLS!) 🔹 Example DNS Setup for `awesomecars.com`: ``` awesomecars.com. IN CAA 0 issue "pki.awesomecars.com; sha256=abcd1234..." pki.awesomecars.com. IN CERT 6 0 0 (--BEGIN CERTIFICATE-- ....) ``` Now, only certs signed by your CA are valid for `awesomecars.com`, even if another CA is tricked into issuing a rogue cert. No more CA hijacking! 🚀 Why Is This Better Than the Current CA Model? ✅ Self-Sovereign Identity: If you own the domain, you should own its PKI. ✅ Prevents Rogue Certs: No government or rogue CA can fake a cert for your domain. ✅ Works Like DKIM for Email: Your CA’s public key is stored in DNSSEC-protected records, just like DKIM keys for email signing. ✅ No More External Trust Issues: You control your CA entirely, instead of relying on Google’s CA store. ✅ Perfect for Self-Hosting & Internal Networks: No need for external CA trust—your DNS is your trust model. 🔥 Why Isn’t This a Thing Already? Big Tech hates this idea because it removes their control: ❌ Google wants Certificate Transparency (CT), where they control which certs are logged. ❌ Commercial CAs make $$$ selling certs. This kills their business. ❌ DNSSEC adoption is intentionally kept low by the same companies who don’t want this to succeed. Browsers refuse to support TLSA for the same reason—they want centralized CA trust, not self-hosted PKI. 🔗 Who Needs to Implement This? 🚀 Self-hosters & Homelabs: Use this for your own infrastructure. 🚀 Email providers: Stop relying on public CAs! 🚀 Privacy-focused projects (Tor, Matrix, XMPP, Fediverse, etc.): A true decentralized PKI alternative. 🚀 Fediverse devs: Let’s push for DNS-based CA validation! What do you think? Would you trust your own CA in DNS over some random commercial CA? 🔁 Boost this if you want a decentralized PKI revolution! 🔥 This keeps the focus on self-hosting your own CA, highlights the security flaws of current PKI, and calls out Big Tech’s resistance to decentralized trust. <a href="https://social.uggs.io/tags/PKI" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#PKI</a> <a href="https://social.uggs.io/tags/Security" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Security</a> <a href="https://social.uggs.io/tags/DNSSEC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#DNSSEC</a> <a href="https://social.uggs.io/tags/DANE" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#DANE</a> <a href="https://social.uggs.io/tags/TLSA" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#TLSA</a> <a href="https://social.uggs.io/tags/CAA" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#CAA</a> <a href="https://social.uggs.io/tags/SelfHosting" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SelfHosting</a> <a href="https://social.uggs.io/tags/Fediverse" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Fediverse</a> <a href="https://social.uggs.io/tags/Privacy" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Privacy</a> <a href="https://social.uggs.io/tags/Decentralization" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Decentralization</a> <a href="https://social.uggs.io/tags/dns" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#dns</a> <a href="https://social.uggs.io/tags/linux" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#linux</a>

KR. Laboratories 🇺🇦5 РОКІВ DNS-ЗОНА MASTERCARD МІСТИЛА ДРУКАРСЬКУ ПОМИЛКУУ червні 2020 року дослідник Філіп Катуреллі (CEO of Seralys) помітив, що в DNS-зоні всесвітньовідомого платіжного сервісу MasterCard один із неймсерверів (Akamai) введено з помилкою: замість "akam.net" вказано "akam.ne".Хибна конфігурація дивним чином зберігалася аж 5 років, поки про неї публічно не заговорили в LinkedIn (<a href="https://www.linkedin.com/feed/update/urn:li:activity:7285038365236682753/" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://www.linkedin.com/feed/update/urn:li:activity:7285038365236682753/</a>). Подібна недбалість дозволяла будь-кому відкрити домен akam.ne і перенаправляти трафік MasterCard до себе...Найбільше здивувала (і обурила) громадськість реакція самої компанії, яка заперечувала, що помилка в DNS якось може критично вплинути на їх безпеку. Мовляв, нічого страшного, все впорядку.Пізніше Катуреллі розповів, що зловмисникам достатньо було купити за 300 доларів домен в нігерійського реєстратора (доменна зона верхнього рівня .ne) і зачекати 3 місяці на обробку заявки. Після цього вони могли спокійно відкривати електронну пошту на домені akam.ne і отримувати корпоративні email-листи, відправлені на сервери MasterCard! І це найменше, що можна було здійснити.Але дослідник - красунчик. Все-таки не став зловживати, а в цілях безпеки сам зареєстрував домен і повідомив в MasterCard. Хоча ті й надалі продовжували заперечувати, навіть не відшкодували йому тих 300 доларів, які він витратив на реєстрацію домену. Просто мовчки усунули друкарську помилку і все... А його звіт на BugCrowd чомусь заблокували.Що цікаво, як розповідає дослідник Браян Кребс (<a href="https://krebsonsecurity.com" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://krebsonsecurity.com</a>), і тут не обійшлося без російського сліду. У 2016 році хтось на рф зареєстрував цей домен і кілька років переспрямовував його на IP-адресу в Німеччині (185.53.177.31), імовірно з метою проведення якихось маніпуляцій і махінацій...Ось так! Більш кращого прикладу про важливість безпеки DNS я ще не зустрічав. Одна помилка може відкрити двері для цілого ряду атак: "Людина посередині" (Man-in-the-Middle), фішингу, спуфінгу, перехоплення даних та багато-багато іншого.Одразу пригадалася одна історія з мого професійного досвіду. Якось звернулася до мене за послугами одна серйозна конторка. Я довго і нудно намагався їх переконувати, що головна проблема криється саме в DNS - треба негайно перевірити усі записи, зокрема NS-сервери, і бажано перевести домен на обслуговування до іншого реєстратора та додатково підключити DNS Cloudflare, аби унеможливити подальші маніпуляуції. На що мені вперто відповідали: "Ні. У нас там нема проблем. NS-сервери не можуть бути загрозою. У нас все впорядку. Доступ до DNS не надаємо. Можемо надати тільки скріншот". Таким чином вони довго і нудно шукали проблему в SSL-сертифікатах, вихідному коді, хостингу, CMS, але тільки не в DNS.... А зловмисники тим часом по повній в тиху експлуатували вразливі NS-сервери та помилки конфіігурації, здійснюючи колосальний репутаційний ризик для компанії. Тепер я чудово розумію, чому так. Мабуть це вже своєрідний "комплекс" або "синдром", присутній у великих компаніях - відкидати і заперечувати все, що стосується безпеки. "Синдром Федорова", я би так це назвав!Однак він може дуже дорого коштувати.Так що, як сказав Катуреллі, цитую: "Не будьте схожими на Mastercard... Не відкидайте ризик і не дозволяйте своїй маркетинговій команді розкривати інформацію про безпеку...".<a href="https://infosec.exchange/tags/cybersecurity" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#cybersecurity</a> <a href="https://infosec.exchange/tags/cybercrime" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#cybercrime</a> <a href="https://infosec.exchange/tags/mastercard" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#mastercard</a> <a href="https://infosec.exchange/tags/%D0%BA%D1%96%D0%B1%D0%B5%D1%80%D0%B1%D0%B5%D0%B7%D0%BF%D0%B5%D0%BA%D0%B0" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#кібербезпека</a> <a href="https://infosec.exchange/tags/stories" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#stories</a> <a href="https://infosec.exchange/tags/security" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#security</a> <a href="https://infosec.exchange/tags/infosec" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#infosec</a> <a href="https://infosec.exchange/tags/%D0%B1%D0%B5%D0%B7%D0%BF%D0%B5%D0%BA%D0%B0" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#безпека</a> <a href="https://infosec.exchange/tags/itsecurtiy" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#itsecurtiy</a> <a href="https://infosec.exchange/tags/dnssec" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#dnssec</a> <a href="https://infosec.exchange/tags/dns" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#dns</a>

HabrCAA и DNSSEC вкратце: как, зачем и поверхность атакиВ рамках проекта «Монитор госсайтов» мы стараемся не только демонстрировать, какие все кругом неумехи и лодыри (а мы – в белом жабо), но и показать, что безопасность веб-сайта – это просто, приятно и полезно. Сегодня расскажем о паре технологий, поддержка которых относится к группе А+ нашей методики, то есть желательно, но не обязательно – CAA и DNSSEC.<a href="https://habr.com/ru/articles/791068/" target="_blank" rel="nofollow noopener noreferrer" translate="no">https://habr.com/ru/articles/791068/</a><a href="https://zhub.link/tags/DNS" class="mention hashtag" rel="tag">#DNS</a> <a href="https://zhub.link/tags/CAA" class="mention hashtag" rel="tag">#CAA</a> <a href="https://zhub.link/tags/DNSSEC" class="mention hashtag" rel="tag">#DNSSEC</a> <a href="https://zhub.link/tags/DoT" class="mention hashtag" rel="tag">#DoT</a> <a href="https://zhub.link/tags/DoH" class="mention hashtag" rel="tag">#DoH</a>

BellingcatКто-то удалил адресную книгу Рунета?Пользователи Рунета сообщают о недоступности ключевых сервисов и ресурсов в зоне .ru. Почему пропала связность в российском сегменте интернета? Технические специалисты дают ответ: «у зоны RU сломался DNSSEC»Что это значит на русском языке?Похоже, что продолжаются эксперименты с созданием национального сервиса доменных имен (DNS - Domain Name Server). Он представляет из себя что-то вроде адресной книги, которая связывает привычные нам доменные адреса (URL) вроде kremlin.ru в машиночитаемые IP-адреса вроде 95.173.136.70.Когда мы вводим URL в поле поиска браузера, то браузер вначале обращается к адресной книге (DNS), а оттуда получает данные об IP на который необходимо перейти, чтобы попасть на нужный нам сайт. Соединение доменного имени (привычного нам адреса) и IP (цифрового адреса) называется резолвинг. Однако если DNS не работает, то браузер не сможет найти сайт.DNS имеет защиту в виде цифровой подписи, которая называется DNSSEC. Она защищает эту главную адресную книгу от подмены злоумышленниками.Российские власти давно предупреждали, что постараются перевести всех пользователей страны на национальный сервер DNS. Вероятно, именно это сейчас и происходит с массой сайтов в зоне .ruКак решить эту проблему?1⃣ Пользователям – принудительно настроить использование DNS-серверов, не имеющих отношение к российским провайдерам, например Google 8.8.8.8.2⃣ Владельцам сайтов – учиться пользоваться сетями TOR или Yggdrasil, уводить свои ресурсы туда, подальше от контролируемых публичных DNS.А вообще все очень плохо.⚠ Еще одна проблема заключается в том, что если эксперимент удастся, и национальный DNS сервер всё же будет запущен (начнет резолвить сайты для всех российских пользователей), то нет никакой гарантии, что он будет приводить ваши браузеры именно к тем сайтам, которые вы запросили, а также не будет фиксировать и передавать куда следует факты обращений с IP адресами.<a href="https://zhub.link/tags/DNS" class="mention hashtag" rel="tag">#DNS</a> <a href="https://zhub.link/tags/DNSSEC" class="mention hashtag" rel="tag">#DNSSEC</a> <a href="https://zhub.link/tags/%D0%A0%D1%83%D0%BD%D0%B5%D1%82" class="mention hashtag" rel="tag">#Рунет</a> <a href="https://zhub.link/tags/%D0%98%D0%BD%D1%82%D0%B5%D1%80%D0%BD%D0%B5%D1%82" class="mention hashtag" rel="tag">#Интернет</a> <a href="https://zhub.link/tags/%D0%A2%D0%B5%D1%85%D0%BD%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B5%D0%9F%D1%80%D0%BE%D0%B1%D0%BB%D0%B5%D0%BC%D1%8B" class="mention hashtag" rel="tag">#ТехническиеПроблемы</a> <a href="https://zhub.link/tags/%D0%A1%D0%B5%D1%80%D0%B2%D0%B8%D1%81%D1%8B" class="mention hashtag" rel="tag">#Сервисы</a> <a href="https://zhub.link/tags/%D0%A0%D0%BE%D1%81%D1%81%D0%B8%D1%8F" class="mention hashtag" rel="tag">#Россия</a> <a href="https://zhub.link/tags/%D0%AD%D0%BA%D1%81%D0%BF%D0%B5%D1%80%D0%B8%D0%BC%D0%B5%D0%BD%D1%82" class="mention hashtag" rel="tag">#Эксперимент</a> <a href="https://zhub.link/tags/%D0%9D%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B9DNS" class="mention hashtag" rel="tag">#НациональныйDNS</a> <a href="https://zhub.link/tags/%D0%A2%D0%B5%D1%85%D0%BD%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B5%D0%A1%D0%BF%D0%B5%D1%86%D0%B8%D0%B0%D0%BB%D0%B8%D1%81%D1%82%D1%8B" class="mention hashtag" rel="tag">#ТехническиеСпециалисты</a> <a href="https://zhub.link/tags/%D0%9A%D0%B8%D0%B1%D0%B5%D1%80%D0%B1%D0%B5%D0%B7%D0%BE%D0%BF%D0%B0%D1%81%D0%BD%D0%BE%D1%81%D1%82%D1%8C" class="mention hashtag" rel="tag">#Кибербезопасность</a> <a href="https://zhub.link/tags/%D0%9F%D1%80%D0%B8%D0%B2%D0%B0%D1%82%D0%BD%D0%BE%D1%81%D1%82%D1%8C" class="mention hashtag" rel="tag">#Приватность</a> <a href="https://zhub.link/tags/GoogleDNS" class="mention hashtag" rel="tag">#GoogleDNS</a> <a href="https://zhub.link/tags/TOR" class="mention hashtag" rel="tag">#TOR</a> <a href="https://zhub.link/tags/Yggdrasil" class="mention hashtag" rel="tag">#Yggdrasil</a> <a href="https://zhub.link/tags/%D0%A1%D0%B5%D1%82%D0%B8" class="mention hashtag" rel="tag">#Сети</a> <a href="https://zhub.link/tags/%D0%98%D0%BD%D1%82%D0%B5%D1%80%D0%BD%D0%B5%D1%82%D0%91%D0%B5%D0%B7%D0%BE%D0%BF%D0%B0%D1%81%D0%BD%D0%BE%D1%81%D1%82%D1%8C" class="mention hashtag" rel="tag">#ИнтернетБезопасность</a>

Recent searches

Search options

Administered by:

Server stats:

#dnssec