06 May, 2011, avidal wrote in the 41st comment:
Votes: 0
David Haley said:
Let's say I'm a malicious user and I want to screw with your server. So I set up some proxy that I control, and it talks to you, and using your secure magic, you believe that I am in fact talking to you. So great – now I can screw with you, while you believe it's truly me.


In order for you, as a malicious user, to speak to my server as if you were a proxy, and for me to trust you, you and I would need to communicate before hand so that I can give you a secret key that I will accept. I would not issue a key to you on a whim. The onus is on the server administrator to not issue keys to anyone that asks.

The alternative (and much more likely) situation is that proxy administrators will setup control panels that a MUD administrator can connect to and add their MUD to the list. They would also have the option of getting a secret key. The MUD administrator would then add the proxies UUID and secret key to its list of trusted proxies.

In other words, BOTH parties must communicate directly, out-of-band (not through telnet) to exchange these keys.

David Haley said:
Nothing here has given you trust, from a technical perspective, that the proxy is telling you the truth about its clients.

What you have accomplished is that you can uniquely identify a proxy, even if its IP address changes, based on its keys etc.


No, there's no trust from a technical perspective that the proxy isn't lying to you. There's nothing that can be done about that without some extreme changes to all three parties (clients, proxies, and servers).

However, like I said above, the trust would come from the two parties directly interacting beforehand. If you think TMC is going to lie to you about the client, then don't issue a key (or remove the key you have issued).
06 May, 2011, Twisol wrote in the 42nd comment:
Votes: 0
David Haley said:
Why? Why would anything other than this sort of proxy or a client connect to the MUD? Why do you care?

Let's say I'm a malicious user and I want to screw with your server. So I set up some proxy that I control, and it talks to you, and using your secure magic, you believe that I am in fact talking to you. So great – now I can screw with you, while you believe it's truly me.

And then the MUD either bans the IP it was falsely given, or the proxy the user is masquerading as.

David Haley said:
So why should I bother going through all this MITM stuff when I can do this directly? If I wanted to do MITM, why not do it on the normal telnet connections?

You missed where avidal said that the MITM protection is a red herring. It's good and it's there, but it's not the point of the protocol. The point of the security is to give you confidence that you're granting access only to those who are allowed to use this feature. It's your responsibility who you give access to, and you can easily revoke access. But the point is to give confidence to the authorization.

David Haley said:
In other words, what problem are you solving that you have introduced with this proxy, that is a problem we actually care about for normal connections in the first place?

Um, IP masking. Some MUDs (I think Kayle said his does this a while back? might have the name wrong) even autoban/kick if it receives two connections from the same IP. The IP is widely used by MUD administrators for controlling abusive players. An advanced client that works as a proxy is probably something you don't want to ban. (If you could care less about supporting a proxy client, this obviously isn't for you.) So this gives the missing information back to the MUD.

David Haley said:
Nothing here has given you trust, from a technical perspective, that the proxy is telling you the truth about its clients.

What you have accomplished is that you can uniquely identify a proxy, even if its IP address changes, based on its keys etc.

And that's precisely the point. I don't understand how that's so confusing.
06 May, 2011, avidal wrote in the 43rd comment:
Votes: 0
By the way, I updated the draft to hopefully clarify a few things. I've removed the part about the proxy address being required for signed messages, combined KEYNOTFOUND and REVOKED into a single UNAUTHORIZED response, and added a couple of FAQ entries (Why not roll it into another protocol; Why not embed the signature into the data)

You can view the draft here: https://github.com/avidal/mud-proxy-prot...

You can view a list of all of the changes here: https://github.com/avidal/mud-proxy-prot...
06 May, 2011, David Haley wrote in the 44th comment:
Votes: 0
avidal said:
In order for you, as a malicious user, to speak to my server as if you were a proxy, and for me to trust you, you and I would need to communicate before hand so that I can give you a secret key that I will accept. I would not issue a key to you on a whim. The onus is on the server administrator to not issue keys to anyone that asks.

