Christian<p>🚨 Fixing the PKI Mess: CAA + Your Own CA via DNS 🚨 </p><p>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. </p><p>🔐 What if we could fix this using DNS? </p><p><a href="https://social.uggs.io/tags/Introducing" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Introducing</span></a> CAA+CA Fingerprint: Self-Sovereign Certificate Authority<br>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. </p><p>🔥 How It Works<br>You run your own CA (because why trust the cartel?). You then publish: <br>1️⃣ A CAA record specifying your own CA (with a fingerprint! 🔥) <br>2️⃣ A DNS record with your CA’s public key (like DKIM but for TLS!) </p><p>🔹 Example DNS Setup for `awesomecars.com`: <br>```<br>awesomecars.com. IN CAA 0 issue "pki.awesomecars.com; sha256=abcd1234..."<br>pki.awesomecars.com. IN CERT 6 0 0 (--BEGIN CERTIFICATE-- ....)<br>```<br>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! </p><p>🚀 Why Is This Better Than the Current CA Model?<br>✅ Self-Sovereign Identity: If you own the domain, you should own its PKI. <br>✅ Prevents Rogue Certs: No government or rogue CA can fake a cert for your domain. <br>✅ Works Like DKIM for Email: Your CA’s public key is stored in DNSSEC-protected records, just like DKIM keys for email signing. <br>✅ No More External Trust Issues: You control your CA entirely, instead of relying on Google’s CA store. <br>✅ Perfect for Self-Hosting & Internal Networks: No need for external CA trust—your DNS is your trust model. </p><p>🔥 Why Isn’t This a Thing Already?<br>Big Tech hates this idea because it removes their control: <br>❌ Google wants Certificate Transparency (CT), where they control which certs are logged. <br>❌ Commercial CAs make $$$ selling certs. This kills their business. <br>❌ DNSSEC adoption is intentionally kept low by the same companies who don’t want this to succeed. </p><p>Browsers refuse to support TLSA for the same reason—they want centralized CA trust, not self-hosted PKI. </p><p>🔗 Who Needs to Implement This?<br>🚀 Self-hosters & Homelabs: Use this for your own infrastructure. <br>🚀 Email providers: Stop relying on public CAs! <br>🚀 Privacy-focused projects (Tor, Matrix, XMPP, Fediverse, etc.): A true decentralized PKI alternative. <br>🚀 Fediverse devs: Let’s push for DNS-based CA validation! </p><p>What do you think? Would you trust your own CA in DNS over some random commercial CA? </p><p>🔁 Boost this if you want a decentralized PKI revolution! </p><p>🔥 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. </p><p><a href="https://social.uggs.io/tags/PKI" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>PKI</span></a> <a href="https://social.uggs.io/tags/Security" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Security</span></a> <a href="https://social.uggs.io/tags/DNSSEC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>DNSSEC</span></a> <a href="https://social.uggs.io/tags/DANE" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>DANE</span></a> <a href="https://social.uggs.io/tags/TLSA" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>TLSA</span></a> <a href="https://social.uggs.io/tags/CAA" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>CAA</span></a> <a href="https://social.uggs.io/tags/SelfHosting" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>SelfHosting</span></a> <a href="https://social.uggs.io/tags/Fediverse" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Fediverse</span></a> <a href="https://social.uggs.io/tags/Privacy" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Privacy</span></a> <a href="https://social.uggs.io/tags/Decentralization" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Decentralization</span></a> <a href="https://social.uggs.io/tags/dns" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>dns</span></a> <a href="https://social.uggs.io/tags/linux" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>linux</span></a></p>
Recent searches
No recent searches
Search options
Only available when logged in.
federatedfandom.net is one of the many independent Mastodon servers you can use to participate in the fediverse.
This is a fandom instance run by imp (stopthatimp on Tumblr) and kate (madecunningly on tumblr). We are here to have fun.
Administered by:
Server stats:
160active users
federatedfandom.net: About · Status · Profiles directory · Privacy policy
Mastodon: About · Get the app · Keyboard shortcuts · View source code · v4.3.4
#PKI
0 posts · 0 participants · 0 posts today
Karl Voit :emacs: :orgmode:<p><a href="https://graz.social/tags/Irreal" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Irreal</span></a>: Digital Vs. <a href="https://graz.social/tags/Analog" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Analog</span></a> <a href="https://graz.social/tags/Notes" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Notes</span></a><br><a href="https://irreal.org/blog/?p=12588" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">irreal.org/blog/?p=12588</span><span class="invisible"></span></a></p><p><a href="https://graz.social/tags/PIM" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>PIM</span></a> <a href="https://graz.social/tags/PKI" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>PKI</span></a> <a href="https://graz.social/tags/orgmode" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>orgmode</span></a> <a href="https://graz.social/tags/notetaking" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>notetaking</span></a> <a href="https://graz.social/tags/fountainpen" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>fountainpen</span></a> <a href="https://graz.social/tags/pen" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>pen</span></a> <a href="https://graz.social/tags/paper" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>paper</span></a></p>
Erik van Straten<p>🟡 INTRODUCTION/BACKGROUND<br>It has become *way too easy* and cheap, to anonymously (or lying about identity) register a domain name, hire or hack a server and obtain a valid DV (Domain Validated) server certificate.</p><p>Furthermore, possibly *stimulated* by the fact that most servers now use DV-certificates, (web) browsers have made it increasingly hard for internet users to view certificate details, without providing any alternatives for those users to distinguish between misleading fake and real (authentic) setvers.</p><p>A steadily increasing number of internet servers is now *anonymous* (it has been *deliberately* made impossible to reliably find out who is responsible), which has lead, and still leads, to huge amounts of unneccesary victims of phishing.</p><p>This causes enormous financial losses to individuals, companies, governmental and healthcare organizations - while most of that money flows into the pockets of criminals who often operate from regimes that are our enemies. Thereby, indirectly or directly, enriching those regimes (the rest of the stolen money flows into the pockets of hosting-, cloud- and CDN providers, as well as DNS registrars and domain name parking services).</p><p>Note: a server certificate never directly warants reliability of the owner of a domain name. However, in order to distinguish between fake and real servers or websites, it is essential that users know who is *responsible* and in which country they are established or live. Eventually, if neccessary, to be able to sue them.</p><p>🟡 From <a href="https://www.theregister.com/2024/09/03/white_house_bgp_security/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="ellipsis">theregister.com/2024/09/03/whi</span><span class="invisible">te_house_bgp_security/</span></a>:<br>«<br>White House thinks it's time to fix the insecure glue of the internet: Yup, BGP<br>3 Sep 2024, 22:34 utc - Thomas Claburn<br>[...]<br>"As initially designed and commonly operating today, BGP does not provide adequate security and resilience features for the risks we currently face," the report (<a href="https://whitehouse.gov/wp-content/uploads/2024/09/Roadmap-to-Enhancing-Internet-Routing-Security.pdf" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">whitehouse.gov/wp-content/uplo</span><span class="invisible">ads/2024/09/Roadmap-to-Enhancing-Internet-Routing-Security.pdf</span></a>) [PDF] says. "Concerns about fundamental vulnerabilities have been expressed for more than 25 years."<br>»</p><p>🟡 IMO, to not *first* fix WebPKI is plain *stupid* because:</p><p>➡️ If the *combination* of:<br>🔸 A *decent* WebPKI {1}, *and*<br>🔸 Improved browsers {2}, *and*<br>🔸 User education {3},<br>*enables* internet users to reliably distinguish between fake and real (authentic) servers, then the necessity for RPKI decreases enormously {4};</p><p>➡️ Apart from the fact that RPKI is fully hidden for internet users (they *neither* know whether it's used for their current IP-connections, and if that happens to be the case, *nor* how reliable the authentication of the parties involved took place), RPKI does *not* solve a much bigger problem: DNS-hijacks.</p><p>➡️ A decent WebPKI effectively mitigates the following vulnerabilities (in the order of most to least occuring):<br>🔸 People not knowing who is responsible for a given (often misleading) domain name;<br>🔸 DNS hijacks/attacks;<br>🔸 BGP hijacks;<br>🔸 AitM's {5} "near" the real server who unrightfully obtain DV-certificates.</p><p>Edited to add 2024-09-05 21:59 {<br>WebAuthn (as used by FIDO2 hardware keys and by passkeys) *ONLY* protects against the first vulnerability (in people who don't know that a given domain name does not belong to the apparent owner, but instead to an impostor). WebAuthn's phishing-resistance ceases to exist if a fake website obtains any type of certificate. However, while it's extermely easy for an attacker to obtain a DV-certificate, more trustworthy certificates should make that *a lot* harder.<br>}</p><p>🟡 {1} WHAT IS A DECENT WEBPKI<br>A *decent* WebPKI means that:</p><p>1️⃣ We must get rid of the current (effectively Google owned) CA/B forum, simply because server certificates exist primarily in the interest of *internet users* (not even represented in the CA/B forum) instead of it's current members: *commercial* cloud providers, browser makers, CA's (Certificate Authorities) and/or CSP's (Certificate Service Providers).</p><p>2️⃣ The world needs a new, independent, organization that supervises requirements of certificates, CA's and CSP's, as well as all requirements for (web) browsers related to certificates. For easy referencing I'll call it the WPKIF (Web Public Key Infrastructure Forum) in this toot. It is essential that internet users are strongly represented in the WPKIF. The WPKIF must be repeatedly audited by independent auditors (based on clear predefined requirements and/or controls).</p><p>3️⃣ Each *critical* server {6} *must* use a server certificate that, more or less reliably, uniquely defines the person, people or organization responsible for the server(s) (and content, security etc.) referenced by the server's domain name(s) included in the certificate.</p><p>4️⃣ The layout of server certificates needs an update to better serve internet users. Most of those users are *not* interested in technical details such as long serial numbers or hexadecimal public key values (such data must remain accessible for experienced users). So some sort of split between technical and *human readable" (not "CN=") information must be made.</p><p>5️⃣ Each server certificate must also contain a standardized indicator that reveals the *minimum* reliability of the authentication of the person, people or organization responsible for all domain names, and all servers referenced by all domain names (included in the certificate). In short: how certain is it that the owner of a website is who they claim to be.</p><p>6️⃣ Each server certificate must also contain a reference to a WPKIF website with a standardized indicator that reveals the *reliability* of the least reliable link in the chain starting at the applicable CA and ending with the CSP (including both ends plus intermediate certificates and their owners). In short: how reliable is the information in the certificate, as determined by the WPKIF.</p><p>7️⃣ The WPKIF must immediately and objectively take action against any CA, intermediate or CSP that violates the rules and requirements as defined by the WPKIF. Such by decreasing their reliability rating upto canceling their right to issue certificates.</p><p>🟡 {2} Web browsers (and perhaps other clients) must make it a lot easier for users to determine who is responsible for a server or website. IMO, at the very least when an internet user visits a website with a specific domain name *for the first time* (using that browser), *OR* when the server sends a new certificate, the browser should first show full details of the owner of the domain name *before* fetching any content - and let the user decide whether they want to continue and open the website. (Note: I've not given it enough thought how to handle third party websites - where CSS, JavaScript, images and/or analytics stuff is downloaded from).</p><p>🟡 {3} Internet users need to be educated about the importance of knowing who owns a domain name (and thus server and/or website). Browsers must play a role by offering tutorials. Current "awareness trainings" are simply insufficient (as notably Google found out, see <a href="https://security.googleblog.com/2024/05/on-fire-drills-and-phishing-tests.html" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">security.googleblog.com/2024/0</span><span class="invisible">5/on-fire-drills-and-phishing-tests.html</span></a> - more info, in Dutch: <a href="https://infosec.exchange/@ErikvanStraten/113045136092456532" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">infosec.exchange/@ErikvanStrat</span><span class="invisible">en/113045136092456532</span></a>).</p><p>🟡 {4} RPKI vs WebPKI<br>Increasingly cybercriminals succeed into hijacking cryptocurrency websites, and they may do so by hijacking BGP and subsequently acquiring a DV certificate for their fake server (examples can be found here: <a href="https://infosec.exchange/@ErikvanStraten/112914050216821746" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">infosec.exchange/@ErikvanStrat</span><span class="invisible">en/112914050216821746</span></a>). However, BGP hijack attacks are not easy to accomplish and often detected soon. In particular it will be hard for the attackers to obtain *trustworthy* server certificates. </p><p>🟡 {5} AitM = Attacker in the Middle. A server in a hosting center may be AitM'ed in the same center without touching the actual server itself and without requiring DNS- or BGP hijacks (because the AitM and the real server are both comnected to an internal network), as for example happened to "jabber.ru" in a German hosting center (see <a href="https://therecord.media/jabber-ru-alleged-government-wiretap-expired-tls-certificate" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">therecord.media/jabber-ru-alle</span><span class="invisible">ged-government-wiretap-expired-tls-certificate</span></a>, full details in <a href="https://notes.valdikss.org.ru/jabber.ru-mitm/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">notes.valdikss.org.ru/jabber.r</span><span class="invisible">u-mitm/</span></a>).</p><p>🟡 {6} A critical server is one whose *authenticity* and/or *indistinguishability from fake sites* are important upto (thtough) essential for internet users. I don't care if a home NAS uses a DV-cert, but banks, goverments (in particular those that do *not* use a specific domain name ending, such as .gov), insurances, websites showing and/or receiving medical/patient data etc. - any server related to PII or needs to otherwise prove their identity.</p><p>🟡 MORE INFORMATION<br>🔸 Let's Encrypt certificates mis-issuances & ocsp ending: <a href="https://infosec.exchange/@ErikvanStraten/112914047006977222" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">infosec.exchange/@ErikvanStrat</span><span class="invisible">en/112914047006977222</span></a></p><p>🔸 Untrustworthy HSTS and lack of "https only" in many browsers: <a href="https://infosec.exchange/@ErikvanStraten/113045241408077702" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">infosec.exchange/@ErikvanStrat</span><span class="invisible">en/113045241408077702</span></a></p><p>🔸 Why awareness trainings fail (in Dutch): <a href="https://infosec.exchange/@ErikvanStraten/113045136092456532" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">infosec.exchange/@ErikvanStrat</span><span class="invisible">en/113045136092456532</span></a></p><p>🔸 Why the physical location of an offline service provider (like a bank office or a town hall) is a hugely underestimated authentication factor (in Dutch): <a href="https://security.nl/posting/855557" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">security.nl/posting/855557</span><span class="invisible"></span></a></p><p>🔸 Why Google lied when they killed EV certs, and why it's insane to introduce digital identity wallets (eID's) for strong online authentication of people on the current, highly crminalized, internet, with more anonymous servers every day (in Dutch): <a href="https://infosec.exchange/@ErikvanStraten/113031344934186250" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">infosec.exchange/@ErikvanStrat</span><span class="invisible">en/113031344934186250</span></a></p><p>🔸 How Google became evil by facilitating cybercrime, renting them hosting services for domain names such as NNoutlook.com, NNNNoutlook.com and ecbeuropa[.]eu, even providing them with server certificates for free: <a href="https://www.virustotal.com/gui/ip-address/35.241.18.84/relations" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="ellipsis">virustotal.com/gui/ip-address/</span><span class="invisible">35.241.18.84/relations</span></a></p><p>Internet reliability needs to be restored, and further improved upon, ASAP.</p><p><a href="https://infosec.exchange/tags/RPKI" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RPKI</span></a> <a href="https://infosec.exchange/tags/PKI" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>PKI</span></a> <a href="https://infosec.exchange/tags/WebPKI" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>WebPKI</span></a> <a href="https://infosec.exchange/tags/InfoSec" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>InfoSec</span></a> <a href="https://infosec.exchange/tags/BGP" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>BGP</span></a> <a href="https://infosec.exchange/tags/BGPHijack" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>BGPHijack</span></a> <a href="https://infosec.exchange/tags/DNS" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>DNS</span></a> <a href="https://infosec.exchange/tags/DNSHijack" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>DNSHijack</span></a> <a href="https://infosec.exchange/tags/Websites" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Websites</span></a> <a href="https://infosec.exchange/tags/Real" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Real</span></a> <a href="https://infosec.exchange/tags/Fake" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Fake</span></a> <a href="https://infosec.exchange/tags/Authentic" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Authentic</span></a> <a href="https://infosec.exchange/tags/Authenticity" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Authenticity</span></a> <a href="https://infosec.exchange/tags/Impostors" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Impostors</span></a> <a href="https://infosec.exchange/tags/CABForum" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>CABForum</span></a> <a href="https://infosec.exchange/tags/Commercialization" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Commercialization</span></a> <a href="https://infosec.exchange/tags/Independant" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Independant</span></a> <a href="https://infosec.exchange/tags/UserRepresentatives" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>UserRepresentatives</span></a> <a href="https://infosec.exchange/tags/Certificates" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Certificates</span></a> <a href="https://infosec.exchange/tags/DV" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>DV</span></a> <a href="https://infosec.exchange/tags/OV" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>OV</span></a> <a href="https://infosec.exchange/tags/EV" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>EV</span></a> <a href="https://infosec.exchange/tags/QWAC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>QWAC</span></a> <a href="https://infosec.exchange/tags/EDIW" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>EDIW</span></a> <a href="https://infosec.exchange/tags/EUDIW" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>EUDIW</span></a> <a href="https://infosec.exchange/tags/eID" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>eID</span></a> <a href="https://infosec.exchange/tags/eIDAS" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>eIDAS</span></a> <a href="https://infosec.exchange/tags/WebAuthn" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>WebAuthn</span></a> <a href="https://infosec.exchange/tags/FIDO2" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>FIDO2</span></a> <a href="https://infosec.exchange/tags/Yubikey" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Yubikey</span></a> <a href="https://infosec.exchange/tags/Yubico" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Yubico</span></a> <a href="https://infosec.exchange/tags/Titan" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Titan</span></a> <a href="https://infosec.exchange/tags/GoogleTitan" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>GoogleTitan</span></a> <a href="https://infosec.exchange/tags/Feitian" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Feitian</span></a></p>
John Kristoff<p>Weekend Reads</p><p>* Where DNSSEC went wrong <a href="https://blog.apnic.net/2024/07/05/where-did-dnssec-go-wrong/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">blog.apnic.net/2024/07/05/wher</span><span class="invisible">e-did-dnssec-go-wrong/</span></a><br>* Rogers 2022 outage report <a href="https://crtc.gc.ca/eng/publications/reports/xona2024.htm" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">crtc.gc.ca/eng/publications/re</span><span class="invisible">ports/xona2024.htm</span></a><br>* Rise of packet rate attacks <a href="https://blog.ovhcloud.com/the-rise-of-packet-rate-attacks-when-core-routers-turn-evil/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">blog.ovhcloud.com/the-rise-of-</span><span class="invisible">packet-rate-attacks-when-core-routers-turn-evil/</span></a><br>* CAA/CT/DANE measurement study <a href="https://arxiv.org/abs/2407.02287" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">arxiv.org/abs/2407.02287</span><span class="invisible"></span></a><br>* Domain name market 2023 report <a href="https://www.afnic.fr/wp-media/uploads/2024/07/study-afnic-the-global-domain-name-market-in-2023.pdf" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="ellipsis">afnic.fr/wp-media/uploads/2024</span><span class="invisible">/07/study-afnic-the-global-domain-name-market-in-2023.pdf</span></a></p><p><a href="https://infosec.exchange/tags/DNSSEC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>DNSSEC</span></a> <a href="https://infosec.exchange/tags/Rogers" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Rogers</span></a> <a href="https://infosec.exchange/tags/DDoS" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>DDoS</span></a> <a href="https://infosec.exchange/tags/PKI" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>PKI</span></a> <a href="https://infosec.exchange/tags/DNS" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>DNS</span></a></p>
Daniel Carkner🥀<p>For <a href="https://historians.social/tags/Indonesians" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Indonesians</span></a>, by the way my former thesis supervisor John Roosa's 2022 book Buried Histories: The Anticommunist Massacres of 1965-1966 in Indonesia has just been released in Indonesian translation by Marjin Kiri, translated by Hendarto Setiadi: <br><a href="https://marjinkiri.com/product/riwayat/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">marjinkiri.com/product/riwayat</span><span class="invisible">/</span></a></p><p>(originally published in English by University of Wisconsin Press: <a href="https://uwpress.wisc.edu/books/5717.htm" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">uwpress.wisc.edu/books/5717.ht</span><span class="invisible">m</span></a> )<br><a href="https://historians.social/tags/HistoryBooks" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>HistoryBooks</span></a> <a href="https://historians.social/tags/Sejarah" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Sejarah</span></a> <a href="https://historians.social/tags/IndonesianHistory" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>IndonesianHistory</span></a> <a href="https://historians.social/tags/NewOrder" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>NewOrder</span></a> <a href="https://historians.social/tags/OrdeBaru" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>OrdeBaru</span></a> <a href="https://historians.social/tags/PKI" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>PKI</span></a> <a href="https://historians.social/tags/CommunistHistory" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>CommunistHistory</span></a> <a href="https://historians.social/tags/HumanRights" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>HumanRights</span></a></p>
ExploreLive feeds
Mastodon is the best way to keep up with what's happening.
Follow anyone across the fediverse and see it all in chronological order. No algorithms, ads, or clickbait in sight.
Create accountLoginDrag & drop to upload