# Pastebin PAOwDhtX [2019-04-21 06:40:51] Is it specified anywhere whatsoever that the first parameter to PING is actually a cookie? Neither of the RFCs mention this, and I've not found this anywhere online aside from conventional usage [2019-04-21 06:41:11] Heck, 1459 even suggests that servers shouldn't respond to PINGs whatsoever [2019-04-21 08:37:31] https://tools.ietf.org/html/rfc2812#section-3.7.2 [2019-04-21 08:37:57] it's not a "cookie" but rfc2812 tells you that whatever you receive you must send it back via PONG [2019-04-21 08:45:32] Xinayder: that's a cookie [2019-04-21 08:47:16] Also it doesn't mention that? It says "the appropriate", which isn't clear at all, and considers the first parameter to be the sending server (and doesn't even mention that clients can send PING messages) [2019-04-21 08:49:40] ERR_NOORIGIN (409) explains it a bit [2019-04-21 08:49:45] PING or PONG message missing the originator parameter which is required since these commands must work without valid prefixes [2019-04-21 08:50:01] https://github.com/ircdocs/modern-irc/issues/59 [2019-04-21 08:50:14] the way I've seen most clients do is send back whatever they receive from the server [2019-04-21 08:50:30] Xinayder: no, that's futher to my point: the RFC considers the first parameter to be the entity that sent the thing [2019-04-21 08:50:36] Be it a client, or a server [2019-04-21 08:50:44] not necessarily [2019-04-21 08:50:53] Which would require the response to have a different value there [2019-04-21 08:51:02] iirc freenode sends a hex string as the first parameter [2019-04-21 08:51:44] jwheare: thanks [2019-04-21 08:52:07] Xinayder: I'd appreciate you pointing where the RFCs say otherwise [2019-04-21 08:52:27] that's the problem, no network follows the rfcs blindly [2019-04-21 08:52:59] Some commands are more accurate than others [2019-04-21 08:53:01] Also freenode doesn't do that. you might be thinking of some servers that send that before registration in order to catch bots/etc that don't send back the cookie exactly [2019-04-21 08:53:36] Xinayder: I know! Which is why I was asking in here in the first place, since I've not really found a reliable source of information on this [2019-04-21 08:54:17] The two IRCds I've looked at (ircd-seven, and inspircd) have the same behaviour where they return the cookie in the first parameter [2019-04-21 08:54:33] I don't know if others have different behaviour [2019-04-21 08:54:39] yeah it's been a while but I remember some network sending a hex string [2019-04-21 08:55:04] I've definitely seen that behaviour before [2019-04-21 08:55:34] https://github.com/inspircd/inspircd/blob/f4041a13c3894e282fb34010f3373d1950136a8c/src/modules/m_conn_waitpong.cpp etc [2019-04-21 08:55:47] however, I think you're not going to have any problem if you just send back whatever first parameter you got, be it a cookie or a server [2019-04-21 08:58:57] Yeah [2019-04-21 08:59:09] I'd just really like to know where this originated from [2019-04-21 08:59:42] Because as I see it currently, most implementations are just copying each other's behaviour [2019-04-21 09:00:06] you should check ircnet's daemon [2019-04-21 09:03:38] http://www.irc.org/ftp/irc/server/irc2.11.2p3/ [2019-04-21 09:04:36] danke [2019-04-21 09:05:40] charybdis: https://github.com/charybdis-ircd/charybdis/blob/master/modules/m_ping.c [2019-04-21 09:24:15] ugh. took me ages to find that (FTP server was down?) but they [ircd2] basically just do as the RFC says. For outgoing PINGs, they send the server's name as the first parameter (or origin/destination if it's a hop); for outgoing PONGs, they send destination/origin flipped (i.e. the origin is now the target, and the destination the sender) [2019-04-21 09:25:43] Relevant code: http://www.irc.org/ftp/irc/server/irc2.11.2p3/ircd/ircd.c line 673, http://www.irc.org/ftp/irc/server/irc2.11.2p3/ircd/s_user.c function m_ping [2019-04-21 09:31:25] looks like charybdis hasn't changed in that regard [2019-04-21 09:38:00] eh, it kind in some places [2019-04-21 09:38:12] I'm way too tired to be looking at this; good night [2019-04-21 09:53:14] ninini [2019-04-21 14:16:54] I think the idea of ping cookies came up to fight some types of bots and UnrealIRCd has that functionality as well even referring to it as ping cookie [2019-04-21 14:21:26] It was to prevent browser based attacks when Firefox allowed arbitrary sockets [2019-04-21 16:11:11] oh that's a thing that might become more common [2019-04-21 16:11:22] what with websocket implementations [2019-04-21 16:11:31] javascript bitcoin miners, c&c'd by IRC [2019-04-21 16:11:59] actually it would probably be wasm wouldn't it for optimal efficiency [2019-04-21 17:52:04] Websocket is not raw tcp [2019-04-21 17:52:25] The server has to specifically accept websocket connections. [2019-04-21 17:52:43] You can’t do arbitrary tcp with wasm either [2019-04-21 17:53:17] i understand websockets aren't tcp, i meant the servers that are accepting websockets can be used as c&c servers [2019-04-21 17:53:37] and i was more thinking do the actually resource intensive part in wasm, then communicate with JS when necessary (c&c) [2019-04-21 17:53:42] That wasn’t the problem but ok [2019-04-21 17:54:08] so you'd do the websocket and IRC stuff with JavaScript and then bitcoin mining with wasm [2019-04-21 18:06:19] It wasn't using websockets, it was abusing arbitrary POST requests [2019-04-21 18:06:41] cookies introduce non-determinmism into this, preventing the automated nature of the attacks [2019-04-21 18:07:43] Because firefox hadn't categorised 6667 as a non-HTTP port [2019-04-21 18:07:45] LordRyan: inspircd's websocket impl requires origin validation [2019-04-21 18:08:25] so unless someone is an idiot and allows http://* [2019-04-21 18:08:40] Sadie: so are origins whitelisted? [2019-04-21 18:08:46] jwheare: yes [2019-04-21 18:09:12] i guess that means you have to also host the web interface [2019-04-21 18:09:35] but you can still connect via websocket as a bot on a server [2019-04-21 18:09:37] https://github.com/inspircd/inspircd/blob/insp3/docs/conf/modules.conf.example#L2270-L2274 [2019-04-21 18:09:57] or allow something like kiwi [2019-04-21 18:10:16] i guess it's similar to us requesting an iline etc [2019-04-21 18:12:31] https://tools.ietf.org/html/rfc6455#section-10.2 [2019-04-21 18:13:34] yeah we do origin checking but we control our client apps. exposing a general purpose ircd to websocket clients is a bit different [2019-04-21 19:51:20] I would love having webchat.freenode.net be usable as a free freenode irc proxy [2019-04-21 19:51:25] ;) [2019-04-21 21:19:14] Sadie: is there a insp testnet with websockets enabled btw? [2019-04-21 21:19:25] i havent tried connecting with kiwi since the last round of changes [2019-04-21 21:20:38] testnet.inspircd.org has it on 7001 but the cert has expired [2019-04-21 21:20:44] i need to make certbot stop falling over [2019-04-21 21:23:57] very nice, works right away \o/ [2019-04-21 21:28:30] gonna add the websocket option on kiwiirc.com so people can test these implementations out easier [2019-04-21 22:03:08] hm, i cant find it now, but what was the encoding for isupport token values? [2019-04-21 22:03:18] there was some specific spec for it iirc [2019-04-21 22:04:09] draft-hardy-irc-isupport-1 [2019-04-21 22:04:22] draft-hardy-irc-isupport-00 [2019-04-21 22:08:01] ah ty. ive just noticed that i dont were parsing the values correctly as your testnet has a space in the network name heh [2019-04-21 22:09:18] but yea, https://kiwiirc.com/nextclient/ now exposes the direct websocket option in the network config, handy for testing out ircd websocket implementations [2019-04-22 10:53:19] — leonardus rolls? [2019-04-22 10:54:44] — dan- rollrollroll [2019-04-22 10:56:16] — jesopo rolls around on the floor complaining [2019-04-22 14:37:14] — jcotton rolls into a bush [2019-04-22 15:10:35] — danopia rolls up a joint [2019-04-22 20:03:12] — presiden cinamon rolls [2019-04-23 11:51:08] construct, Xinayder: i dug up some logs on the PING origin topic from a while ago in #ircv3. might be useful: [2019-04-23 11:51:21] https://www.irccloud.com/pastebin/4gWKe8ty/ [2019-04-23 16:39:36] mmh, interesting [2019-04-23 16:41:19] well kind of, except the 1st param isn't who it's "from" it's a blob it's from whoever sent it, which the server already knows <- I disagree here: when used for S2S, the server needs to know who the true origin was, which would be clobbered if not for that parameter existing [2019-04-23 16:41:38] (this is what ircd2 did, by the looks of things) [2019-04-23 16:42:06] obviously it's obsolete now, given that noone uses the original S2S protocols, but there was reason for that parameter at some point [2019-04-23 16:42:45] s2s is a black box, if in doubt assume i am never talking about it [2019-04-23 16:43:02] mm [2019-04-23 16:43:41] +1 [2019-04-23 16:44:36] So the origin stuff is just legacy that no one cares about. <- pretty much [2019-04-23 16:46:53] jwheare: +1 for the no-javascript link; don't remember seeing that last time I checked out an irccloud paste [2019-04-23 16:47:33] yeah added it a while ago [2019-04-23 16:47:53] that whole discussion can probably be summed up by [2019-04-23 16:47:55] [2019-02-22 10:55:36] the mix of s2c/c2s commands in the rfcs is, in general, a bit weird [2019-04-23 16:57:12] basically: https://i.imgur.com/Rs55nWp.png [2019-04-23 17:08:04] 28xx split them apart i think [2019-04-23 17:08:37] IIRC [2019-04-23 17:13:59] it sort of did [2019-04-23 17:59:15] [16:57:12] <+9d54b3dan-> basically: https://i.imgur.com/Rs55nWp.png [2019-04-23 17:59:33] this is a whole new uncharted meme territory :o [2019-04-23 18:01:10] https://i.imgflip.com/2z9om1.jpg [2019-04-23 18:02:07] spoiler: numerics and standard replies get married [2019-04-23 18:02:35] yes [2019-04-24 01:31:52] jwheare, thanks [2019-04-24 01:32:00] that should be a good addition to modern [2019-04-24 01:32:07] Agreed