We spent $20 to achieve RCE and accidentally became the admins of .mobi
labs.watchtowr.com
labs.watchtowr.com
> As part of our research, we discovered that a few years ago the WHOIS server for the .MOBI TLD migrated from whois.dotmobiregistry.net to whois.nic.mobi – and the dotmobiregistry.net domain had been left to expire seemingly in December 2023.
Never ever ever ever let a domain expire. If you're a business and you're looking to pick up a new domain because it's only $10/year, consider that you're going to be paying $10/year forever, because once you associate that domain with your business, you can never get rid of that association.
Domains are really cheap, I try to just pay for 5-10 year blocks (as many as I can), when I can just to reduce the issues.
The technical perspective is that things like wildcard subdomains (e.g. to support yourcustomername.example.com), or DNSSec if your compliance requires it, etc. cause an extra burden if done for these two use-cases at a time.
> can't easily click
Http pages don't have problems with having a link to example.net from within example.com. Or the opposite. Seems like an unrelated problem.
Easier and safer to have separate domains.
2. if a user uploaded something like an html file, you wouldn't want it to be able to run javascript on google.com (because then you can steal cookies and do bad stuff), csp rules exist, but it's a lot easier to sandbox users content entirely like this.
Cookies are the only problem here, as far as I know, everything else should be sequestered by origin, which includes the full domain name (and port and protocol). Cookies predate the same-origin policy and so browsers scope them using their best guess at what the topmost single-owner domain name is, using—I kid you not—a compiled-in list[1]. (It’s as terrifying as it sounds.)
- is allowed to set cookies scoped to *.github.com, interfering with cookie mechanisms on the parent domain and its other subdomains, potentially resulting in session fixation attacks
- will receive cookies scoped to *.github.com. In IE, cookies set from a site with address "github.com" will by default be scoped to *.github.com, resulting in session-stealing attacks. (Which is why it's traditionally a good idea to prefer keeping 'www.' as the canonical address from which apps run, if there might be any other subdomains at any point.)
So if you've any chance of giving an attacker scripting access into that origin, best it not be a subdomain of anything you care about.
I read about this a while back but I can't find the link anymore (and it's not the same one that op pointed to).
Imagine if eg.com allowed user subdomains, and some users added logins to their subdomains for whatever reason, there's a potential for an adversarial user to have a subdomain and just record all logins attempted, because browsers will automagically autofill into any subdomain.
if you need proof i can take a screenshot, it's ridiculous, and i blame google - it used to be the standard way of having users on your service, and then php and apache rewrite style usage made example.com/user1 more common than user1.example.com.
They have. That's why PSL list exists. It applies to all CSP rules.
> if i have example.com login saved,
It's the passsword wallet thing. It uses different rules and have no standards
Also in the case of HTTP/1 browsers will limit the number of simultaneous connections by host or domain name, and this was a technique for doubling those parallel connections. With the rise of HTTP/2 this is becoming moot, and I'm not sure of the exact rules of modern browsers to know if this is still true anyway.
Example I have is - I have a domain that allows users to upload images. Some people abuse that. If google delists that domain, I haven't lost SEO if the user content domain gets delisted.
I presume this issue has been reduced over the years by browsers as part of the third-party cookies denial fixes...?
Definitely was a bad security problem.
If your main web page is available at example.com, and the CMS starts sending HSTS headers, stuff on subdomain.example.com can suddenly break.
Businesses only ever need two $10 domains, usercompany.com and company.com, just in case they ever want to host user generated content.
https://money.cnn.com/2016/01/29/technology/google-domain-pu...
Please elaborate...
Also, what about personal domains? Does it apply there as well?
Personal domains are up to you.
Since the documentation is Apache License 2.0 there isn't much one can do, other than complain to the hosting about misuse of the project name/branding. But so far we haven't heard back from the hosting provider's abuse contact point (https://github.com/jodal/pykka/issues/216 if anyone is interested).
Unlike in Germany, where you can’t get one without a passport or ID card.
They're not tied to your person with much more permanency than a DHCP IP address. There's no process to verify your identity or recover your number or help you regain your accounts. The actual process for migrating your number is "Sign up with this other brand you've never tried before and tell them to politely ask your former brand to release the number to them".
If I lose my phone to a trash compactor, the process to change anything in my phone carrier account with regard to SIM cards is going to forward things to my Gmail account, which at random times for random reasons is going to begin to demand 2 factor identification for logging in on a new device via texting my phone number.
There are all sorts of crazy scenarios that can arise with double binds like this.
If we had a resilient authoritative identity verification (say, the DMV, or US Passport Office), or if we had a diverse variety of low-trust identity factors that we could check multiple aspects of ("text my mother" / "Here's a bill showing my address" / "here's a video of my phase saying my phone number"), there would be a way out, but all of corporate America heard "2fa is required for security now" and said "So we just text them right?"
That makes your phone not "another thing that people can use to talk to you in circumstances when you're not accessible", which the FCC's portability plan was maybe sufficient for, but a fragile single point of failure for your entire identity.
https://www.fcc.gov/general/wireless-local-number-portabilit...
Is it possible to "park" your phone number until you can start a new plan?
Though AFAIK there's no law or contract term preventing Google from starting to charge a monthly fee in the future.
And after some time — for me it was 5+ years, porting from a baby Bell land line to a postpaid T-Mobile family plan for a couple years and then to Google Voice — your number will be tarred and feathered as a "VoIP" number and rejected for identity verification by some parties until it's ported back to a paid service (again, after some time).
Even so, it's nice that Google lets me keep the number I was born with for $0/month for as long as it lasts.
This is despite written emails from their support confirming the use case (videography) and storage needs were suitable, and a written statement that she is "permanently grandfathered" once Google stopped offering the plan to new customers.
To make matters worse, they gave her 30 days to download all data before everything would be deleted permanently. This is how Google treats "enterprise" customers.
Where things get fun is when Google Voice IS your paid service (e.g. google fiber's phone service, popular with a certain demographic that used POTS for most their life and want to continue having a similarly behaving service).
It just makes many services such as Credit Karma unavailable to anyone but the first person to signup.
ICANN provides some protection for standard gTLD domains, but it's minimal. You're guaranteed identical pricing to all other standard domain registrants on the gTLD, so they can only raise your price by raising the price of everyone else at the same time. That hasn't stopped some registries from 10x price increases though. The only thing it does is ensure they can't single you out and massively hike your renewal fee.
However, that does not apply to registry premium gTLD domains. When you register a registry premium domain you waive those protections and the registries can technically do anything they want.
If you register a ccTLD domain, you're at the mercy of that country's registry. If you register a 3rd level domain you're at the mercy of the 2nd level domain owner and they're regulated by either ICANN or a country based registry.
It's actually somewhat complex when you get into it.
DNS providers can't do this.
It's domain registries that can.
Granted, I also have zero respect for people who think that trademarks, patents, and copyright are still working to promote rather than stifle the arts and sciences, so I can understand why my above sentiment might rankle.
The next year they decided it was premium after all, and wanted to charge £492,000 for renewal. I still have a screenshot of that, although needless to say I don't own the domain anymore.
That's insane though, I assumed renewal prices were more or less locked in after you own a domain. Even the premium ones that go for thousands say they renew at the standard $12 or whatever.
Put another way, as soon as you register a .com domain, the only registry that can sell you a renewal is Verisign. If there weren't price controls, Verisign could increase the price of a .com renewal to $100 and there's nothing anyone could do but pay it.
This whole thread back to the root is right. Verisign has a monopoly, you can never drop a domain once it's associated with your business, and all of it should be regulated like a monopoly.
How do mega corps remember to pay their domain bills? Do they pay an (overpriced) registrar for "infinity" years of renewals? This seems like a genuinely hard business operations problem.
Even when companies don't have their own top-level domain, they can have their own domain registrar. For example "facebook.com" is registered with "registrarsafe.com" as registrar. The latter registrar is a wholly owned subsidiary of Facebook. I learned this from this HN thread https://news.ycombinator.com/item?id=28751497
Found this out when some of our emails started bouncing...
[1] https://en.wikipedia.org/wiki/ARPANET#Debate_about_design_go...
Seems there is a standard (?) way of registering this in DNS, but just from a quick test, a lot of TLDs are missing a record. Working example:
dig _nicname._tcp.fr SRV +noall +answer
_nicname._tcp.fr. 3588 IN SRV 0 0 43 whois.nic.fr.
There's an expired Internet Draft for this: https://datatracker.ietf.org/doc/html/draft-sanz-whois-srv-0...
mobi.whois.arpa. CNAME whois.nic.mobi
Although as fanf2 points out below, it seems you could also just start with the IANA whois server. Querying https://www.iana.org/whois for `mobi` will return `whois: whois.nic.mobi` as part of the answer.
Developer incompetence is one thing, but AI-hallucination will make this even worse.
Whether it’s this sort of thing, a stale-but-important URL hanging out somewhere, someone on your team signing up for a service with an old domain-email, or whatever, it’s just so hard to know when it’s truly okay let an old domain go.
Unfortunately, it isn't required for ccTlds, and there are plenty of non-ccTlds that aren't working.
https://en.wikipedia.org/wiki/Registration_Data_Access_Proto...
IMHO, there is no reason for a registrar to not support RDAP, and to have the RDAP server's address registered with ICANN.
>The dotmobiregistry.net domain, and whois.dotmobiregisry.net hostname, has been pointed to sinkhole systems provided by ShadowServer that now proxy the legitimate WHOIS response for .mobi domains.
If those domains were meant to be deprecated should be better to return a 404. Keeping them active and working like normal reduces the insensitive to switch to the legitimate domain.
Domain not found.
>>> Please update your code or tell your system administrator to use whois.nic.mobi, the authoritative WHOIS server for this domain. <<<That is never going to work. Even log4j, 40% of all downloads are vulnerable versions. Much less when a vendor in a chain goes out of business or stops maintaining a component.
Everything is always going to be buggy and full of holes, just like our body is always full of battlefields with microbes.
It will be probably a few decades, but the road seems pretty clear. Put in the work, apply the knowledge gained from all the "lessons learned" and don't stop.
If only the naysayers had listened and fixed their parsing, the post authors might've been spared.
Let's flip that on its head - are we expected to trust every single WHOIS server in the world to always be authentic and safe? Especially from the point of view of a CA trying to validate TLS, I would not want to find out that `whois somethingarbitrary.ru` leaves me open to an RCE by a Russian server!
Oh cool they saved the logs in a database ! Wait... |sort|uniq|wc -l ?? But why ?
-- COUNT ( DISTINCT ... ) ~= uniq | wc -l ;; sort without -u is this busybox? ORDER BY col ASC
-- wait this doesn't need sort and uniq if it's just being counted...
SELECT COUNT( DISTINCT source ) FROM queries
Sure there are problems with this conjecture, like what if the attacker is just as incompetent (it just gets captured again), or "bad actor" etc. A concept similar to capture the flag might provide for evolving better approaches toward security than the traditional legal and financial methods of organizational capture the flag.
OTOH, if the capture failed to also capture banking flows from customers to the service, then the capturer would have a paddle-less canoe.
R̶i̶g̶h̶t̶ o̶f̶f̶ t̶h̶e̶ b̶a̶t̶, S̶T̶O̶P̶. I̶ d̶o̶n̶'t̶ c̶a̶r̶e̶ w̶h̶o̶ y̶o̶u̶ a̶r̶e̶ o̶r̶ h̶o̶w̶ "w̶e̶l̶l̶-̶i̶n̶t̶e̶n̶t̶i̶o̶n̶e̶d̶" s̶o̶m̶e̶o̶n̶e̶ i̶s̶. I̶n̶t̶e̶n̶t̶i̶o̶n̶a̶l̶l̶y̶ s̶p̶r̶i̶n̶k̶l̶i̶n̶g̶ i̶n̶ v̶u̶l̶n̶e̶r̶a̶b̶l̶e̶ c̶o̶d̶e̶, K̶N̶O̶W̶I̶N̶G̶L̶Y̶ a̶n̶d̶ W̶I̶L̶L̶I̶N̶G̶L̶Y̶ t̶o̶ "a̶t̶ s̶o̶m̶e̶ p̶o̶i̶n̶t̶ a̶c̶h̶i̶e̶v̶e̶ R̶C̶E̶" i̶s̶ b̶e̶h̶a̶v̶i̶o̶r̶ t̶h̶a̶t̶ I̶ c̶a̶n̶ n̶e̶i̶t̶h̶e̶r̶ c̶o̶n̶d̶o̶n̶e̶ n̶o̶r̶ s̶u̶p̶p̶o̶r̶t̶. I̶ t̶h̶o̶u̶g̶h̶t̶ t̶h̶i̶s̶ k̶i̶n̶d̶ o̶f̶ r̶o̶g̶u̶e̶ c̶o̶n̶t̶r̶i̶b̶u̶t̶i̶o̶n̶s̶ t̶o̶ p̶r̶o̶j̶e̶c̶t̶s̶ h̶a̶d̶ a̶ g̶r̶e̶a̶t̶ e̶x̶a̶m̶p̶l̶e̶ w̶i̶t̶h̶ t̶h̶e̶ U̶n̶i̶v̶e̶r̶s̶i̶t̶y̶ o̶f̶ M̶i̶n̶n̶e̶s̶o̶t̶a̶ o̶f̶ w̶h̶a̶t̶ n̶o̶t̶ t̶o̶ d̶o̶ w̶h̶e̶n̶ t̶h̶e̶y̶ g̶o̶t̶ a̶l̶l̶ t̶h̶e̶i̶r̶ c̶o̶n̶t̶r̶i̶b̶u̶t̶i̶o̶n̶s̶ r̶e̶v̶o̶k̶e̶d̶ a̶n̶d̶ f̶o̶r̶c̶e̶ r̶e̶v̶i̶e̶w̶e̶d̶ o̶n̶ t̶h̶e̶ L̶i̶n̶u̶x̶ k̶e̶r̶n̶e̶l̶.
EDIT: This is not what the group has done upon further scrutiny of the article. It's just their very first sentence makes it sound like they were intentionally introducing vulnerabilities in existing codebases to achieve a result.
I definitely can see that it should have been worded a bit better to make the reader aware that they had not contributed bad code but were finding existing vulnerabilities in software which is much better than where I went initially.
But also, we really need our software supply chains to be resilient. That means building a better cultural immune system toward malicious contributors than “please don’t”. Because the bad guys won’t respect our stern, disapproving looks.
This is the problem with allowing a critical domain to expire and fall into evil hands when software you don't control would need to be updated to not use it.
Definitely they could have worded that better to make it not sound like they had been intentionally contributing bad code to projects. I'll update my original post to reflect that.
We need to focus on the important things: not telling anyone, and not trying to break anything. It's important to just not have any knowledge on this stuff at all
It's one thing if you're trying to make sure that maintainers are actually reviewing code that is submitted to them and fully understanding "bad code" from good but a lot of open source projects are volunteer effort and maybe we should be shifting focus to how maintainers should be discouraged from accepting pull requests where they are not 100% confident in the code that has been submitted. Not every maintainer is going to be perfect but it's definitely not an easy problem to solve overnight by a simple change of policy.
The negligent part was not holding the domain with an error result for 10 years and respond to every request with an email telling them to stop using that domain. And I say 10 years because 10 years of having a broken system is already way too long to not go addressing, no matter how sluggish the service underneath.
You can not be expected to cover your own ass for OTHER people's fuckups into perpetuity. Every system issuing an whois to a supposed dead domain should be considered the actual responsible party for this.
Since the registrar could very easily determine whether or not the domain was in active use in the wild (and still return an error if they wanted), and didn't, I do consider it negligence.
People hard-code them, they end up in configs, all over, specially in forgotten or hard-to-change places.
$20 a year forever is pretty cheap for a company.
It’s tempting to hold onto every domain ‘just in case,’ but cutting domains without a proper risk assessment can open the door to serious security issues, as this article points out.
But seriously, it was the most frustrating thing about the mobile web.
Is this TLD even worth a damn in 2024?
IMO: No. Table stakes nowadays are for all web sites to support mobile devices; the notion of having a separate web site for mobile users, let alone an entire TLD for those web sites, is obsolete.
> Never Update, Auto-Updates And Change Are Bad
as the source of the problem a couple of times.
This is pretty common take from security professionals, and I wish they'd also call out the other side of the equation: organizations bundling their "feature" (i.e. enshittification) updates and security updates together. "Always keep your programs updated" is just not feasible advice anymore given that upgrades as just as likely to be downgrades these days. If that were to be realistic advice, we need more pressure on companies to separate out security-related updates and allow people to get updates only on that channel.
I actually think it's viable to fix, I am simply not sure if anyone would pay for it — basically, old LTS model from Linux distributions where a set of packages gets 5 or 10 years of guaranteed security updates (backported, maintaining backwards compatibility otherwise).
If one was to start a business of "give me a list of your FLOSS dependencies and I'll backport security fixes for you for X", what's X for you?
- Be inherently less trustworthy of more unique TLDs where this kind of takeover seems more likely due to less care being taken during any switchover.
- Don't use any "TLS/SSL Certificate Authorities/resellers that support WHOIS-based ownership verification."
- If someone manages to MitM the communication between e.g. Digicert and the .com WHOIS server, then they can get a signed certificate from Digicert for the domain they want
- Whether you yourself used LE, Digicert or another provider doesn't have an impact, the attacker can still create such a certificate.
This is pretty worrying since as an end user you control none of these things.
If we were able to guarantee NO certificate authorities used WHOIS, this vector would be cut off right?
And is there not a way to, as a website visitor, tell who the certificate is from and reject/distrust ones from certain providers, e.g. Digicert? Edit: not sure if there's an extension for this, but seems to have been done before at browser level by Chrome: https://developers.google.com/search/blog/2018/04/distrust-o...
However, this depends strongly on how the attacker uses the cert. If they hijack your DNS to ensure "fun.tetha.example" goes to a record they control, they can also drop or modify the CAA record.
And sure, you could try to prevent that with long TTLs for the CAA record, but then the admin part of my head wonders: But what if you have to change cert providers really quickly? That could end up a mess.
The CAA record essentially says "I, the owner of this DNS name, hereby instruct you, the Certificate Authorities to only issue certificates for this name if they obey these rules"
It is valid, and perhaps even a good idea in some circumstances, to set the CAA record for a name you control to deny all issuance, and only update it to allow your preferred CA for a few minutes once a month while actively seeking new certificates for any which are close to expiring, then put it back to deny-all once the certificates were issued.
Using CAA allows Meta, for example, to insist only Digicert may issue for their famous domain name. Meta has a side deal with Digicert, which says when they get an order for whatever.facebook.com they call Meta's IT security regardless of whether the automation says that's all good and it can proceed, because (under the terms of that deal) Meta is specifically paying for this extra step so that there aren't any security "mistakes".
In fact Meta used to have the side deal but not the CAA record, and one day a contractor - not realising they're supposed to seek permission from above - just asked Let's Encrypt for a cert for this test site they were building and of course Let's Encrypt isn't subject to Digicert's agreement with Meta so they issued based on the contractor's control over this test site. Cue red faces for the appropriate people at Meta. When they were done being angry and confused they added the CAA record.
[Edited: Fix a place where I wrote Facebook but meant Meta]
https://www.cloudflare.com/learning/security/what-is-remote-...
Maybe they read your comment and fixed it?
What? No.
eval($var . '="' . str_replace('"', '\\\\"', $itm) . '";');
PHP provides a built in escaper for this purpose
eval($var . '=' . var_export($itm, true) . ';');
${$var} = $itm;
So kind of both.
You can become a good person late in life and still be lonely because all your bridges are burned to the ground.
I think the word you’re looking for is “epic” or “legendary”
What would you use to build and self-host an ecommerce site quickly and that is not a SaaS?
Google for example does exactly this.
I left Amazon 2020. Had various collaborations with ecommerce (mainly around fulfillment) and there was plenty of Mason around.
It’s not that PHP somehow makes people write terrible code, I think it’s just the fact that it’s been out for so long and so many people have taken a crack at learning it. Plus, it seems that a lot of ingrained habits began back when PHP didn’t have many of its newer features and they just carried on, echoing through stack overflow posts forever.
IMO it’s because php and js are so easy to pick up for new programmers.
They are very forgiving, and that leads to… well… the way that php and js is…
It's a very similar exploit.
(to include the ones that appeared in the time I spent typing this post)
If you were doing things right, by that point you were already using Laravel or Symphony or something, so the change didn't seem as revolutionary as it was, but that was the moment a lot of dumb string concatenated query code (for example) no longer worked out of the box.
The main use I know of goes away with workers.
Mind you this was more than ten years ago when PHP was fixing exploits left and right.
This dust up resolved itself within 24 hours though, as I came in the next morning to find he was too busy to work on something else because he was having to patch the PHP forum software he administered because it had been hacked overnight.
I did not gloat but I had trouble keeping my face entirely neutral.
Now I can’t read PHP for shit but I tried to read the patch notes that closed the hole. As near as I could tell, the exact same anti pattern appeared in several other places in the code.
I can’t touch PHP. I never could before and that cemented it.
A developer who has the aptitude to write a whois client, but knows neither of those things? It just seems very unlikely.
Let's add a few:
1. WHOIS isn't encrypted or signed, but is somehow suitable for verification (?)
2. DNS CAA records aren't protected by DNSSEC, as absence of a DNS record isn't sign-able (correction: NSEC is an optional DNSSEC extension)
3. DNS root & TLD servers are poorly protected against BGP hijacks (adding that DNSSEC is optional for CAs to verify)
4. Email, used for verification in this post, is also poorly protected against BGP hijacks.
I'm amazed we've lasted this long. It must be because if anyone abuses these issues, someone might wake up and care enough to fix them (:
NSEC does this.
> An NSEC record can be used to say: “there are no subdomains between subdomains X and subdomain Y.
Unfortunately though, the entire PKI ecosystem is tainted if other CAs do not share the same security posture.
[1] https://cabforum.org/working-groups/server/baseline-requirem...
[2] https://www.verisign.com/en_US/company-information/verisign-...
Let's convince all registrars to implement a new standard? ouch.
At that point, it doesn't matter how many vantage points you verify from: all traffic goes to your hijack. It only takes a few seconds for you to verify a certificate, and then you can drop your BGP hijack and pretend nothing happened.
Thankfully there are initiatives to detect and alert BGP hijacks, but again, if your organization does not have a strong security competency, you have no knowledge to prevent nor even know about these attacks.
It took me 3 years of getting SSL certs from the same company through a convoluted process before I tried a different company. My domain has been with the same registrar since private citizens could register DNS names. That relationship meant nothing when trying to prove that I'm me and I own the domain name.
I went back to the original company because I could verify myself through their process.
My only point is that human relationships is the best form of verifying integrity. I think this provides everyone the opportunity to gain trust and the ability to prejudge people based on association alone.
This sort of trust is only as strong as it's weakest link but each individual can choose how far to extend their own trust.
A better approach is to have hyperlocal offices where you can go to do business. Is this less “efficient”? Yes but when the proceeds of efficiency go to shareholders anyway it doesn’t really matter.
I agree with this but that means you need to regulate it. Even banks nowadays are purposely understaffing themselves and closing early because "what the heck are you going to do about it? Go to a different bank? They're closed at 4pm too!"
The earliest banking was done with letters of introduction. That is why banking families had early international success. They had a familial trust and verification system.
> This sort of trust is only as strong as it's weakest link but each individual can choose how far to extend their own trust.
is exactly why I prefer PKI to the WoT. If you try to extend the WoT to the whole Internet, you will eventually end up having to trust multiple people you never met with them properly managing their keys and correctly verifying the identity of other people. Identity verification is in particular an issue: how do you verify the identity of someone you don't know? How many of us know how to spot a fake ID card? Additionally, some of them will be people participating in the Web of Trust just because they heard that encryption is cool, but without really knowing what they are doing.
In the end, I prefer CAs. Sure, they're not perfect and there have been serious security incidents in the past. But at least they give me some confidence that they employ people with a Cyber Security background, not some random person that just read the PGP documentation (or similar).
PS: there's still some merit to your comment. I think that the WoT (but I don't know for sure) was based on the 7 degrees of separation theory. So, in theory, you would only have to certify the identity of people you already know, and be able to reach someone you don't know through a relatively short chain of people where each hop knows very well the next hop. But in practice, PGP ended up needing key signing parties, where people that never met before were signing each other's key. Maybe a reboot of the WoT with something more user friendly than PGP could have a chance, but I have some doubts.
Honestly: we're in this situation because we keep trying to band-aid solutions onto ancient protocols that were never designed to be secure. (I'm talking about you DNS.) Given xkcd's wisdom though, I'm not sure if this is easily solvable.
only then can it be trustworthy, fast and free/accessible
If you can't trust DNS, you can't trust TLS or anything downstream of it.
Even banks are not bothering with EV certificates any more, since browsers removed the indicator (for probably-good reasons). DV certificate issuance depends on trustworthy DNS.
Internet security is "good enough" for consumers, most of the time. That's "adequately trustworthy", but it's not "very trustworthy".
However, I don't think it's reasonable to call DNS, as a system, "very trustworthy".
"Well-secured" by active effort, and consequently "adequately trustworthy" for consumer ecommerce, sure.
But DNS is a systemic weak link in the chain of trust, and must be treated with extra caution for "actually secure" systems.
(E.g., for TLS and where possible, the standard way to remove the trust dependency on DNS is certificate pinning. This is common practice, because DNS is systemically not trustworthy!)
I think you're "well-secured" comment is saying the same thing I am, with some disagreement about "adequate" vs "very". I don't spend any time worrying that my API calls to AWS or online banking transactions are insecure due to lack of DNSSEC, so the DNS+CA system feels "very" trustworthy to me, even outside ecommerce. The difference between "very" and "adequate" is sort of a moot point anyway: you're not getting extra points for superfluous security controls. There's lots of other things I worry about, though, because attackers are actually focusing their efforts there.
As always, it ultimately depends on your threat profile, real or imagined.
Re: certificate pinning, it's common practice in the financial industry at least. It mitigates a few risks, of which I'd rate DNS compromise as more likely than a rogue CA or a persistent BGP hijack.
On the other hand things like SMTP truly are ancient. They were designed to do things that just aren’t a thing today.
I think that covers everything in that list. For example, trying to go from IPv4 to IPv6 is a totally different kind of problem from the one in the comic.
Bolting on extensions to existing protocols not designed to be secure, while improving the situation, has been so far unable to address all of the security concerns leaving major gaps. It's just a fact.
The problem is, in many of these fields actual real-world politics come into play - you got governments not wanting to lose the capability to do DNS censorship or other forms of sabotage, you got piss poor countries barely managing to keep the faintest of lights on, you got ISPs with systems that have grown over literal decades where any kind of major breaking change would require investments into rearchitecture larger than the company is worth, you got government regulations mandating stuff like all communications of staff be logged (e.g. banking/finance) which is made drastically more complex if TLS cannot be intercepted or where interceptor solutions must be certified making updates to them about as slow as molasses...
I think this is a 20-year old argument, and it’s largely irrelevant in 2024.
It's not irrelevant - AWS lacks support for example in EKS or in ELB target groups, where it's actually vital [1]. GCE also lacks IPv6 for some services and you gotta pay extra [2]. Azure doesn't support IPv6-only at all, a fair few services don't support IPv6 [3].
The state of IPv6 is bloody ridiculous.
[1] https://docs.aws.amazon.com/vpc/latest/userguide/aws-ipv6-su...
[2] https://cloud.google.com/vpc/docs/ipv6-support?hl=de
[3] https://learn.microsoft.com/en-us/azure/virtual-network/ip-s...
Then if you look at the internet, there is a very uncoordinated collection of manufacturers, network providers, and standardization is driven in a more open manner that is good for transparency but is also prone to complexifying log-jams and hecklers vetos. Where we see success, like the promotion of TLS improvements, it's largely because a small number of knowledgable players - browsers in the case of TLS - agree to enforce improvements on the entire eco-system. That in turn is driven by simple self-interest. Google, Apple, and Microsoft all have strong incentives to ensure that TLS remains secure; their ads and services revenue depend upon it.
But technologies like DNSSEC, IPv6, QUIC all face a much harder road. To be effective they need a long chain of players to support the feature, and many of those players have active disincentives. If a home users internet seems to work just fine, why be the manufacturer that is first to support say DNSSEC validation and deal with all of the increased support cases when it breaks, or device returns when consumers perceive that it broke something? (and it will).
Dnssec shouldn't be as bad, but for dns resolvers and software that build them in. I think it's a bit worse than TLS adoption in part just because of DNS allowing recursive resolution and in part DNS being applicable to a bit more than TLS was. But the big thing seems to be that there isn't a central authority like web browsers who can entirely force the issue. ... Maybe OS vendors could do it?
Quic is an end to end protocol so should be deployable without every network operator buying in. That said, we probably do need a reduction in udp blocking in some places. But otherwise, how can quic deployment be harder than TLS deployment? I think there just hasn't been incentive to force it everywhere.
IPv6 is simpler in a lot of ways than ipv4 - fewer headers/extensions, no support for fragmentation. What makes it more complicated? What makes the failure modes more obscure? Is it just that dual stack is more complex to operate?
The problem with DNSSEC is that deploying it breaks DNS. Anything that goes wrong with your DNSSEC configuration is going to knock your whole site off the Internet for a large fraction of Internet users.
Very aware that dual stack deployment is a thing. It's really the only sane way to do the migration for any sizable network, but obviously increases complexity vs a hopeful future of IPv6 only.
Good point about dnssec, but this is par for the course with good security technologies - it could break things used to be an excuse for supporting plaintext http as a fallback from https / TLS. If course having an insecure fallback means downgrade attacks are possible and often easy, so defeats a lot of the purpose of the newer protocols
"Our industry" is a pile of snakes that abhor the idea of collaboration on common technologies they don't get to extract rents from. ofc things are they way they are.
The industry is profit driven.
The point is that our industry has a lot of opinionated individuals that tend to disagree on fundamentals, implementations, designs, etc., for good reasons! That's why we have thousands of frameworks, hundreds of databases, hundreds of programming languages, etc. Not everything our industry does is profit driven, or even rational.
> Our industry does not argue about code style.
QED
I'm convinced it's just human nature to work on something while it is interesting and move on. What is the motivation to actually finish?
Why would the the technologies that should hold up the Internet itself be any different?
All that said, even the sense of completing or finishing a thing only really happens in small and limited-scope things, and in that sense it's very much human nature, yeah. You can see this in creative works, too. It's rarely "finished" but at some point it's called done.
I bet they never finished it, since the perpetrators are half the remaining team.
How is checking if, say, the source address is 255.255.255.255 to trigger special processing, any easier than checking if the version number is 6? If you're thinking about passing IPv6 packets through an IPv4 section of the network, that can already be achieved easily with tunneling. Note that ISPs already do, and always have done, transparent tunneling to pass IPv6 packets through IPv4-only sections of their network, and vice versa, at no cost to you.
Edit: And if you want to put the addresses of translation gateways into the IPv4 source and destination fields, that is literally just tunneling.
If anyone knows they are being abused, anyway. I conclude that someone may be abusing them, but those doing so try to keep it unknown that they have done so, to preserve their access to the vulnerability.
It was long ago, and I don't remember the details, but I do remember a lot of people having shit hemorrhages.
Additionally, Google has pinned their certificates in Chrome and will alert via Certificate Transparency if unexpected certificates are found. [2]
It is unlikely this has been abused without anyone noticing. With that said, it definitely can be, there is a window of time before it is noticed to cause damage, and there would be fallout and a "call to action" afterwards as a result. If only someone said something.
[1] https://certificate.transparency.dev [2] https://github.com/chromium/chromium/blob/master/net/http/tr...
A big company might discover millions are missing years after the fact and back date reports. But nobody is ever going to record those office supplies.
Now, the application using TLS probably cares, and most Internet applications want an X.509 certificate, conforming more or less with PKIX and typically from the Web PKI. But TLS doesn't care about those details.
HTTP-based ACME verification also uses unencrypted port-80 HTTP. Similar for DNS-based verification.
This should make getting a cert via BGP hijack very difficult.
[1] https://github.com/cabforum/servercert/blob/main/docs/BR.md#...
I mean, they need to bootstrap the verification somehow no? You cannot upgrade the first time you request a challenge.
If we really wanted verification we would still be manually verifying the owners of domains. Highly effective but expensive.
Do mail servers even verify TLS certs these days instead of just ignoring them?
I don't want to live on this planet anymore
The non-sensicalness of it is just a phase. Remember the Tower of Babel didn't stop humanity.
Here is a link that was posted a few days ago regarding how great things are compared to 200 years ago. Ice cream has only become a common experience in the last 200 years..
https://ourworldindata.org/a-history-of-global-living-condit...
“be the change” or some such
https://duckduckgo.com/?q=crypt+site:reddit.com/r/lolphp
>crc32($str) and hash("crc32",$str) use different algorithms ..
>Password_verify() always returns true with some hash
>md5('240610708') == md5('QNKCDZO')
>crypt() on failure: return <13 characters of garbage
> strcmp() will return 0 on error, can be used to bypass authentication
> crc32 produces a negative signed int on 32bit machines but positive on 64bit mahines
>5.3.7 Fails unit test, released anyway
The takeaway from these titles is not the problems themselves but the pattern of failure and the issue of trusting the tool itself. Other than that if you've used php enough yourself you will absolutely find frustration in the standard library
If you're looking for something more exhaustive there's the certified hood classic "PHP: A fractal of bad design" article as well that goes through ~~300+~~ 269 problems the language had and/or still has.
https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
Though most of it has been fixed since 2012, there's only so much you can do before the good programmers in your community (and job market) just leave the language. What's left is what's left.
Lingering bad reputation, from the bad old days
Minimal barrier to entry - which both makes it a go-to for people who should not be writing production code in any language, and encourages many higher-skill folks to look down on it
Start shipping the compiler with your code for infrastructure-agnostic RCEs
Anyway, turns out that shelling out to an external binary fed with bytes from the Internet is good fun
b) It's a legacy misfeature that I hope new compiled languages don't copy. There are much much better better interfaces for running processes that don't rely on an intermediate shell.
c) Shell escaping is much more stable than some hipster language like PHP where you'd need to update your escaping for new language changes all the time.
Our computer security analogies are modeled around securing a home from burglars, but the actual threat model is the ocean surging 30 feet onto our beachfront community. The ocean will find the holes, no matter how small. We are not prepared for this.
While I wouldn't have too much of an issue with that, I'm pretty sure I'm a minority with that
Correct.
https://en.wikipedia.org/wiki/2014_celebrity_nude_photo_leak
https://www.cybersecurity-insiders.com/glitch-makes-data-fro...
https://arstechnica.com/gadgets/2023/09/apple-patches-clickl...
Well, no home is burglar-proof either. Just like with computer security, we define , often just implicitly, a threat model and then we decide which kind of security measures we use to protect our homes. But a determined burglar could still find a way in. And here we get to a classic security consideration: if the effort required to break your security is greater than the benefit obtained from doing so, you're adequately protected from most threats.
It's no huge loss if the sea takes all the cat photos off my phone. But if you're a hospital or civil services admin hooking up your operation to the Internet, you gotta be prepared for it all to go out to sea one day, because it will. Is that worth the gains?
(Possibly even negative, when people go out and deliberately install apps that, by backdoor or by design, hoover up their data, etc. And when the mainstream OSes are disincentivized to prevent this because it's their business model too.)
There was a time, not very long ago, when I could just tcpdump my cable-modem interface and know what every single packet was. The occasional scan or probe stuck out like a sore thumb. Today I'd be drinking from such a firehose of scans I don't even have words for it. It's not even beachfront property, we live in a damn submarine.
Of course there is, and things are only getting more secure. Just because a lot of insecurity exists doesn't mean computer security isn't possible.
Computer security is impossible at the prices we can afford. That doesn't mean we can't use computers, but it does mean we need to assess the threats appropriately. I don't think most people do.
> People are building new software all the time. It all has bugs. It will always have bugs.
No. Most bugs these days are due to legacy decisions where security was not an issue. We are making advances in both chip and software security. Things are already vastly more secure than they were 20 years ago.
20 years from now, security will be a lot closer to being a solved problem.
> The only way to build secure software is to increase its cost by a factor of 100 or more (think medical and aviation software). No one is going to accept that.
What are you basing that cost on?
> Computer security is impossible at the prices we can afford.
No, it really isn't. There's a reason some organizations have never been hacked and likely never will be. Largely because they have competent people implementing security that very much exists.
<< maintainers of WHOIS tooling are reluctant to scrape such a textual list at runtime, and so it has become the norm to simply hardcode server addresses, populating them at development time by referring to IANA’s list manually. Since the WHOIS server addresses change so infrequently, this is usually an acceptable solution >>
This is the approach taken by whois on Debian.
Years ago I did some hacking on FreeBSD’s whois client, and its approach is to have as little built-in hardcoded knowledge as possible, and instead follow whois referrals. These are only de-facto semi-standard, i.e. they aren’t part of the protocol spec, but most whois servers provide referrals that are fairly easy to parse, and the number of exceptions and workarounds is easier to manage than a huge hardcoded list.
FreeBSD’s whois starts from IANA’s whois server, which is one of the more helpful ones, and it basically solves the problem of finding TLD whois servers. Most of the pain comes from dealing with whois for IP addresses, because some of the RIRs are bad at referrals. There are some issues with weird behaviour from some TLD whois servers, but that’s relatively minor in comparison.
[[ Edited to add: I remembered last time I mentioned these some people got confused. The requirement is a CA must use at least one of the blessed methods, there used to be "Any other method" basically they could do whatever they wanted and that "method" was of course abused beyond belief which is why it's gone. They can do whatever they like in addition, and there are also some (largely not relevant) checks which are always mandatory, but these "blessed methods" are the core of what prevents you from getting a certificate for say the New York Times websites ]]
https://cabforum.org/working-groups/server/baseline-requirem...
The Ten Blessed Methods are listed in section 3.2.2.4 of the Baseline Requirements, there are currently twenty sub-sections corresponding to what the Forum considers distinct methods, the newer ones unsurprisingly are later in the list, although many are retired (no longer permitted for use)
3.2.2.4.2 "Email, Fax, SMS, or Postal Mail to Domain Contact" specifically says to check whois as does 3.2.2.4.15 "Phone Contact with Domain Contact".
For the commercial CAs this is all bad for their bottom line, because a willing customer can't buy their product due to some bureaucratic problem. They want to give you $50, but they can't because some IT bloke needs to update a field in some software. When they ask the IT guy "Hey, can you update this field so I can buy a $50 certificate" the IT guy is going to say "Oh, just use Let's Encrypt" and you don't get $50. So you want to make it as easy as possible to give you $50. Bad for the Internet's Security? Who cares.
ISRG (the Let's Encrypt CA) of course doesn't care about $$$ because the certificates do not cost money, only the provisioning infrastructure costs money, so they only implement 3.2.2.4.7, 3.2.2.4.19 and 3.2.2.4.20 IIRC because those make sense to automate and have reasonable security assuming no bugs.
mobi.whoisserverlist.info. IN CNAME whois.nic.mobi.
org.whoisserverlist.info. IN CNAME whois.publicinterestregistry.org.
Though this relies on registrar publishing their own, and some don't. I meant that some other authority could publish them all, if they are known.
edit: It seems like {tld}.whois-servers.net is exactly that, CNAME to whois servers. Your link mentioned it. Thanks again.
As a result, a whois client needs referral support. The top level IANA whois server has good referral data, so there isn’t much to gain from trying to bypass it.
> While this has been interesting to document and research, we are a little exasperated. Something-something-hopefully-an-LLM-will-solve-all-of-these-problems-something-something.