<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: bsysop</title><link>https://news.ycombinator.com/user?id=bsysop</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Sat, 18 Apr 2026 07:20:25 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=bsysop" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by bsysop in "Mitigating a DDoS on Mastodon"]]></title><description><![CDATA[
<p>This is huge. There are a ton of mis-configured Apache and nginx reverse proxies out there that expose the primary domain name of the site being served. You can quickly test this for yourself by running "curl -vk <a href="https://your.ip.address"" rel="nofollow">https://your.ip.address"</a> and see what pops up for the CN field or Location header.<p>Even worse is the pattern of requesting LetsEncrypt certificates for multiple domains on one certificate. Now all of a sudden you're leaking development server hostnames, peeling off the white label of multi-tenant, and making things easier for automated scanners.<p>I get it that security by hostname obscurity is a poor practice on its own, but there's also something to be said for cutting down a large amount of malicious traffic with some common best practices.</p>
]]></description><pubDate>Fri, 06 Dec 2019 15:22:05 +0000</pubDate><link>https://news.ycombinator.com/item?id=21722518</link><dc:creator>bsysop</dc:creator><comments>https://news.ycombinator.com/item?id=21722518</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=21722518</guid></item><item><title><![CDATA[New comment by bsysop in "Cname cloaking, a disguise of third-party trackers"]]></title><description><![CDATA[
<p>Do you think ad companies will really trust reverse-proxied ad traffic? Seems like a tremendous opportunity for fraud. Right now with user agents hitting ad servers directly, there's much less opportunity for content publishers to fake impressions and clicks.</p>
]]></description><pubDate>Sat, 23 Nov 2019 21:04:23 +0000</pubDate><link>https://news.ycombinator.com/item?id=21616537</link><dc:creator>bsysop</dc:creator><comments>https://news.ycombinator.com/item?id=21616537</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=21616537</guid></item><item><title><![CDATA[New comment by bsysop in "The Maturing of QUIC"]]></title><description><![CDATA[
<p>What developer out there reads "The spin bit is an OPTIONAL feature of QUIC", then sees "Implementations MUST allow administrators of clients and servers to disable the spin bit either globally or on a per-connection basis" and thinks "Yes, this is definitely something I will implement and test out all the edge cases." Especially stuff like "The random selection process SHOULD be designed such that on average the spin bit is disabled for at least one eighth of network paths."<p>This whole thing is going to be a congestion control arms race. With TCP out the window this is going to be an epic battle of network operators trying to heuristically classify important vs. bulk traffic any way they can, content servers trying every trick in the book to get their traffic prioritized ahead of competitors, and savvy users running tweaked router firmware to jump the Fair Share queue.</p>
]]></description><pubDate>Mon, 11 Nov 2019 20:58:34 +0000</pubDate><link>https://news.ycombinator.com/item?id=21508847</link><dc:creator>bsysop</dc:creator><comments>https://news.ycombinator.com/item?id=21508847</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=21508847</guid></item></channel></rss>