If they or their company use email "security" software that "scans" all links it's not necessarily the users fault / they don't in fact click. The mail is auto-confirmed the second it hits the inbox.
We've had to change our registration confirmation mails too recently to not confirm on GET only, but with another form - in hindsight it was stupid before but many services do that.
Security software fetching links will not trigger this behavior. It needs to be done in the context of the actual ChatGPT user so that a JavaScript payload can run.
If merely GET on the link was sufficient to trigger the behaviors, the adversary generating the link would just GET it themselves.
Yes, if it requires the user session (xss related), like the article, there is no problem.
I was replying more generally about the "don't click links" advice and cases of server generated confirmation-token links (not saying this was the case at OpenAI)
> We've had to change our registration confirmation mails too recently to not confirm on GET only, but with another form - in hindsight it was stupid before but many services do that.
Last time I gave that a try (without LLM assistance though) it was really hard as games DirectX calls cannot simply be glued to WebGL so performance was bad.
They don't offload TLS to the kernel, do they? Most apps do it in userspace linked against openssl afaik.
Do you patch that lib? If ebpf "just" operates at network/packet level, I don't see how it can do more than Mitmproxy in regard to avoid DH-PFS/Pinning
It’s done via uprobes which allows ebpf to attach to users processes or libraries, basically like ld_preload but built into the kernel. First link that explains it https://blog.quarkslab.com/defeating-ebpf-uprobe-monitoring.... but there are many more links about it and it is a pretty useful tool for debugging in prod environments. (Also first link: https://blog.px.dev/ebpf-function-tracing/) this also the intended use case.
px.dev is btw a cncf project which also helps for ebpf debugging in k8s (comes from new relic)
Exactly this :)
You can either attach the uprobes directly to the systems OpenSSL to capture anything using it (curl etc), though most of these LLM clients and similar uses their own static compiled BoringSSL, but its very straight forward to find, it does require some knowledge to determine the right place where you attach the uprobe, but after that it can easily be scripted to automatically find the right offsets (as these are usually stripped binaries)
eBPF started as a network tool, but (according to the creators of it) targeting the network was just a ploy to get a foot in the door so they could start expanding it to other things. They didn’t think the idea would be accepted if they tried to do it all at once. So now it works on many parts of the system, not just the network.
It does not even require the PoW thing Anubis does. I've setup a simple logic that just:
Checks for existence of a specific static cookie, if it does not exist, output a small page that sets the cookie via JS and reloads. Sadly this kills Noscript, but it would be possible to add a form in <noscript> that when submitted sets the cookie serverside.
Is this trivial to bypass? Yes. It still keeps out 95% of unwanted bots.
Reality is most do not target you specifically they just want to mass-scrape with low effort. Running headless browsers is way more expensive for their op
I've extended this with a FCRDNS checked exclusion for Googlebot.
Another quite effective measure I figured out was checking the existence of Sec-Fetch-Dest header if the User-Agent claims to be a modern browser. If you don't want to close down too much.
Also, I only apply these rules to routes that are not cheap and cached.
That's not far from what anubis does for clients that are determined to have light souls. It doesn't always send a PoW challenge.
For a webapp that sets a long-lived cookie, that cookie could be used to bypass anubis completely, or lower the weight in anubis so that it doesn't send its pow challenge unless there are major red flags. If bots start to abuse that exception, it can be removed.
I understand that most people don't use it and indeed rely on tofu, but the statement is not absolutely correct.
ssh server keys can be authenticated using (the DNSSEC "CA" system and) SSHFP, and it's possible to setup a signing CA for the host key (similar to ssh certificates, however not applicable for foreign servers).
And of course, the fingerprint could be advertised out of band e.g. on the homepage with tls
sshfp is not PKI. It's an option and it is off by default in ssh(1). In practice no one actually deploys it, exe.dev, terminal.shop, jobs.{whoever.com}, etc. I've yet to see an in the wild deployment. The aforementioned sites let you perform electronic payment transactions over ssh without it, which is probably a PCI violation tbh, but auditors aren't good enough.
These commits [1] are related to the issue. I am not too familiar with the code, but it appears nginx manages/closes streams in a pool at times the attacker cannot control, and during short windows, it is vulnerable.
I did that for a while because of compatibility issues with a newer laptop, it works but generally if there is no reason it's way easier to stay with the provided packages. Compiling weekly due to security patches becomes annoying over time for no real gain other than the version number
mysql/maria also lets you turn off/down the isolation level for queries if you know the guarantees aren't needed, to speed things up. I think postgres does not have that option.
I've been receiving loads of spam from google MX servers lately until blocking all mails with X-Google-Group-Id headers. I don't know how it's possible, the contents were 100% spammer controlled, no Google template
We've had to change our registration confirmation mails too recently to not confirm on GET only, but with another form - in hindsight it was stupid before but many services do that.
reply