If the higher-level goal here is for these clients to work with MUD servers easily and universally, isn't this an onerous requirement?

Now, if I want to my server to talk to these proxies, not only do I have to implement this protocol, but I also need some way of dealing with requests from web-based clients. Either I do that by adding my MUD to the client, or doing it myself – the point is, I have to do a fair bit of work just to get this system working.

Nobody has answered why we care so much about this security problem, when we care so very little about the same problem for standard clients.

It strikes me as quite sufficient to trust by default (generate and give a key), with the option of revoking the key later.
EDIT: yes, I realize that a determined attacker could put their proxy on a different IP and start the process again. But this is the case no matter what client is trying to get around a ban. In other words, we are maintaining the same level of security.

avidal said:
There's nothing that can be done about that without some extreme changes to all three parties (clients, proxies, and servers).

The changes are hardly extreme, it's just that they'd require client-side changes, which defeats the point of this exercise.

Twisol said:
Um, IP masking.

Um, I'm not stupid. :rolleyes: Assuming that I'm asking stupid questions is not useful. That's the point of having a proxy that can communicate to a MUD what IP the sub-connections are using. This is obvious. The question was with respect to all this extra security being put in place.

You actually haven't solved IP masking, because the proxy can, uh, mask the IPs of its clients.

Twisol said:
And that's precisely the point. I don't understand how that's so confusing.

It's not confusing, it's just, uh, missing the point. :smile:

For example…
Twisol said:
The point of the security is to give you confidence that you're granting access only to those who are allowed to use this feature.

This point has been missed, because you have no trust that the people behind the proxy are who the proxy says they are.

In other words, the only confidence you have is that the proxy is the same no matter which IP the proxy is coming from. How this confidence extends to the proxy's clients is unclear.
06 May, 2011, Tonitrus wrote in the 45th comment:
Votes: 0
I believe the point of this protocol is to allow proxies to attempt to identify individual users so that an administrator can attempt to ban individual users instead of banning the whole proxy.

This seems useful.

Will it stop anyone with the knowledge and determination to break it? No. Neither will the lock on your door, but it's still a good idea to have one.

