06 May, 2011, avidal wrote in the 21st comment:
Votes: 0
Wow, lots of replies. I need to go to bed, but I'll try to address this one comment from Scandum now, and look over the rest again tomorrow.

Scandum said:
Twisol said:
Scandum said:
As there's no way for a 3rd party to snoop the data a plain text password would suffice for proxies with a user accessible telnet interface.

Replay attacks are actually very easy to accomplish. All you need is the data being sent to the server, and you can send that exact data from your own computer. Including a timestamp in the data (and signing it) ensures that replay attacks are infeasible.

Assuming the setup is as following:
[browser] <———-> [mud proxy] <———> [mud server]

How will the browser intercept data sent between the proxy and the server? No interception, no replay.


The browser isn't going to snoop anything. This is protection against MITM attacks which, while relatively rare (and even more so in the world of text-based MUDs), can and do happen.

By signing messages, you can trust that the message came from who you expected it to come from, and even if someone sits in the middle and snoops the traffic, there's nothing they can do without -also- getting a hold of the secret key.

The intention of this protocol is not 100% uncrackable robust security. It was created, and exists, to fill one purpose: a moderately secure method for a proxy to send data (and perhaps receive back, as the protocol evolves) to a MUD server, and for the MUD server to be able to reasonably trust that the data they got was from who they expected.

There is absolutely no way that I know of to solve the problem of IP masking by using a proxy server without having some explicit communication between the proxy and the MUD. And there's absolutely no way to rely on the information from the proxy server without having some sort of signature/authentication method. This approach solves both problems while introducing a minimal amount of work on either party.
06 May, 2011, avidal wrote in the 22nd comment:
Votes: 0
Also, quickly, as was said before: It is not feasible to roll this communication as a data packet into another protocol. Let's say it's added to MCDP (or whatever KaVir referenced on page 1) or GMCP. This means that the proxy would have to negotiate to enable the protocol, it would need to do deep inspection of all communication to see if it's something the proxy itself cares about, discarding or modifying accordingly. Basically exactly as Stendec said.

Plus, this is strictly for proxy <-> server communication and has no place being shoved into a client <-> server protocol which serves entirely different purposes.

Serializing the signature as part of the actual data object is also infeasible for the reasons Twisol mentioned. The first draft actually did exactly that, but then I realized that if we did that, it would require the receiving party to deserialize the data object, extract the signature, reserialize the data object according to a very specific and strict set of rules, then regenerate the signature. I'm sure you can all see where that plan starts to fall apart (hint: it's around the part where you have to reserialize according to a very specific and strict set of rules). By separating the signature and the data object, the receiving party can simple regenerate the signature using the already serialized string that they received.
06 May, 2011, Scandum wrote in the 23rd comment:
Votes: 0
avidal said:
The browser isn't going to snoop anything. This is protection against MITM attacks which, while relatively rare (and even more so in the world of text-based MUDs), can and do happen.

It may be difficult to convince MUD servers they need to implement data encryption in case someone wants to engage in a MITM attack (with no practical (as of yet) example of how such an attack could be carried out) in order to prevent multiplaying.

All that's needed from a pragmatic perspective is a simple client IP exchange, with the server subsequently comparing its ban lists to both IPs. Someone can submit a fake IP, but assuming the server favors non proxy connections there is no real potential for abuse as it'd disconnect the proxy for multi-playing rather than the direct connection.

Another pragmatic implementation would be the proxy initiating telnet MSSP, checking for "MULTIPLAYING" == "None", and disallowing multiple connections when that's the case.
06 May, 2011, Twisol wrote in the 24th comment:
Votes: 0
Scandum said:
It may be difficult to convince MUD servers they need to implement data encryption in case someone wants to engage in a MITM attack (with no practical (as of yet) example of how such an attack could be carried out) in order to prevent multiplaying.

The data isn't encrypted. It's hashed, and this hash is sent alongside the data as the signature. When you receive the data, you hash the data again using your copy of the secret key and compare.

As for examples…. um, MITM attacks aren't specific to HTTP or Telnet or anything else. It's simply the injection of one party between two others. Every routing node between the client and the server is effectively a man in the middle; the difference is that (ostensibly) they're not trying to attack us.

