I run a rust webserver on a €4 VPS from hetzner that serves 300M (million) requests a day. Way cheaper than doing that on _any_ "serverless" request-based platform, I think.
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.
Sorry if its a bit unclear; the first part was HKG -> LHR when I kinda discovered it (9th May), and then the HTTPS proxy test was my flight back LHR -> HKG (18th May)
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.
There may not be any "free messaging" or similar offers is my guess. In fact using ECH it is already possible to spoof the SNI but make a real TLS handshake to the underlying domain; you can try it on my test website[0] with wireshark open on the side (if your browser supports ECH)
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).
From what I can figure out, Vercel charges "$0.60 per million invocations" [1], which would cost me $180 per day.
[0] https://news.ycombinator.com/item?id=47611454 [1] https://vercel.com/docs/functions/usage-and-pricing#invocati...