>then does that mean that the whole challenge request/response model is >effectively moot?
For new servers, yes, after they are updated with new code (and do not intentionally relax the 1200 requirement using the environment variable). However, clients will still need to understand the challenge handshake, if they wish to talk to any older servers that do not update and still require the challenge. From: csgo_servers@list.valvesoftware.com <csgo_servers@list.valvesoftware.com> On Behalf Of David Parker Sent: Tuesday, December 1, 2020 10:25 AM To: csgo_servers@list.valvesoftware.com Subject: Re: [External Mail] Re: [Csgo_servers] Steam Client beta released with changes to the A2S_INFO protocol Thanks for clarifying that, Fletch. That answers my question. In my test queries I am padding the packets with zeros, but I was querying against current production versions of TF2 and CS:GO, not the new testing binaries. So that explains why I still needed a challenge response to get anything from A2S_PLAYER, regardless of the packet size. So if this change is going to require that all A2S_INFO, A2S_RULES, and A2S_PLAYER queries are >=1200 bytes, and any such request which is >=1200 bytes gets an immediate response with no challenge required, then does that mean that the whole challenge request/response model is effectively moot? Because if I'm understanding this correctly, the server won't answer a challenge request which is <1200 bytes, and will respond to a proper one with the requested information. I'm mostly just trying to determine which steps can be disabled or removed completely in my query app, once these engine changes are live. Thanks! On Tue, Dec 1, 2020 at 12:09 PM Fletcher Dunn - fletcherd at valvesoftware.com<http://valvesoftware.com> (via csgo_servers list) <csgo_servers@list.valvesoftware.com<mailto:csgo_servers@list.valvesoftware.com>> wrote: But to answer this question: >Can I just send a header and 0x55 with nothing after it, if it's padded to >>=1200 bytes? Yes (after the first four 0xff bytes). Also, is it required that you always pad with *zeros*. (Just in case we need to extend the protocol in the future.) From: Fletcher Dunn Sent: Tuesday, December 1, 2020 9:06 AM To: csgo_servers@list.valvesoftware.com<mailto:csgo_servers@list.valvesoftware.com> Subject: RE: [External Mail] Re: [Csgo_servers] Steam Client beta released with changes to the A2S_INFO protocol Previously, an A2S_PLAYER packet with a challenge of zero (or any incorrect challenge for that matter) was interpreted as a challenge request, and the server would reply with a challenge number for the client to use. The new behavior will be that if the packet is padded to be at least 1200 bytes, the server should just go ahead and reply with the info, even if the field where the challenge normally goes is zero. The CSGO server has not yet been updated to use the new binaries, however! Let me work with the CSGO guys to get that updated. I was about to suggest that you obtain the latest binaries to use for testing by opting into the beta client on linux. However, those are compiled to target a newer distro, and we compile special “server” binaries that target older distro. If you have a server running on a relatively recent distro, I believe it should work to mix those binaries, but I cannot say for sure – I have not ever actually tested this. From: csgo_servers@list.valvesoftware.com<mailto:csgo_servers@list.valvesoftware.com> <csgo_servers@list.valvesoftware.com<mailto:csgo_servers@list.valvesoftware.com>> On Behalf Of David Parker Sent: Monday, November 30, 2020 1:45 PM To: csgo_servers@list.valvesoftware.com<mailto:csgo_servers@list.valvesoftware.com> Subject: Re: [External Mail] Re: [Csgo_servers] Steam Client beta released with changes to the A2S_INFO protocol Thanks, Fletcher. But doesn't A2S_PLAYER require the challenge response to be included in the query? In my testing I have found that SRCDS will accept a challenge request which is padded to 1200 bytes and return a challenge response. And then I can send an A2S_PLAYER query with that challenge response and pad it to 1200 bytes, and then get the player info back. I just wanted to see if this is the correct way moving forward, or if the need for a challenge was removed. And if so, what it has been replaced with. Can I just send a header and 0x55 with nothing after it, if it's padded to >=1200 bytes? Thanks! On Mon, Nov 30, 2020 at 3:41 PM Fletcher Dunn - fletcherd at valvesoftware.com<http://valvesoftware.com> (via csgo_servers list) <csgo_servers@list.valvesoftware.com<mailto:csgo_servers@list.valvesoftware.com>> wrote: The new gameserver code will drop all A2S_PLAYER packets < 1200 bytes, if the environment variable is set. No challenge is necessary for packets >= 1200, but if the environment variable is set to allow <1200 packets, then the challenge will be required for such packets. The new client code will always send 1200 byte packets. It will also know how to do the challenge handshake, for compatibility with old servers. From: csgo_servers@list.valvesoftware.com<mailto:csgo_servers@list.valvesoftware.com> <csgo_servers@list.valvesoftware.com<mailto:csgo_servers@list.valvesoftware.com>> On Behalf Of David Parker Sent: Monday, November 23, 2020 10:39 AM To: csgo_servers@list.valvesoftware.com<mailto:csgo_servers@list.valvesoftware.com> Subject: [External Mail] Re: [Csgo_servers] Steam Client beta released with changes to the A2S_INFO protocol Hi Fletcher, I was just hoping you could clarify something for me. For A2S_PLAYER, is the challenge still required once the 1200 byte minimum is implemented? And if so, does the challenge query need to be >1200 bytes, or just the subsequent A2S_PLAYER query which includes the challenge response? Thanks! Dave On Wed, Nov 18, 2020 at 7:53 PM Fletcher Dunn - fletcherd at valvesoftware.com<http://valvesoftware.com> (via csgo_servers list) <csgo_servers@list.valvesoftware.com<mailto:csgo_servers@list.valvesoftware.com>> wrote: A Steam client beta has just been released, with the following change notes relevant to the A2S_INFO discussion: Server Browser • Server browser packets (A2S_INFO, A2S_PLAYER, A2S_RULES) sent by clients will now be at least 1200 bytes. (For more details, see https://steamcommunity.com/discussions/forum/14/2989789048633291344/) Third party tools that send these packets are especially encouraged to read this thread.) • Improved gameserver challenge generation to harden against certain DoS attacks https://steamcommunity.com/groups/SteamClientBeta/announcements/detail/2896339990496271925 Also, if you use the steamclient.dll/.so with that beta, you can activate the new, stricter message handling on the gameserver by setting the environment variable STEAM_GAMESERVER_MIN_CONNECTIONLESS_PACKET_SIZE=1200 This is just the beta steam client, not the full public release. Only a set of users will be using this client, and we are not quite to deployment step #1 described below. From: Fletcher Dunn Sent: Monday, November 16, 2020 4:47 PM To: 'hlds_annou...@list.valvesoftware.com<mailto:hlds_annou...@list.valvesoftware.com>' <hlds_annou...@list.valvesoftware.com<mailto:hlds_annou...@list.valvesoftware.com>> Subject: RFC: Changes to the A2S_INFO protocol Hello! Over the next couple of months we will be releasing some changes to how servers and clients using steamclent.so/dll<http://steamclent.so/dll> handle the venerable Source engine A2S_INFO message used by the server browser. This includes the Steam client server browser, all Source engine games, and all Steam games using the ISteamMatchmaking API. The purpose of these changes is a long overdue fix for a reflection attack vulnerability. This email is to let you know what those plans are and to solicit your feedback. Fixing the vulnerability requires changing the protocol and will necessarily break existing third party utilities that speak the protocol. Currently, the A2S_INFO packet looks like this: 4 bytes: 0xFFFFFFFF 1 byte: 0x54 (A2S_INFO packet type identifier) 20 bytes: "Source Engine Query\0" The proposal is for clients to modify the A2S_INFO packet they send in one of two ways: Option 1: Pad the message with zeros, so that the request is larger than the reply. The passes size is TBD, but it will probably be at least 800 bytes, and perhaps as high as 1200. Feedback is requested concerning this size. Option 2: Append a 4-byte anti-spoofing challenge obtained using the existing A2S_PLAYER or A2S_RULES messages. Note that both options produce a packet that is acceptable to the current code in steamclient.so/dll<http://steamclient.so/dll>. However, any custom handlers might have stricter behavior, and will need to be updated to be aware than “extra” data might appear after the end of the magic string in packets from legitimate clients. Once all clients are using one of these two options, a server wishing to avoid being vulnerable to reflection attacks could drop any A2S_INFO packets below a minimum size without a challenge. The changes would be deployed as follows: 1.) First, we will release a new Steam client that sends A2S_INFO messages padding to a minimum size. (Option #1 above.) Since it takes time for Steam client updates to roll out to all Steam users, and for third parties to change their code to make queries in the new format, we will not change the server to require the new format by default. However, the server code will be updated to look for an environment variable that can be used to opt into the new, stricter behavior. This is so that third parties can test their clients to make sure they are compliant with the new server code. 2.) As more clients upgrade to the new code and third party tools are updated to send queries in the new format, server operators may elect to opt into the new behavior at their discretion using the environment variable. 3.) After some time has passed (and we have posted several warnings on this mailing list), we will ship a new steamclient.so/.dll<http://steamclient.so/.dll> that has the strict behavior enabled by default. A different environment variable can be used to use the older, more permissive behaviour. If you have any concerns or feedback about this change, please post it to hlds_annou...@list.valvesoftware.com<mailto:hlds_annou...@list.valvesoftware.com>. After feedback has been collected and details finalized, I’ll post again with more technical details about the changes that are going to be made. _______________________________________________ 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/ -- 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/ -- 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/