Copyright © 2017 Evan Magaliff <email@example.com>
Copyright © 2017 Darren Whitlen <firstname.lastname@example.org>
Unlimited redistribution and modification of this document is allowed provided that the above copyright notice and this permission notice remains intact.
This specification is a work-in-progress and may have major incompatible changes without warning.
This specification may change at any time and we do not recommend implementing it in a production environment.
This specification is intended to document the existing
WEBIRC command that is already in use by multiple IRC servers and WebIRC gateways to provide a standard specification for implementation. This specification does not add any new features or changes, although new features, such as use of public-key cryptography instead of password authentication, can be submitted as extensions.
When a user connects through an indirect connection to the IRC server, the user’s actual IP address and hostname are not visible. The
WEBIRC command allows the WebIRC gateway to pass on the user’s actual IP address and hostname to the IRC server. This information can be used by the network as if the user was connecting directly.
WEBIRC command MUST be the first command sent from the WebIRC gateway to the IRC server and MUST be sent before capability negotiation.
WEBIRC command takes four parameters:
passwordPassword authenticating the WebIRC gateway to the IRC server which must be agreed upon ahead of time
gatewayWebIRC gateway service name
hostnameUser’s resolved hostname
ipIPv4 or IPv6 address of the connecting user. If the IP address cannot be resolved to a DNS name, the IP address MUST be sent as both the
If forward and reverse DNS do not match, the IP address SHOULD be sent as the
hostname and the unverified
hostname SHOULD NOT be sent (see Security Considerations). If the connection fails to the IRC server, the WebIRC gateway MUST return an
ERROR with an appropriate message and terminate the connection.
Note: Previous implementations referred to the
gateway field as
user. This change is for documentation clarity only and maintains compatibility with all existing implementations.
WEBIRC password gateway hostname ip
IP address resolves to hostname.
WEBIRC hunter2 ExampleGateway 3-100-51-198.location.example-isp.com 198.51.100.3
IP address does not resolve to hostname.
WEBIRC hunter2 ExampleGateway 198.51.100.3 198.51.100.3
Error from invalid password.
ERROR :Invalid WebIRC password
Webchat applications that proxy the connection to the IRC server are the primary intended use case. WebIRC allows network and channel operators to use available moderation and security tools to their full extent by exposing user IP addresses and hosts.
Other use cases include bouncer services that wish to pass user information to the IRC server.
WebIRC requires that the both WebIRC gateway and IRC server be configured to accept the connection in advance. Specific recommendations are outlined below in the Security Considerations section.
WebIRC allows anyone with a valid password to successfully connect to the IRC server and spoof any desired hostname. IRC servers SHOULD use secure passwords and SHOULD whitelist the IP addresses for the allowed WebIRC gateway servers. If the
WEBIRC command does not originate from a whitelisted IP address or uses an incorrect password, the gateway SHOULD close any connections with an
Because the possibility for hostname spoofing exists, IRC servers MAY attempt to further validate or resolve hostnames and match them to an IP address. It is the responsibility of IRC servers to verify the authenticity of connecting users and perform additional security checks as they see fit. To assist network operators and prevent abuse, IRC servers SHOULD show when a WebIRC connection is in use and SHOULD provide the original host when possible. This behavior is non-normative and implementation defined.