Scandum said:
Another pragmatic implementation would be the proxy initiating telnet MSSP, checking for "MULTIPLAYING" == "None", and disallowing multiple connections when that's the case.

This puts the onus of action on the proxy instead of the MUD server. A malicious proxy is free to ignore the directive if they want. The MUD should be responsible for managing multiplayers, and the proxy only needs to give the MUD the information to do so effectively.
06 May, 2011, quixadhal wrote in the 25th comment:
Votes: 0
Ah, if only we had some protocol that allowed for unique identification of both client and server by a generated public key pair, making NO assumptions about IP addresses or anything else which can be spoofed, or which may not be a one-to-one mapping.

Oh wait. We do. It's called SSL.

The proxy could authenticate against the server, which would only accept a connecting that negotiates a trusted key. The clients could authenticate against the proxy, which would accept any key and forward said key on to the server to allow IT to decide to accept the connection or not.

Oh but wait. We have to support TELNET clients from 1812, since nobody would be willing to just download a custom client to play a game. That's absurd and never happens in this day and age. Nevermind.
06 May, 2011, David Haley wrote in the 26th comment:
Votes: 0
Quote
or even run behind DHCP

ITYM NAT, no?
06 May, 2011, Twisol wrote in the 27th comment:
Votes: 0
Well… no. NAT hides the multiple machines behind a single IP, and uses DHCP to assign the internal machines IPs in the internal-use range (i.e. 192.168.*.*). It can assign public IPs though, which is why I said DHCP: a machine could be given a new IP in the future if it's configured to accept its IP via DHCP.
06 May, 2011, David Haley wrote in the 28th comment:
Votes: 0
Ah, sorry, I thought we were talking about how proxies hide client IP addresses (which is the effect NAT has) – must have read too quickly. Never mind. :smile:
06 May, 2011, Arynth wrote in the 29th comment:
Votes: 0
I've read the document posted and the comments here, and I have one quick question: if this protocol is supposed to be strictly proxy <–> server communication, wouldn't that mean that the proxy still had to process the stream of data going to the client, and parse out this option before sending it on to the client? I thought not using MSDP or something else was meant to avoid doing that…

In the least, it would have to inject information into the clients stream to go to the server, and then either ignore any responses (meaning the client would get them and need to ignore them), or do as I said above.
06 May, 2011, avidal wrote in the 30th comment:
Votes: 0
Arynth said:
I've read the document posted and the comments here, and I have one quick question: if this protocol is supposed to be strictly proxy <–> server communication, wouldn't that mean that the proxy still had to process the stream of data going to the client, and parse out this option before sending it on to the client? I thought not using MSDP or something else was meant to avoid doing that…

In the least, it would have to inject information into the clients stream to go to the server, and then either ignore any responses (meaning the client would get them and need to ignore them), or do as I said above.


You're right in that it still needs to inspect the stream, but there is a significantly less amount of work required with a new protocol. The proxy needs to do nothing but search for IAC DO|DONT|WILL|WONT|SB MPCP/PROXY. If that's not found, then just forward to the client. If it is found, check the data, process it, then remove it from the stream going to the client.
06 May, 2011, avidal wrote in the 31st comment:
Votes: 0
quixadhal said:
Oh but wait. We have to support TELNET clients from 1812, since nobody would be willing to just download a custom client to play a game. That's absurd and never happens in this day and age. Nevermind.


And how long do you think it'll be before every MUD server provides a custom client and blocks connections from everywhere except that custom client? 10 years? 20?

The fact of the matter is that this is a very real problem that exists right this minute, for nearly everyone that plays from (and servers that accept connections from) MudGamers, TMC and Aspect (in the future), not to mention my own plans for a web-based client that runs through a proxy.

I'm not asking for anyone to implement something complicated like the ton of client customization/informational protocols (sound, fonts, gmcp, etc). I'm merely proposing a dead simple way for a proxy to tell a server "Hey, this is who is connecting" and for a server to trust the information it is receiving.
06 May, 2011, avidal wrote in the 32nd comment:
Votes: 0
Scandum said:
It may be difficult to convince MUD servers they need to implement data encryption in case someone wants to engage in a MITM attack (with no practical (as of yet) example of how such an attack could be carried out) in order to prevent multiplaying.

