Ya’ll read too many conspiracy theories. What makes you think other countries were interested in recruiting him, specifically? I want to see the logic behind this assumption.
>Ya’ll read too many conspiracy theories. What makes you think other countries were interested in recruiting him, specifically? I want to see the logic behind this assumption.
You don't understand why a country without nuclear weapons would try to get a scientist to help them make them?
Oh I understand. I’m asking why him, specifically?
Countries that have nuclear ambitions but lack the capability have more than enough scientists of their own that could do it given the permission. It’s pretty available science which is why we put sanctions on it and prevent people from enriching uranium like that.
There are already other articles claiming he was shot because he's Jewish and has supported Israel. Seems like the cops haven't arrested anybody yet, so we don't really know anything.
He was working on fusion technology, so you could just as well speculate it was fossil fuel interests involved, but that also seems purely speculative.
First thing that came to mind is that he might have been secretly working for Israel's nuclear program but this is all very speculative. It does feel plausible though given that Israel has already assassinated plenty of Iranian nuclear scientists; so there is some precedent for it.
There are lots of different scenarios you can conjure up. Another could be that Israel assassinated him after he refused to support their nuclear program OR to silence him.
> As part of our ongoing work to protect customers using React against a critical vulnerability, CVE-2025-55182, we started rolling out an increase to our buffer size to 1MB, the default limit allowed by Next.js applications.
Why would increasing the buffer size help with that security vulnerability? Is it just a performance optimization?
I think the buffer size is the limit on what they check for malicious data, so the old 128k would mean it would be trivial to circumvent by just having 128k ok data and then put the exploit after.
If the request data is larger than the limit it doesn’t get processed by the Cloudflare system. By increasing buffer size they process (and therefore protect) more requests.
Thats a fair point, there are some protections in place for abuse already. I will have a look at what ngrok does for browser warnings. Thanks a lot for the suggestions.
Be aware of threat actors, too: you're giving them an easy data exfil route without the hassle and risk of them having to set up their own infrastructure.
Back in the day you could have stood up something like this and worried about abuse later. Unfortunately, now, a decent proportion early users of services like this do tend to be those looking to misuse it.
I'm not who you asked, but essentially, when you write malware that infects someone's PC, that in itself doesn't really help you much. You usually want to get out passwords and other data that you might have stolen.
This is where an exfil (exfiltration) route is needed. You could just send the data to a server you own, but you have to make sure that there are fallbacks once that one gets taken down. You also need to ensure that your exfiltration won't be noticed by a firewall and blocked.
Hosting a server locally, easily, on the infected PC, that can expose data under a specific address is (to my understanding) the holy grail of exfiltration; you just connect to it and it gives you the data, instead of having to worry much about hosting your own infrastructure.
That's actually a fair defence against this kind of abuse. If the attacker has to get some information (the tunnel ID) out of the victim's machine before they can abuse this service, then it is less useful to them because getting the tunnel ID out is about as hard as just getting the actual data out.
However, if "No signup required for random subdomains" implies that stable subdomains can be obtained with a signup, then the bad guys are just going to sign up.
I've seen lots of weird tricks malware authors use, people are creative. My favorite is that they'd load up a text file with a modified base64 table from Dropbox which points to the URL to exfiltrate to. When you report it to Dropbox, they typically ignore the report because it just seems like random nonsense instead of being actually malicious.
> Hosting a server locally, easily, on the infected PC, that can expose data under a specific address is (to my understanding) the holy grail of exfiltration; you just connect to it and it gives you the data, instead of having to worry much about hosting your own infrastructure.
A permanent SSH connection is not exactly discreet, though...
HEIF is just the usual container for AVIF encoded data, similar to how AV1 encoded data might commonly be in an MP4 or MKV container. HEIF might easily get conflated with HEIC, which is Apple's implementation of HEIF specifically for HEVC encoded data. Too many damn "HE"s, if you ask me.
If you run "strings" you should see "av01Image" pretty early on in the HEIF header, which is what signals it's really an AVIF file. Tools like "file" may possibly not be updated to look for that yet, so could just report the container alone.
Because I didn't feel like parsing the HEIF to check it's actually AVIF. I'm pretty sure browsers aren't that bothered about the file extension or MIME type for images.
Huh, my image viewer claimed it's HEIC specifically. My camera also seems to conflate HEIC and HEIF in the settings. It provides HEIF as a format option, when I guess it should be specifying which codec is actually being used. I had no idea HEIF isn't tied to just HEIC though.
It likely overrides DNS resolution to CDN/POPs in countries which don't require age checking, or routes the traffic through TCP proxies so your traffic appears to come from a different country without these laws.
This will increase the latency of all traffic to that site though.
Sure they can. When your browser resolves a host, they replace the actual IP with the IP of a proxy that is configured to forward traffic according to the Host HTTP header.
- You ask Foo DNS Provider for the IP address of pornhub.com
- Foo DNS Provider responds with the real IP address
- You connect to that address, send a TLS ClientHello containing a Server Name Indication extension of "pornhub.com"
What could happen:
- You ask Foo DNS Provider for the IP address of pornhub.com
- Foo DNS Provider responds with one of their own IP addresses
- You connect to that address, send a TLS ClientHello containing a Server Name Indication extension of "pornhub.com"
- Foo DNS Provider now knows that you intend to connect there, so it connects there for you and relays your ClientHello to it
- Foo DNS Provider then just acts as a dumb relay, passing everything back and forth with no modifications
- The certificate verifies fine because the traffic was not modified and it was presented by the party who controls the corresponding private key
- The website thinks you are connecting from Foo DNS Provider, not your real address
The only thing that would break this is ECH (Encrypted ClientHello), currently supported only by CloudFlare and Google Chrome (and its derivatives) as far as I know. This security feature is provisioned with ... DNS records! So Foo DNS Provider can simply indicate that the records required for ECH do not exist, and your web browser wouldn't encrypt the ClientHello. It's already tampering with the responses to address lookups anyway, so DNSSEC wouldn't be an issue -- you simply would not expect to be able to validate anything.
Instead, NextDNS is very likely abusing the EDNS Client Subnet feature to provide website operators with a spoofed client location. Much more simple and less nefarious.
> A certificate has to be signed by a trusted CA (one your browser already trusts).
Yes.
> A DNS provider could mint a self-signed cert for pornhub.com, but your browser would reject it immediately.
I never said anything about the DNS provider minting any certificates, and explicitly said that the certificate would be provided by PornHub's servers and merely relayed -- verbatim -- through the DNS provider. As well as the rest of the TLS negotiation.
> Instead, NextDNS is very likely abusing the EDNS Client Subnet feature to provide website operators with a spoofed client location.
That's what they are doing now, yes. What I propose is how they can continue to make it work once the website operators catch on and start looking at the ASN information of the source IP address of the HTTP connection.
I am well aware of how CAs and the Web PKI model and TLS work.
Ah, ok... a transparent proxy just to hide the origin IP. Thanks for clarifying. A lot of people are assuming full proxying, but I understand you were describing a hypothetical.
Right. What I proposed is scarcely different from doing HTTPS over a SOCKS5 proxy. It's just that the proxy would infer your destination from the ClientHello rather than being instructed by the client in advance (Edit: and it would have to assume port 443 -- a safe assumption in the context of a service whose feature is bypassing website content blocking).
I tried out NextDNS and this feature doesn't seem to work anyway. Enabling "Bypass Age Verification" has no effect. I tested it out on PornHub and XVideos.
I also can't find anything different in the returned A/AAAA records compared to my standard resolver.
