[HN Gopher] The difficulty of making sure your website is broken
___________________________________________________________________
The difficulty of making sure your website is broken
Author : mcpherrinm
Score : 50 points
Date : 2026-04-10 16:45 UTC (6 hours ago)
(HTM) web link (letsencrypt.org)
(TXT) w3m dump (letsencrypt.org)
| paulirish wrote:
| https://badssl.com/ also offers several test subdomains in the
| same vein.
| NicolaiS wrote:
| badssl.com is an amazing tool especially for testing "TLS
| intercepting" boxes. I've seen more than one fortune 500
| company that re-sign certain broken certs with their own CA,
| allowing silent MITM.
| bullen wrote:
| Meanwhile HTTP keeps working just fine and is decentralized.
|
| Just "add your own crypto" on top, which is the ONLY thing a sane
| person would do.
|
| 3... 2... 1... banned?
| xandrius wrote:
| Did you self-ban?
| bullen wrote:
| XD Nope, more like self destruct! ;)
| horsawlarway wrote:
| to actually tackle this (on the off chance you're serious, I'm
| assuming not) - this doesn't work.
|
| The payload that implements your crypto cannot be delivered
| over http, because any intermediate party can just modify your
| implementation and trivially compromise it.
|
| If you don't trust TLS, you have to pre-share _something_. In
| the case of TLS and modern browser security, the "pre-shared"
| part is the crypto implementation running in the browser, and
| the default trusted store of root CAs (which lives in the
| browser or OS, depending).
|
| If you want to avoid trusting that, you've got to distribute
| your algorithm through an alternative channel you do trust.
| bullen wrote:
| You are right presharing is a requirement, unless you hash
| the keys used to encrypt the secret into the secret itself,
| but that can only be prooven later on a channel where the
| same MITM is not present.
|
| Work in progress, that said presharing solve(d/s) enough for
| the world to dump DNS and HTTPS in a bin and light it on fire
| now, because nobody has the power to implement all the MITM
| needed if everyone "makes their own crypto" on top of
| allready shared secrets!
|
| Circular arguments, wishful thinking and all...
| ipython wrote:
| Interesting. Chrome (146, macOS) shows no error messages on the
| revoked cert pages, but Firefox does (also macOS).
| mcpherrinm wrote:
| Yeah, Chrome only partly supports revocation (Not sure exactly
| the criteria, but our test sites don't match it).
| moralestapia wrote:
| Same with Brave, so it is a Chromium thing.
| omoikane wrote:
| Chrome doesn't want to perform online revocation checks
| according to this page:
|
| https://chromium.googlesource.com/chromium/src/+/HEAD/docs/s...
|
| found via:
| https://issues.chromium.org/issues/471199592#comment3
| lifis wrote:
| Vanadium, Chrome and Firefox (all for Android) all accept all the
| revoked certificates... But revoked.badssl.com is considered
| revoked
| RunningDroid wrote:
| > Vanadium, Chrome and Firefox (all for Android) all accept all
| the revoked certificates... But revoked.badssl.com is
| considered revoked
|
| Firefox Beta (150.0b7) is accepting all of the revoked certs on
| my device
| nottorp wrote:
| In the same direction, I once wanted to test an embedded device
| on crap wifi.
|
| So I just ordered the cheapest AP I could find.
|
| Except the damn device worked perfectly. Slow but rock solid.
|
| One of our testers at $CURRENT_JOB also has trouble simulating a
| crap network, because our network is good.
| Groxx wrote:
| Some proxies, iptables extensions, and OS-provided tools exist
| - there's almost certainly a combo that would work for them.
| What platform?
|
| Unless it's for a custom physical device, then uh. idk.
| Probably something, proxying through another computer that is
| hosting a separate wifi network? But likely a lot harder.
| nottorp wrote:
| I think he figured it out eventually, used some software
| tool. But I heard the complaining first.
| gnopgnip wrote:
| You can simulate bad wifi with the throttling option on the
| network tab of your browser's developer tools
| dieulot wrote:
| That's an unreliable way of simulating an unreliable network,
| as overviewed in
| https://calendar.perfplanet.com/2016/testing-with-
| realistic-...
| patmorgan23 wrote:
| Slow networks != Bad networks. Bad networks could be slow, or
| drop random packets, or corrupt packets, or have jitter, etc
| a_t48 wrote:
| I'm building a product that helps out Docker usage in poorly
| networked environments (ie, robotics deployments). I've just
| been moving the Jetson around the house.
| callistocodes wrote:
| Putting a StarLink dish so it has a tree branch in the way is a
| good way to get packet loss.
| makr17 wrote:
| Coming up on 20 years ago I was building a system that was
| going to be deployed at various locations throughout a very
| large country. All locations had internet access; but the
| throughput, latency, and quality (e.g. packet drops) were all
| over the map.
|
| For testing we ended up building a small linux box to proxy for
| the test environment in the office. We could throttle the
| throughput to any arbitrary level, introduce latency, and
| introduce packet drops. It's amazing how poorly a frontend will
| work when you throttle the network to 128kbps, and introduce a
| small percentage of dropped packets. But once you get the
| system to work (for some definition of "work") under those
| conditions you feel pretty good about deploying it.
___________________________________________________________________
(page generated 2026-04-10 23:00 UTC)