[Edit: To avoid later quibbling, I'm not comparing this protocol to a lock on a door. I'm stating that everything fails under certain conditions, and that doesn't necessarily make it useless.]
06 May, 2011, David Haley wrote in the 46th comment:
Votes: 0
Tonitrus said:
I believe the point of this protocol is to allow proxies to attempt to identify individual users so that an administrator can attempt to ban individual users instead of banning the whole proxy.

This seems useful.

Will it stop anyone with the knowledge and determination to break it? No. Neither will the lock on your door, but it's still a good idea to have one.

Yes, this is completely true, and a good goal. In case this was directed at me, nothing I said has been disagreeing with this mission statement.
06 May, 2011, avidal wrote in the 47th comment:
Votes: 0
David Haley said:
If the higher-level goal here is for these clients to work with MUD servers easily and universally, isn't this an onerous requirement?

Now, if I want to my server to talk to these proxies, not only do I have to implement this protocol, but I also need some way of dealing with requests from web-based clients. Either I do that by adding my MUD to the client, or doing it myself – the point is, I have to do a fair bit of work just to get this system working.

Nobody has answered why we care so much about this security problem, when we care so very little about the same problem for standard clients.

It strikes me as quite sufficient to trust by default (generate and give a key), with the option of revoking the key later.
EDIT: yes, I realize that a determined attacker could put their proxy on a different IP and start the process again. But this is the case no matter what client is trying to get around a ban. In other words, we are maintaining the same level of security.


This particular proposal does not involve you having to add support to handle requests from web-based clients at all. That's what the proxy exists for. The proxy is the one able to handle those requests, and it translates this into a regular telnet stream to your MUD server. If you decide that you want to directly support web-based clients, then by all means go for it.

If you choose to trust by default and implement a system whereby anyone that wants to run a proxy server that connects to your MUD can get a key, go for it. That's your choice.

You, as a MUD administrator, would only need to support this proposal if you want to know who is connecting to you through a proxy. There is no way to be absolutely certain that the proxy is not lying, but that's the nature of the game. Like I said, if you want to trust by default then its on you. Personally, I'd much rather issue keys to trusted proxy servers (or receive a key from a trusted proxy server).

Again, it's no guarantee that the proxy won't lie, but you have much more fine-control using a proposal like this. If you think the proxy is lying, then remove the key and ban the proxy IP if you choose. You'll be in the same situation you're in now but only with that specific proxy. If you have keys for other proxies, you'll still have much more visibility.

The saner solution is for those people that run proxy servers to provide a control panel for a MUD administrator to list their MUD as an officially supported MUD, which also allows them to obtain the proxy UUID and have a secret key generated for them. It minimizes the amount of work required on the MUD administrator this way.
06 May, 2011, David Haley wrote in the 48th comment:
Votes: 0
avidal said:
This particular proposal does not involve you having to add support to handle requests from web-based clients at all. That's what the proxy exists for. The proxy is the one able to handle those requests, and it translates this into a regular telnet stream to your MUD server. If you decide that you want to directly support web-based clients, then by all means go for it.

I thought that the whole point here was that many of these web-based clients use proxies to gather connections and forward them on to the target MUD.

avidal said:
There is no way to be absolutely certain that the proxy is not lying, but that's the nature of the game. Like I said, if you want to trust by default then its on you. Personally, I'd much rather issue keys to trusted proxy servers (or receive a key from a trusted proxy server).

But the whole point here is that by issuing your key, you haven't actually solved this particular problem about the proxy lying. I'm not sure why you (and Twisol) are juxtaposing these two notions, because they are entirely separate problems: one, trusting that the proxy is who it says it is. Two, trusting that the proxy's clients are who the proxy says they are. Establishing trust for (1) changes nothing for (2).

avidal said:
The saner solution is for those people that run proxy servers to provide a control panel for a MUD administrator to list their MUD as an officially supported MUD, which also allows them to obtain the proxy UUID and have a secret key generated for them. It minimizes the amount of work required on the MUD administrator this way.

Well, you'd still need some kind of central repository etc., but that's not onerous on the MUD admin, sure.
06 May, 2011, Twisol wrote in the 49th comment:
Votes: 0
David Haley said:
If the higher-level goal here is for these clients to work with MUD servers easily and universally, isn't this an onerous requirement?

No. The alternative is an open proxy, also known as the scourge of the earth, the black menace, and the killer of kittens. Thus, I need permission to connect my proxy to a MUD. It's not so hard to exchange a secret key at that time.

David Haley said:
Now, if I want to my server to talk to these proxies, not only do I have to implement this protocol, but I also need some way of dealing with requests from web-based clients. Either I do that by adding my MUD to the client, or doing it myself – the point is, I have to do a fair bit of work just to get this system working.

You have to do the code, which is unavoidable (you need a mechanism to accept the IP from somewhere else, period, no matter what the mechanism actually is). And you have to tell the proxy client it's OK to connect and exchange a secret key.

I don't know what you mean by "requests from web-based clients". The proxy hides that from you. The proxy is just another Telnet-speaking machine. The proxy hides IPs, and it wants to help you by giving you what it knows. You can accept the offer, or not accept the offer. I, at least, will be supporting a reasonable number of ways to provide the IP, so this isn't the only mechanism. I do think it's the best way to date, because it's only accessible to those you allow.

David Haley said:
Nobody has answered why we care so much about this security problem, when we care so very little about the same problem for standard clients.


Because standard clients already give you the user's IP directly due to how sockets work. Proxies hide that, hence proxies want to pass it along. Opening a hole for anyone to provide a different IP isn't very good, so some kind of protection is needed. That's what we have here.

David Haley said:
It strikes me as quite sufficient to trust by default (generate and give a key), with the option of revoking the key later.

EDIT: yes, I realize that a determined attacker could put their proxy on a different IP and start the process again. But this is the case no matter what client is trying to get around a ban. In other words, we are maintaining the same level of security.

Wait, "by default"? How is the key provided? How do you know who doesn't already have a key? How many keys do you have to track? Is revoking a key then synonymous with banning an IP? Presumably that IP won't be allowed to get another key.

Seems like a lot of baggage when you could just register with the client and get your credentials. Have you ever used AWS S3? I have, and it works quite nicely.

David Haley said:
Twisol said:
Um, IP masking.

Um, I'm not stupid. :rolleyes: Assuming that I'm asking stupid questions is not useful. That's the point of having a proxy that can communicate to a MUD what IP the sub-connections are using. This is obvious. The question was with respect to all this extra security being put in place.

You actually haven't solved IP masking, because the proxy can, uh, mask the IPs of its clients.

We've solved unintentional IP masking. Intentional IP masking is just as much a problem as it ever was, and it's totally out of scope for this proposal.

David Haley said:
Twisol said:
And that's precisely the point. I don't understand how that's so confusing.

It's not confusing, it's just, uh, missing the point. :smile:

For example…
Twisol said:
The point of the security is to give you confidence that you're granting access only to those who are allowed to use this feature.

This point has been missed, because you have no trust that the people behind the proxy are who the proxy says they are.

We never had that kind of trust, see above.

David Haley said:
In other words, the only confidence you have is that the proxy is the same no matter which IP the proxy is coming from. How this confidence extends to the proxy's clients is unclear.

You can be confident that you're talking to someone who you've authorized to provide a replacement IP. That's the only thing we're trying to do here.

Also, IPs are not constant, etc. etc. It's much more reliable to use unique secret keys that the proxy can utilize, and we'll know it's the proxy by virtue of knowing the secret key. You don't want the secret key itself advertised over the wire, so you hash the data and send it as a signature. The data isn't sensitive enough to warrant transport-level security, so that can be sent plain.
06 May, 2011, Kayle wrote in the 50th comment:
Votes: 0
Twisol said:
David Haley said:
In other words, what problem are you solving that you have introduced with this proxy, that is a problem we actually care about for normal connections in the first place?

Um, IP masking. Some MUDs (I think Kayle said his does this a while back? might have the name wrong) even autoban/kick if it receives two connections from the same IP. The IP is widely used by MUD administrators for controlling abusive players. An advanced client that works as a proxy is probably something you don't want to ban. (If you could care less about supporting a proxy client, this obviously isn't for you.) So this gives the missing information back to the MUD.


