Yes, the A2S_INFO w/ challenge just appends the 4 byte challenge after “TSource Engine Query\0”. PLUS in the future there may be other stuff! Specifically, a future update to the protocol may append a server-assigned “revision number” of the game data (map name, server name, tags, etc) obtained from the master server. The game server may then omit those details in its reply that have not changed since that revision. This is totally optional. The server can continue to provide all the details if it wishes. (Or if some middle box is caching them.) But if it wishes to send a smaller reply, it can do so.
Unfortunately, my testing revealed that at least one relatively large game hosting provider was blocking packets that had only 4 extra 0’s appended to the original A2S_INFO request. So for that hosting provider, at least, there doesn’t appear to be any change that could be made to the original packet that would not get blocked. And that is just the first example of very aggressive filtering brought to our attention, because it was a relatively large user of this service, from a partner with whom we happen to be in frequent communication. There are presumably many other hosting providers and server operators that have already (quite reasonably) taken draconian steps such as this to protect their servers against abuse of this ancient and poorly-designed protocol from the early 2000’s. This is why “Just tell the game hosting providers to change their filters” is not a serious alternative. There are too many of them, and there is not a clear channel through which the communication could be made to reach all of them. This forum is perhaps the best, and many did not get the first message. Even now, they are slow to respond when I was in direct communication when them. So “Just make them change the filters” in practice means to go ahead and break games, and use player reports of the game being broken to get the attention of the operators. Personally I find that approach unacceptable. This latest proposal is definitely not the ideal design one would make if one were starting from scratch with no existing users. But it seems to be a good path forward to address the reflection attack vulnerability, given the current state of affairs and the constraints that are in place given how many users of this protocol there are. This plan puts the control in the hands of the server operators. If compatibility with third party clients is important to them, they can retain the current behavior indefinitely. It’s up to them. The official client will be ready to prove they are not spoofing soon, and they can request that proof when they decide they value protection against the reflection amplification over compatibility. From: csgo_serv...@list.valvesoftware.com <csgo_serv...@list.valvesoftware.com> On Behalf Of David Parker Sent: Thursday, December 3, 2020 8:46 PM To: csgo_serv...@list.valvesoftware.com Cc: hlds_announce@list.valvesoftware.com Subject: [External Mail] Re: [Csgo_servers] RE: Changes to A2S_INFO - take 2 Thanks for the updates. I assume this means that the "TSource Engine Query\0" remains in place, and the challenge response (when provided) gets appended after the trailing null byte? Also, this may be a silly question, but is there a smaller padded packet size that could be used, which doesn't trigger DDoS protections but is still big enough that it makes a reflection attack less appealing to the asshats who launch them? Just curious. Thanks, Dave On Thu, Dec 3, 2020 at 10:54 PM Fletcher Dunn - fletcherd at valvesoftware.com<http://valvesoftware.com> (via csgo_servers list) <csgo_serv...@list.valvesoftware.com<mailto:csgo_serv...@list.valvesoftware.com>> wrote: A steam client beta has been released: https://steamcommunity.com/groups/SteamClientBeta/announcements/detail/2896341257765264787 It understands how to respond if the server issues a challenge in response to an A2S_INFO request. Importantly because of the existing filtering environment servers run in, the client will behave EXACTLY as it did before, until the server replies in the new method. (https://twitter.com/ZPostFacto/status/1334700095221104640) The protocol is now as follows: • Client will send the exact A2S_INFO packet that it has always sent, no more, no less. • A new server will reply with a challenge, using the same S2C_CHALLENGE packet that’s used for the A2S_PLAYERS and A2S_RULES packets. (Indeed, if a client is quick enough, it can use the same challenge for multiple requests.) • Now, a client will send a A2S_INFO with the challenge appended. Also: DO NOT ASSUME THAT ANY EXTRA BYTES AFTER THE CHALLENGE ARE INVALID. This is reserved for future expansion to the protocol! There are some more protocol changes in development right now designed to have the client obtain more information from the master server, thus reducing the amount of information that must come from the server. Those improvements won’t be possible if assumptions are made about packet sizes! I’ll post again when there are server binaries available that can opt into the new behavior, fixing the reflection attack vulnerability. You will not want to opt in until all clients you care about are speaking the new protocol. For steam clients, that will probably at least a couple of weeks. Please share this with any authors of third party clients that you know! From: csgo_serv...@list.valvesoftware.com<mailto:csgo_serv...@list.valvesoftware.com> <csgo_serv...@list.valvesoftware.com<mailto:csgo_serv...@list.valvesoftware.com>> Sent: Thursday, December 3, 2020 2:42 PM To: 'hlds_announce@list.valvesoftware.com<mailto:hlds_announce@list.valvesoftware.com>' <hlds_announce@list.valvesoftware.com<mailto:hlds_announce@list.valvesoftware.com>>; csgo_serv...@list.valvesoftware.com<mailto:csgo_serv...@list.valvesoftware.com> Subject: [Csgo_servers] Changes to A2S_INFO - take 2 The previous change to pad the server browser query A2S_INFO packets has triggered some aggressive Anti-DDoS filters for some games. This change was made to address a reflection amplification attack in the protocol. So it looks like we will need to address the vulnerability by securing the response with a challenge, in the same way that the A2S_PLAYERS and A2S_RULES queries work. We’ll be releasing a new client soon that sends the small A2S_INFO packets again, but also understands how to reply to a server that replies with a challenge instead of the data. This protocol does make it more complicated to write a custom client for the protocol (although not drastically so), and means that the query traffic cannot be trivially filtered at the edge. Unfortunately, it looks like in the current environment, that is what we need to do. Further bulletins as events warrant. _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/ _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/ -- Dave Parker '11 Database & Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177 _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/ _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/