All that's needed from a pragmatic perspective is a simple client IP exchange, with the server subsequently comparing its ban lists to both IPs. Someone can submit a fake IP, but assuming the server favors non proxy connections there is no real potential for abuse as it'd disconnect the proxy for multi-playing rather than the direct connection.

Another pragmatic implementation would be the proxy initiating telnet MSSP, checking for "MULTIPLAYING" == "None", and disallowing multiple connections when that's the case.


Like Twisol said, this has nothing to do with encryption.

One place where I think this went wrong is the focus on MITM attacks. I wasn't intending to say that the reason this should be done is to prevent against admittedly rare MITM attacks, but instead because there should be some way for a proxy to tell a server who is connecting. The naive approach is for a server to whitelist a proxy IP and just allow a connection from that IP to send along the client IP like you said. This does exactly the same thing, but adds in authentication in that you can trust who you are receiving the data from.

Again, the problem with rolling something like this into an existing client <-> server protocol is that the proxy would have to negotiate a client protocol that the actual client very well may or may not support, and then the proxy having to figure out what messages along that protocol need to go to the client, which ones it needs to act on, which ones to accept from the client, which ones to block, etc. By implementing this as a dead-simple custom protocol (that no client developers ever need to worry about) you can minimize the amount of work required by both the proxy and the MUD server, while at the same time increasing trust.
06 May, 2011, Twisol wrote in the 33rd comment:
Votes: 0
avidal said:
Arynth said:
I've read the document posted and the comments here, and I have one quick question: if this protocol is supposed to be strictly proxy <–> server communication, wouldn't that mean that the proxy still had to process the stream of data going to the client, and parse out this option before sending it on to the client? I thought not using MSDP or something else was meant to avoid doing that…

In the least, it would have to inject information into the clients stream to go to the server, and then either ignore any responses (meaning the client would get them and need to ignore them), or do as I said above.


You're right in that it still needs to inspect the stream, but there is a significantly less amount of work required with a new protocol. The proxy needs to do nothing but search for IAC DO|DONT|WILL|WONT|SB MPCP/PROXY. If that's not found, then just forward to the client. If it is found, check the data, process it, then remove it from the stream going to the client.


It actually needs to check the byte before the first IAC, too, to make sure it's not also an IAC. In that case the IAC IAC is an escaped IAC, rendering the whole sequence as plain, visible text. Also, IAC DO|DONT|… isn't supposed to be in a subnegotiation, so the proxy might need to watch for that too.

Of course, you can just use libtelnet for that (and I have my own lib, anachronism), which should make proxy implementors' lives easier.


…Also, if a client wants to murder its connection by sending a ClientInfo with false information, more power to it. The proxy shouldn't really care all that much. And if it does have a valid ClientInfo message… well, avidal, what happens if multiple ClientInfo's are received? Should the MUD just update its current data? Makes sense, unless the secret keys being used are different, in which case, wat.
06 May, 2011, David Haley wrote in the 34th comment:
Votes: 0
Quote
One place where I think this went wrong is the focus on MITM attacks. I wasn't intending to say that the reason this should be done is to prevent against admittedly rare MITM attacks, but instead because there should be some way for a proxy to tell a server who is connecting.

Agreed… the focus here should not be on creating some kind of secure authentication and identity system, but rather just to forward along connection information. Why should this proxy be under stricter requirements than normal clients? Seems excessive to me, and we're already operating under the assumption that people are more or less reasonable in the first place. (And if you don't like what a proxy is doing, kill the proxy, problem solved.)
06 May, 2011, Vigud wrote in the 35th comment:
Votes: 0
Quote
Why should this proxy be under stricter requirements than normal clients?
Banning normal clients doesn't hurt as much as banning proxies does.
06 May, 2011, Twisol wrote in the 36th comment:
Votes: 0
David Haley said:
Why should this proxy be under stricter requirements than normal clients? Seems excessive to me, and we're already operating under the assumption that people are more or less reasonable in the first place.

Because proxy clients aren't normal clients…? Multiple users connect through them. There needs to be a way to differentiate between them. To forward the IP, the server must be willing to look at a provided IP instead of the one that comes with the connection. If abused, this is an easy way to get around bans or make it look like you're someone else. Hence, the mechanism needs to be secured somehow. MPCP provides this via a remarkably simple mechanism that gives you a greater degree of confidence in both authenticity and data consistency.

