This brings a disturbing thought to mind… if an instance domain name like foo.bar lapses and someone else snaps the domain up (or of it gets stolen) can the new controller plop Lemmy on a server and be instantly federated? If so what kind of damage could they do?
So looking at that spec… Nothing there is validation that current messages originate from an “original” server…
I don’t think either of these signature options for Server to Server communications means that my current lemmy.saik0.com instance can’t be torn down (delete LXC container) and reconfigured as a brand new instance (New LXC container) and other instances wouldn’t know that there’s been a change to the instance running here… or more accurately would flag a change. I think these signatures are all about not being able to spoof OTHER instances. eg, lemmy.ml can’t send messages on behalf of lemmy.world.
I assumed that once federated the public key would be remembered and signatures that do not match it would be handled, but you may be correct. I do wonder whether this could be a problem as instances close down over time. I’ll have to spend some more time researching to see if there’s a more clear answer, or if any ActivityPub implementations have their own way of handling that situation.
Yeah that’s my worry. I’m pretty sure(and could be wrong) that message/ keys are only checked on ingestion. So i would get key value for a message coming in and can check that is currently valid, not that it’s “changed” since 2 months back. I think this could allow for some one to ressurrect an old Lemmy service and masquerade as the old one… communities , users… all of it.
ICANN has an Expired Registration Recovery Policy (ERRP) that requires your registrar to give your domain a 30-day grace period before deleting the records. ERRP also requires them to shutdown your DNS resolutions 8 days before deletion.
You’d have to be really mismanaging your domain if you miss all the required email reminders and don’t notice your domain has been non functional for a couple of days.
This is why you don’t let your domain registration lapse. It’s not the only way computers on the internet verify each other’s identity, but a hell of a lot of internet security features are based around domain names, so keeping yours functioning is a very big deal.
Domain registration ≠ internet security. Root of trust is in cryptographic keys, not domains. DNS is not the security cornerstone you make it out to be. PKI says hi!
Consider how many system relies on being able to send you an email for verifying your login and performing password reset. Those who have control over your email address domain can trigger password reset for most of online services out there. Imagine if Google forgot to renew gmail.com and it falls to a wrong hands.
Email is tied to domains. TLS is tied to domains. CORS is tied to domains. OAuth is tied to domains. Those are just four things I can think of while half asleep. Here’s one recent example of how screwing up a domain name is enough by itself to cause a security breach.
Cryptography is not security any more than domain names are; both are facets of how security is implemented but there’s no one system that makes the Internet secure.
Yes, but it is very quick and cheap to get a domain validated cert from a CA that is generally trusted by most web browsers, so once the bad actor has the domain, the should be able to trick most users, only maybe certificate pinning might help, but that is not widely used.
This brings a disturbing thought to mind… if an instance domain name like foo.bar lapses and someone else snaps the domain up (or of it gets stolen) can the new controller plop Lemmy on a server and be instantly federated? If so what kind of damage could they do?
No, the signatures wouldn’t match.
That’s an assumption that lemmy will quit federating with a server that does not match.
And what signature are we talking about anyway? Is not certificates…
Activitypub signatures that each user and group sends out their messages with.
It’s not an assumption, it’s how activitypub works.
Can you show me documentation that shows communities or servers are signed?
https://www.w3.org/wiki/SocialCG/ActivityPub/Authentication_Authorization
So looking at that spec… Nothing there is validation that current messages originate from an “original” server…
I don’t think either of these signature options for Server to Server communications means that my current lemmy.saik0.com instance can’t be torn down (delete LXC container) and reconfigured as a brand new instance (New LXC container) and other instances wouldn’t know that there’s been a change to the instance running here… or more accurately would flag a change. I think these signatures are all about not being able to spoof OTHER instances. eg, lemmy.ml can’t send messages on behalf of lemmy.world.
I assumed that once federated the public key would be remembered and signatures that do not match it would be handled, but you may be correct. I do wonder whether this could be a problem as instances close down over time. I’ll have to spend some more time researching to see if there’s a more clear answer, or if any ActivityPub implementations have their own way of handling that situation.
Yeah that’s my worry. I’m pretty sure(and could be wrong) that message/ keys are only checked on ingestion. So i would get key value for a message coming in and can check that is currently valid, not that it’s “changed” since 2 months back. I think this could allow for some one to ressurrect an old Lemmy service and masquerade as the old one… communities , users… all of it.
ICANN has an Expired Registration Recovery Policy (ERRP) that requires your registrar to give your domain a 30-day grace period before deleting the records. ERRP also requires them to shutdown your DNS resolutions 8 days before deletion.
You’d have to be really mismanaging your domain if you miss all the required email reminders and don’t notice your domain has been non functional for a couple of days.
I think Microsoft and Google have both done it, but what do they know? 🤣
Oh really? Haven’t heard that one, back in the day or something?
Yeah some dude bought the google.com domain via some glitch a while back. Here’s a story about it.
Awesome lol
Yup. Microsoft let hotmail lapse once. Someone paid for the renewal for them. https://slashdot.org/story/00/01/18/1645224/microsoft-hotmail-domain-reward-check-on-ebay
This is why you don’t let your domain registration lapse. It’s not the only way computers on the internet verify each other’s identity, but a hell of a lot of internet security features are based around domain names, so keeping yours functioning is a very big deal.
Domain registration ≠ internet security. Root of trust is in cryptographic keys, not domains. DNS is not the security cornerstone you make it out to be. PKI says hi!
Consider how many system relies on being able to send you an email for verifying your login and performing password reset. Those who have control over your email address domain can trigger password reset for most of online services out there. Imagine if Google forgot to renew gmail.com and it falls to a wrong hands.
Email is tied to domains. TLS is tied to domains. CORS is tied to domains. OAuth is tied to domains. Those are just four things I can think of while half asleep. Here’s one recent example of how screwing up a domain name is enough by itself to cause a security breach.
Cryptography is not security any more than domain names are; both are facets of how security is implemented but there’s no one system that makes the Internet secure.
Yes, but it is very quick and cheap to get a domain validated cert from a CA that is generally trusted by most web browsers, so once the bad actor has the domain, the should be able to trick most users, only maybe certificate pinning might help, but that is not widely used.