Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The difficulty of making sure your website is broken

letsencrypt.org

Post reply on HN
Print view View original

11–20 of 42 posts

Re: The difficulty of making sure your website is broken

#11

Post by horsawlarway »

bullen wrote: post #3

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?

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.

Re: The difficulty of making sure your website is broken

#12

Post by nottorp »

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.

Re: The difficulty of making sure your website is broken

#13

Post by Groxx »

nottorp wrote: post #12

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.

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.

Re: The difficulty of making sure your website is broken

#14

Post by nottorp »

Groxx wrote: post #13
nottorp wrote: post #12

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.

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.

I think he figured it out eventually, used some software tool. But I heard the complaining first.

Re: The difficulty of making sure your website is broken

#15

Post by bullen »

horsawlarway wrote: post #11
bullen wrote: post #3

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?

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 implementatio…

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...

Re: The difficulty of making sure your website is broken

#16

Post by [deleted] »

nottorp wrote: post #12

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.

[deleted]

Re: The difficulty of making sure your website is broken

#17

Post by gnopgnip »

nottorp wrote: post #12

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.

You can simulate bad wifi with the throttling option on the network tab of your browser's developer tools

Re: The difficulty of making sure your website is broken

#18

Post by NicolaiS »

paulirish wrote: post #2

https://badssl.com/ also offers several test subdomains in the same vein.

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.

Re: The difficulty of making sure your website is broken

#19

Post by dieulot »

gnopgnip wrote: post #17
nottorp wrote: post #12

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.

You can simulate bad wifi with the throttling option on the network tab of your browser's developer tools

That’s an unreliable way of simulating an unreliable network, as overviewed in https://calendar.perfplanet.com/2016/testing-with-realistic-...

Re: The difficulty of making sure your website is broken

#20

Post by a_t48 »

nottorp wrote: post #12

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.

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.
Post reply on HN