David Haley said:
(And if you don't like what a proxy is doing, kill the proxy, problem solved.)

…huh? How can you kill a proxy that's running remotely?
06 May, 2011, David Haley wrote in the 37th comment:
Votes: 0
Vigud said:
Banning normal clients doesn't hurt as much as banning proxies does.

We're talking about a proxy that is doing weird things. So banning the entire proxy is exactly what you want to do, because you believe it is no longer acting in a trustworthy fashion.

Twisol said:
If abused, this is an easy way to get around bans or make it look like you're someone else. Hence, the mechanism needs to be secured somehow.

You're already trusting that the proxy is behaving reasonably. The proxy connection being secure makes no difference when it comes to trusting the contents of proxy messages. You could have messages over the most secure connection in the world, and you'd still have to just believe that the IP addresses it's forwarding are legitimate.

If you want to guarantee that the proxy isn't playing funny games with client IP addresses, you need client support for all of this, which not only defeats the purpose of this exercise, but seems outside the scope in the first place.

My point here is simple. Why establish such stricter trust rules for the proxy than you already have? Presumably, I won't even entertain using this protocol with a proxy I have no faith in, precisely because I would worry about malicious intent.

And if you are really trying to secure things against MITM attacks, well, you're establishing a stricter standard than exists for direct connections. You're assuming an awful lot of malicious intent for a text-only game, adding a pile of complexity to secure against unlikely attacks that stand to gain relatively little in the first place.

Twisol said:
How can you kill a proxy that's running remotely?

Kill the connection, I meant. I.e., ban it.
06 May, 2011, Twisol wrote in the 38th comment:
Votes: 0
David Haley said:
You're already trusting that the proxy is behaving reasonably.

That's not the point. We want to be sure it's the proxy we're talking to in the first place.
06 May, 2011, avidal wrote in the 39th comment:
Votes: 0
I'm not sure at this point where this discussion is going, but there seems to be a misunderstanding of the purpose.

Without this (or something similar) there are two alternatives:

1) The current system whereby you have no clue who is who if they connect through a proxy (such as TMC and mudgamers) and need to ban the entire proxy to stop malicious activity

2) Setup a system where a proxy can forward client information and then blindly trust based on IP address alone that the party sending you this client information is actually who you think it is.

If you'd like to continue on in a black box where you have no clue who is who, then feel free. This isn't for you. It's for server administrators who actually want to KNOW who is connecting and TRUST that the party sending them that information is who they say they are.

If you don't trust the people running a given proxy server, then don't issue a secret key for that proxy server. If the proxy starts misbehaving, then revoke the key.

Personally, I'd much rather see something like this when I check the who list:

Joe [1.2.3.4 via TMC(100.100.100.101)]
Bob [1.2.3.5 via MudGamers(100.100.100.102)] (MULTIPLAYING AS Alice)
Alice [1.2.3.5 via MudGamers(100.100.100.102)] (MULTIPLAYING as Bob)
John [1.2.3.7 via MudGamers(100.100.100.102)]
Ralph [1.2.3.8 via MudGamers(100.100.100.102)]
Sean [1.2.3.9 via MudGamers(100.100.100.102)]

versus the current option of:

Joe [100.100.100.101] (MULTIPLAYING AS Bob, Alice, John, Ralph, Sean)
Bob [100.100.100.101] (MULTIPLAYING AS Joe, Alice, John, Ralph, Sean)
Alice [100.100.100.101] (MULTIPLAYING AS Bob, Joe, John, Ralph, Sean)
John [100.100.100.101] (MULTIPLAYING AS Bob, Alice, Joe, Ralph, Sean)
Ralph [100.100.100.101] (MULTIPLAYING AS Bob, Alice, John, Joe, Sean)
Sean [100.100.100.101] (MULTIPLAYING AS Bob, Alice, John, Ralph, Joe)
06 May, 2011, David Haley wrote in the 40th comment:
Votes: 0
Twisol said:
We want to be sure it's the proxy we're talking to in the first place.

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.

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?

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?

It seems that you're establishing a higher standard of security here but it's unclear why.

avidal said:
If you'd like to continue on in a black box where you have no clue who is who, then feel free. This isn't for you. It's for server administrators who actually want to KNOW who is connecting and TRUST that the party sending them that information is who they say they are.

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.
20.0/81