I think you have me confused with someone else. All my MUD will do is only allow one person from a given connection to leave designated safe zones at a time.
06 May, 2011, avidal wrote in the 51st comment:
Votes: 0
David Haley said:
I thought that the whole point here was that many of these web-based clients use proxies to gather connections and forward them on to the target MUD.


Yes, the web-based clients use proxies to gather connections and forward them to the target MUD. But the only reason the proxy exists is so that it can accept websocket/flash socket connections and translate them into regular telnet streams so that they can connect to MUDs without the MUD having to explicitly support those websocket/flash connections themselves.

If the server supported those types of connections, there would be no need for the proxy to exist.

David Haley said:
But the whole point here is that by issuing your key, you haven't actually solved this particular problem about the proxy lying. I'm not sure why you (and Twisol) are juxtaposing these two notions, because they are entirely separate problems: one, trusting that the proxy is who it says it is. Two, trusting that the proxy's clients are who the proxy says they are. Establishing trust for (1) changes nothing for (2).


I understand that they are two separate problems, and solving one does not imply the other is solved. What I'm trying to propose is a system whereby issue (1) is addressed. I don't know what the answer is to solve (2), but I do know that it is out of the scope of this proposal. The only point I'm trying to make is that we currently cannot trust that the client IP is correct even on a direct connection, but we do it anyway because there are no better alternatives (while still allowing connections from every client out there).

