Your own servers probably also dont have HSTS enabled, or clicking continue will be disabled (if not overwritten in your browser-config)
Your own servers probably also dont have HSTS enabled, or clicking continue will be disabled (if not overwritten in your browser-config)
Thats why we now have certificate transparency reports and CA-records.
Sure not perfect, but at least with a compliant CA it wont just happen in the dark.
At some point you have to trust someone.
Thats why we have HSTS and HSTS preloading, so the browser refuses to allow this (and disabling it is usually alot deeper to find than a simple button to “continue anyways”)
Yeah and discord is allowing it. Thats all i am saying.
Of course Restorecord is doing it on purpose. There are some valid reasons, but maybe Discord shouldt allow untrusted bot-developers like them to do so.
afaik thats rather about the parallel service someone had selling the data for a subscription and getting that data from restorecord’s database.
In the video it is already suspected restorecord is in on it, and the update comment proves it.
The problem with restorecord getting that data in the first place persists. I am not aware if Discord is tackling that issue at all e.g. making it against EULA and banning those bots.
Discord bots were able to get a users IP via the verification system afaik.
And there are of course other ways to force users to do so. Its more interesting Discord themselves didnt care about these methods to ban such bots… well its Discord, not that surprising when i think about it.
But they are leaving it open…
Indeed, not classically, but there are HSTS preload lists you can put your domain into which will be downloaded by supported browsers.
And via HSTS you can include all your subdomains, which would then force proper TLS connections for those you havent visited before too.
With the new TLS1.3 version we are getting the HTTPS / “SVCB” Record which not only allows ECH but also indicates to the client similar protection policies like HSTS. (RFC 9460)
ECH will then make such attacks impossible on TLS-level, assuming DNSSEC is used and client can make an integrity-checked lookup e.g. via DoH/DoT or validating DnsSec themselves.
The strength of this depends on the security-chain you want to follow of course. You dont need DNSSEC, but then the only integrity-check is between DNS-Service and Client if they use DoH/DoT (which is usually enough to defeat local attackers)