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.
dropboot 7 hours ago [-]
[dead]
nottorp 1 days ago [-]
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.
makr17 22 hours ago [-]
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.
BuildTheRobots 7 hours ago [-]
The linux kernel traffic control (tc) can do network emulation with qdisc to simulate bad network connections. Add latency, jitter, bandwidth limits, and settable levels of traffic loss to your network interface.
If you're testing hardware or vm's that don't support it or don't have root, you can stick your linux box transparently in the middle by bridging two interfaces, and apply your traffic mangling there. Testing wifi? Use a decent WiFi AP connected to one of these bridges and mangle your traffic once it hits the wire/after it stops being RF.
At a previous job I had a linux box set up with multiple bridges (each set with a different "testing profile" on different vlans) and trunked to a physical switch. Made it very easy for people in the office to attach physical devices through known bad network links by either using pairs of physical switchports or just dumping VMs/SSIDs into the right VLAN so they could test different things (simultaneously) without needing to reconfigure the actual mangling.
Worth noting that tc applies to egress traffic, so if you want a uniformly bad line it needs applying to both sides - but it does mean you can simulate unidirectional link problems too.
Groxx 1 days ago [-]
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 1 days ago [-]
I think he figured it out eventually, used some software tool. But I heard the complaining first.
gnopgnip 24 hours ago [-]
You can simulate bad wifi with the throttling option on the network tab of your browser's developer tools
Slow networks != Bad networks. Bad networks could be slow, or drop random packets, or corrupt packets, or have jitter, etc
nottorp 12 hours ago [-]
> You can simulate bad wifi with the throttling option on the network tab of your browser's developer tools
Oh? How does that help for native applications?
> You can always also simulate bad WiFi by walking away from your access point until you have bad wifi
That's unfortunately very inconvenient when you work on an embeddeded device prototype that consists of several boards interconnected by hair thin wires :)
Maybe I should make some friends across the street to the point they give me access to their APs...
SOLAR_FIELDS 21 hours ago [-]
You can always also simulate bad WiFi by walking away from your access point until you have bad wifi
contraposit 13 hours ago [-]
I remember Facebook while developing it's mobile app in the early days of smartphones did similar tests.
I miss https://highscalabilty.com ;( The “Stuff The Internet Says On Scalability” posts were always worth a read.
a_t48 23 hours ago [-]
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 23 hours ago [-]
Putting a StarLink dish so it has a tree branch in the way is a good way to get packet loss.
sublinear 17 hours ago [-]
Why not just loosely wrap the antenna or entire box in foil or move it to the basement/garage/roof?
If you're going for realism, bad wifi is a radio signal problem.
nottorp 2 minutes ago [-]
Oh I'll write that down! Looks like it can at least do something bad to the signal.
astrange 15 hours ago [-]
Not necessarily, it could also be on-band or off-bad interference, or bugs in the AP, or too many clients on the network.
NooneAtAll3 20 hours ago [-]
maybe look into jammers?
bigfatkitten 15 hours ago [-]
Not an option if you want to act lawfully.
24 hours ago [-]
ipython 1 days ago [-]
Interesting. Chrome (146, macOS) shows no error messages on the revoked cert pages, but Firefox does (also macOS).
omoikane 22 hours ago [-]
Chrome doesn't want to perform online revocation checks according to this page:
Yeah, Chrome only partly supports revocation (Not sure exactly the criteria, but our test sites don't match it).
moralestapia 1 days ago [-]
Same with Brave, so it is a Chromium thing.
JackSlateur 1 hours ago [-]
Notice how your browser happily accepts the expired certificates :)
bullen 1 days ago [-]
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?
horsawlarway 1 days ago [-]
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.
NooneAtAll3 20 hours ago [-]
> default trusted store of root CAs (which lives in the browser or OS, depending).
speaking of that, is there any way to verify that stored certificates are actually valid?
bullen 24 hours ago [-]
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...
xandrius 1 days ago [-]
Did you self-ban?
bullen 1 days ago [-]
XD Nope, more like self destruct! ;)
lifis 1 days ago [-]
Vanadium, Chrome and Firefox (all for Android) all accept all the revoked certificates... But revoked.badssl.com is considered revoked
RunningDroid 1 days ago [-]
> 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
sureglymop 20 hours ago [-]
I don't think those certs are revoked yet.
Rendered at 20:16:21 GMT+0000 (Coordinated Universal Time) with Vercel.
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.
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.
If you're testing hardware or vm's that don't support it or don't have root, you can stick your linux box transparently in the middle by bridging two interfaces, and apply your traffic mangling there. Testing wifi? Use a decent WiFi AP connected to one of these bridges and mangle your traffic once it hits the wire/after it stops being RF.
At a previous job I had a linux box set up with multiple bridges (each set with a different "testing profile" on different vlans) and trunked to a physical switch. Made it very easy for people in the office to attach physical devices through known bad network links by either using pairs of physical switchports or just dumping VMs/SSIDs into the right VLAN so they could test different things (simultaneously) without needing to reconfigure the actual mangling.
Worth noting that tc applies to egress traffic, so if you want a uniformly bad line it needs applying to both sides - but it does mean you can simulate unidirectional link problems too.
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.
Oh? How does that help for native applications?
> You can always also simulate bad WiFi by walking away from your access point until you have bad wifi
That's unfortunately very inconvenient when you work on an embeddeded device prototype that consists of several boards interconnected by hair thin wires :)
Maybe I should make some friends across the street to the point they give me access to their APs...
https://highscalability.com/how-facebook-makes-mobile-work-a...
If you're going for realism, bad wifi is a radio signal problem.
https://chromium.googlesource.com/chromium/src/+/HEAD/docs/s...
found via: https://issues.chromium.org/issues/471199592#comment3
Just "add your own crypto" on top, which is the ONLY thing a sane person would do.
3... 2... 1... banned?
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.
speaking of that, is there any way to verify that stored certificates are actually valid?
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...
Firefox Beta (150.0b7) is accepting all of the revoked certs on my device