David Haley said:
Well, you'd still need some kind of central repository etc., but that's not onerous on the MUD admin, sure.


You mean the MUD admin needs a repository? True. They would need a configuration file or some such where they can store the mapping of secret key to proxy UUID for lookup purposes. However, there doesn't need to be a central repository that all proxies and MUD servers access.
06 May, 2011, Twisol wrote in the 52nd comment:
Votes: 0
David Haley said:
I thought that the whole point here was that many of these web-based clients use proxies to gather connections and forward them on to the target MUD.

That's hidden from you though. You don't need to know that it's a web-based user (though perhaps an MDSP variable could be created for that kind of thing). The proxy translates between whatever protocol the web end uses and Telnet.

David Haley said:
But the whole point here is that by issuing your key, you haven't actually solved this particular problem about the proxy lying. I'm not sure why you (and Twisol) are juxtaposing these two notions, because they are entirely separate problems: one, trusting that the proxy is who it says it is. Two, trusting that the proxy's clients are who the proxy says they are. Establishing trust for (1) changes nothing for (2).

(2) already exists without using a proxy client. We don't want to fix that. It's out of scope. (1) is introduced by proxy clients, hence we're fixing it.

David Haley said:
Well, you'd still need some kind of central repository etc., but that's not onerous on the MUD admin, sure.

The MUD can simply keep, say, a map<UUID, secret_key>. The proxy simply keeps a map<MUD, secret_key>. I don't think that's too much to ask, considering that you'd have to code a mechanism of some kind in no matter what you do.

