I’m not being rude, what does it mean to unexpectedly carry cookies? That’s not what I understand the risk of CSRF is.
My understanding is that we want to ensure a POST came from our website and we do so with a double signed HMAC token that is present in the form AND the cookie, which is also tied to the session.
The "unexpected" part is that the browser automatically fills some headers on behalf of the user, that the (malicious) origin server does not have access to. For most headers it's not a problem, but cookies are more sensitive.
The core idea behind the token-based defense is to prove that the origin server had access to the value in the first place such that it could have sent it if the browser didn't add it automatically.
I tend to agree that the inclusion of cookies in cross-site requests is the wrong default. Using same-site fixes the problem at the root.
The general recommendation I saw is to have two cookies. One without same-site for read operations, this allows to gracefully handle users navigating to your site. And a second same-site cookie for state-changing operations.
Right but that's still not really answering his question. Sure, the constant factor is higher for router TCAM memory. Still: you can sum this post up as "in the late 1990s, tier-1 carriers filtered advertisements for all but the 'swamp' range down to /19s or smaller prefixes; now everything is the 'swamp'". Why is that?
Because IPv4 address scarcity means small blocks get sold as they are available to people in completely different parts of the Internet. With IPv6 the address space is so large that they can easily keep the blocks in one piece.
No, obviously, I get that (we buy a lot of IPv4 space --- and I'm actually happier with the current regime than I was with the "supplicate to ARIN" regime). I'm just wondering what technologically happened to make universal /24 advertisements fine. I assume it's just that routers got better.
The transition to 7200 VXRs as core routers really hit a tipping point around 2000. They could handle millions of entries in the FiBs and really led to a relief in pressure. Subsequent devices had to match that.
On the IPv6 side; by 2002, nobody was really experimenting with A6 records any more, and EUI64 was needless. Both were parts of IPv6 designed to facilitate "easy" renumbering, so that single prefixes could be replaced with larger ones. But the ISPs weren't complaining any more about table size.
> I'm just wondering what technologically happened to make universal /24 advertisements fine. I assume it's just that routers got better.
Routers had to get better (more tcam capacity) because there wasn't much choice. Nobody wants to run two border routers each with the table for half the /8s or something terrible like that. And you really can't aggregate /24 announcements when consecutive addresses are unrelated.
I don't have opinions about Matrix (a more-secure version of Discord or IRC seems like a reasonable thing to want) but want to put a word in for reading the Nebuchadnezzar paper, which is kind of a master class in cryptanalyzing secure messaging protocols, and really drives the point home that the hard part of a group secure messaging system isn't encrypting messages (anybody can do that) but rather in securely managing group membership without trusting servers:
I just read through the Matrix protocol documentation, coming to it from never having heard of Matrix before, and I have to say, it is hot garbage, reading like someone with no distributed systems background and hasn’t heard of lamport clocks or virtual synchrony vibe-coded a shonky mashup of IRC and XMPP and then tried to copy-paste Signal’s crypto in the middle. There are early warning signs in which it extensively reinvents endpoint name resolution, by the time you get to the twelfth attempt to build consensus over group state by sorting a DAG you may, like me, realise their entire project is a lost cause.
Matrix for me just went from, “what is this?” to being, “not touching that with a barge pole”. You could probably build yourself a group chat more worthy of trust using NNTP+gnupg and a couple of shell scripts.
I think you're looking at the outcome of attempting to design a secure open federated system for 12 different major kinds of user, not so much a lack of understanding of distsys stuff. The real problem is federation.
Notably, though, very few systems get the group membership problem right; this is a thru-line of secure messaging research results.
Well, you’re a little kinder than me, but I also agree entirely; and notwithstanding that it’s certainly a hard problem, I’d hoped/expected to find end-to-end behaviours at the heart of distributed consensus in a modern protocol, and instead it was “the servers are in charge” all over again, cue disappointed frown.
Is that on theoretical or practical grounds? I would love to learn how you would approach the challenge (no snark). I feel lots of developers miss the needed background, pour in a lot of work and then be stuck with it. How can we avoid that?
Is there some settled science, some principles and patterns in distributed security? Like, you want A, now you can only have option 1 or 2. But if you want B too, this only leaves you with option 2, provided you satisfy D too. But the combo D+B rules out any E.
No, there's no science to it at all; it's just a collective action problem. You saw it in Matrix's effort to get all their clients encrypted by default (they were hamstrung by an installed base of popular clients that didn't work that way), and again in the response to Nebuchadnezzar.
That sounds like a social problem again. What foundational materials would you recommend to read though for anyone trying to build something secure and non-centralized? It is a pity that everyone spends a lot of effort in this area, only to learn they did it wrong and having to deal with unfortunate design decisions. That is, if they are honest about it.
You can build secure and noncentralized! What you can't do is build secure and federated, where everyone lives in a shared, broadly reachable namespace comprised of independently operated instances.
I simply wouldn't build a secure group message system to begin with. It's a treacherously hard problem and the very few people who have done it well accomplished that with major UX compromises that put them at long-term disadvantage against schlock like Telegram, and survived mostly due to force-of-nature word of mouth.
If you're going to try, and you want to be rigorous about it, I'd say you need to start by reading the whole history of cryptanalyses of secure messaging systems, even systems you don't care about. Read the papers carefully and work out the attacks for yourself. It's a little like math in that you're only going to figure it out by actually working the examples yourself.
Perhaps you put your finger on it before, in that given the current state-of-the-art, the range of needs is simply too diverse to be met by a single paradigm. Nevertheless I still retain that hope, being disappointed by one effort didn’t break my faith in progress.
I think it's hard to overestimate how much Matrix is doing this on hard mode, in circumstances where they can't iterate or clean things up as they go, because they deliberately set themselves up to have a heterogenous installed base almost from the jump. Seen in that light, what else could they end up with but a ball of mud? Since I think that's basically priced in, I think the right thing to do is try to read between the lines and home in on the "good parts" of the design, rather than reflexively rejecting the whole thing because there are "bad parts" they'll never be rid of.
That, or adopt a "nothing federated can be good" stance. I'm sympathetic to that!
Trying to build a secure system on top of email is a waste of time and energy. Even if you succeeded, it would only be by compromising all the things that make email useful.
reply