HN user

arch-choot

77 karma

Contact: poiasd@saxrag.com

Posts1
Comments29
View on HN

Could you clarify a bit more what you mean by "Domain Fronting is why ECH exists"?

Because even with ECH, you (TLS client) can set any public_name you want, but the innerSNI can be something else.

Or is that what you mean; since the providers can "ignore" the OuterSNI, they can rely on the InnerSNI to still route traffic?

An example for the hub:

``` echo -e "GET / HTTP/1.1\r\nHost: www.pornhub.com\r\nConnection: close\r\n\r\n" | openssl s_client -connect 66.254.114.41:443 -quiet ```

This works for most ISPs in India, but if you set the SNI it'll get a TCP reset

If i'm not mistaken its because IPs are actually much easier to rotate than domains.

E.g. all the users will remember `example.com` , underlying it doesn't matter what IP it resolves to. If the IP gets "burned" , then the providers can rotate to a new IP (if their provider allows).

Vs. telling your users to use a new domain `example.org` , fake websites etc.

Also sensible ISPs usually don't block IPs since for services behind a CDN it could lead to other websites being blocked, though of course sometimes this is ignored. See also: https://blog.cloudflare.com/consequences-of-ip-blocking/

\> This makes the spec entirely meaningless for small servers and basically requires shifting hosting to shared hosts/massive CDNs to provide any protection against SNI snooping.

Actually you can setup ECH on your server, and configure the public_name to be something like `cloudflare-ech.com` , so clients would indeed use that in the OuterSNI, connect to you, without you needing to use CF. And middleboxes might think they are indeed connecting to CF (though CF publishes their IP ranges so this could be checked elsewhere).

Should've added this was back in like 2018 or so. Setting up DoH was harder than enabling SNI, and from my testing back then they were hard filtering on SNI (e.g. I used OpenSSL CLI to set the SNI to `pornhub.com` and connect to "known good" IPs, it'd still get reset).

Funnily enough, not setting the SNI and connecting the the origin IP, and then requesting the page worked fine.

Glad that it's published, I'd been following it since ESNI draft days. Was pretty useful back when I was in India since Jio randomly blocked websites, and cloudflare adopted the ESNI draft on its servers as did Firefox client side which made their SNI based blocking easy to bypass.

There was a period where I think both disabled ESNI support as work was made on ECH, which now is pretty far along. I was even able to setup a forked nginx w/ ECH support to build a client(browser) tester[0].

Hopefully now ECH can get more mainstream in HTTPS servers allowing for some fun configs.

A pretty interesting feature of ECH is that the server does not need to validate the public name (it MAY) , so clients can use public_name's that middleboxes (read: censors) approve to connect to other websites. I'm trying to get this added to the RustTLS client[1], now might be a good time to pick that back up.

[0] https://rfc9849.mywaifu.best:3443/ [1] https://github.com/rustls/rustls/issues/2741

Yea, I run wireguard & OpenVPN on port53 (different VPS) just in case it works. Unfortunately my experience with the "pay to use" WiFi so far has been they validate that port 53 is valid DNS traffic, and often don't allow arbitrary resolvers (e.g. `dig example.com @1.1.1.1` will not work)

I think that's essentially what my HTTPS proxy does; except rather than actually being over WhatsApp (i.e. using WA messages or w/ever), the SNI tricks their authorization into thinking I'm using WA, while I am connecting to my proxy.

Yep; on my way to LHR I was intrigued by their "free messaging" and wanted to poke around, with the SNI hypothesis I did the actual HTTPS proxy setup on a VPS while in the UK, so I could actually try and proxy arbitrary browser traffic on the way back

Interesting! I'd done something similar in Typescript to learn more about BT, and then redid it in rust to learn rust (https://github.com/ckcr4lyf/kiryuu).

However I decided to just use redis as the DB. It sounds like your entire DB is in memory? Any interesting design decisions you made and/or problems faced in doing so?

(My redis solution isn't great since it does not randomize peers in subsequent announces afaik)

Pretty cool! I've been living in HK for 7 years now and not moved past the basic few phrases - mostly because English gets you so far there's no "forcing factor" (vs. in Tokyo you'd be kinda forced to learn Japanese).

One suggestion, though it would be quite high effort: have you considered also adding a button or something for the pronunciation? I think the hardest part for learners is knowing their reading of the jyutping sounds correct (especially with all the tones).

imo BT is not at fault here (if that's what your were implying) - It is a conscious choice by Apple chooses to always listen for these beacons and prompt the user with a pop-up (even if they turn it "off" via the pull down settings).

A "solution" is just to only view these devices when a user explicitly goes into some kind of "pairing mode" (but needs more clicks from a user).

I think it just leads to a false sense of security for most "normie" users. E.g. Snapchat, people think it must give a screenshot notification or whatever, so it is "safe" for nudes.

Well it is quite trivial to save the photos, either by network interception or patching the app etc. , which ordinary users may not even consider.

Not quite related, but I think "deleting messages" falls into a similar problem. It makes end users think they are "safe" or whatever, but the reality is that if a message was delivered to the other parties phone, they could easily have the original text despite any deletions, e.g. a cached notification or similar.