(Yes, yes, I know std::map is C++. It's an example.)

EDIT:

Kayle said:
I think you have me confused with someone else. All my MUD will do is only allow one person from a given connection to leave designated safe zones at a time.

Ah, yeah, that's what I meant. :) It -was- you, then, I just had the mechanism wrong.
06 May, 2011, Kayle wrote in the 53rd comment:
Votes: 0
Now that I've finished reading all of this, I'm actually very much a fan of this as it will allow me to use things like Aspect without fear of screwing over players because of my multiplay restrictions.
06 May, 2011, avidal wrote in the 54th comment:
Votes: 0
Kayle said:
I think you have me confused with someone else. All my MUD will do is only allow one person from a given connection to leave designated safe zones at a time.


So if you have two players connected from TMS or mudgamers, this restriction applies I assume? If TMS or mudgamers implemented this protocol, would you still use the TMS/mudgamers IP to determine this restriction, or would you then use the relayed IP address that they send you?
06 May, 2011, David Haley wrote in the 55th comment:
Votes: 0
Twisol said:
Because standard clients already give you the user's IP directly due to how sockets work. Proxies hide that, hence proxies want to pass it along. Opening a hole for anyone to provide a different IP isn't very good, so some kind of protection is needed. That's what we have here.

No, it is not. The proxy can lie.

Twisol said:
Seems like a lot of baggage when you could just register with the client and get your credentials

So as a MUD dev, I now have to go worrying about these clients just so people can connect to my game with them.

Think about how this will work in practice. Do you really think MUD admins will be so careful with who they trust? Perhaps in practice there just won't be a lot of such proxies. But is everybody so security conscious as you think?

Twisol said:
We've solved unintentional IP masking.

Yes. Piling on all of this extra security in the name of trust is a red herring because you're not speaking to the core mission statement.

The core mission statement is very valuable. Adding on all these extra layers in the same of extra security seems excessive, and doesn't actually solve the security issue; it just pushes it around like peas on a plate, really.
06 May, 2011, Kayle wrote in the 56th comment:
Votes: 0
avidal said:
Kayle said:
I think you have me confused with someone else. All my MUD will do is only allow one person from a given connection to leave designated safe zones at a time.


So if you have two players connected from TMS or mudgamers, this restriction applies I assume? If TMS or mudgamers implemented this protocol, would you still use the TMS/mudgamers IP to determine this restriction, or would you then use the relayed IP address that they send you?


Under current circumstances, yes, it would affect them, but once this is fleshed out in its entirety, and they start using it, then I would use the relayed IP address instead of the Mudgamers/TMC one.
06 May, 2011, Twisol wrote in the 57th comment:
Votes: 0
David Haley said:
No, it is not. The proxy can lie.

Anyone can lie, with or without a proxy client. That's not our problem.

David Haley said:
Twisol said:
Seems like a lot of baggage when you could just register with the client and get your credentials

So as a MUD dev, I now have to go worrying about these clients just so people can connect to my game with them.

Think about how this will work in practice. Do you really think MUD admins will be so careful with who they trust? Perhaps in practice there just won't be a lot of such proxies. But is everybody so security conscious as you think?

No, I don't think so. But I'm not about to let someone connect to an arbitrary host from my proxy and get me in trouble for what they did. I'm protecting myself by requiring MUD admins to register with me. This is required, non-negotiable, done.

David Haley said:
Twisol said:
We've solved unintentional IP masking.

Yes. Piling on all of this extra security in the name of trust is a red herring because you're not speaking to the core mission statement.

The core mission statement is very valuable. Adding on all these extra layers in the same of extra security seems excessive, and doesn't actually solve the security issue; it just pushes it around like peas on a plate, really.

How is this extra layers? Look, do you want me to just implement this and show you the code? It's really simple. >:|
06 May, 2011, David Haley wrote in the 58th comment:
Votes: 0
In the end of the day, as long as it is crystal clear that this establishes nothing when it comes to trusting clients behind the proxy, that's what matters. A lot of talk here has been about how all this security fixes these problems, and, well, it really doesn't. It addresses one very specific problem, which is whether the proxy is who it says it is.

Making it sound like there is a bunch of security is not only false, it's dangerous.

Again, I'm not dumb. This isn't a question of code complexity, but of security perception. The perception of security can be worse than an obvious lack of security (where that lack is something we already deal with and are happy with).

Twisol said:
I'm protecting myself by requiring MUD admins to register with me. This is required, non-negotiable, done.

Sure, if you want. You've just increased the entrance barrier for your client, and made me (as a MUD admin) care about something I shouldn't really have to care about, which is people connecting from some client I've potentially never heard of. Whether or not you are ok with that is of course your decision, but this is not a policy that should be forced on everybody.
06 May, 2011, Twisol wrote in the 59th comment:
Votes: 0
David Haley said:
In the end of the day, as long as it is crystal clear that this establishes nothing when it comes to trusting clients behind the proxy, that's what matters. A lot of talk here has been about how all this security fixes these problems, and, well, it really doesn't. It addresses one very specific problem, which is whether the proxy is who it says it is.

Making it sound like there is a bunch of security is not only false, it's dangerous.

If I ever gave the impression that it was supposed to do anything beyond allow specific people to give you replacement IPs, I apologize.

David Haley said:
Twisol said:
I'm protecting myself by requiring MUD admins to register with me. This is required, non-negotiable, done.

Sure, if you want. You've just increased the entrance barrier for your client, and made me (as a MUD admin) care about something I shouldn't really have to care about, which is people connecting from some client I've potentially never heard of. Whether or not you are ok with that is of course your decision, but this is not a policy that should be forced on everybody.

The alternative is an open proxy. IP forwarding is irrelevant here: I'm not allowing people to connect to arbitrary hosts through my client. And I won't just allow any-odd MUD I discover because that also imposes on MUDs that disallow multiplaying. So yes, a MUD will need to give me permission to connect to it. If you have any better ideas I'm all ears, but it can't be an open proxy.
06 May, 2011, Dean wrote in the 60th comment:
Votes: 0
Like Kayle, I think this is a good idea.

There have been several cases now where we've had players come in via the TMC or MUDgamers client to cause trouble and ultimately had to ban the proxy for a period of time. Not a decision made lightly given that we do get a few legitimate people using them from time to time but relayed IPs would help with this particular scenario.
40.0/81