Commit graph

39 commits

Author SHA1 Message Date
Chris Smith c607fd5a58 Set a higher timeout for proxyproto listeners
go-proxyproto added support for a read timeout in 0.6.0[1] and
defaulted it to 200ms. After this time if no data is read on
the socket, it is closed.

This is _really_ low if the underlying connection is a TLS
one as no data pops out the other end until the handshake is
done. It effectively limits you to TLS connections within
a 50ms RTT of your bouncer with clients that are fast enough
at responding.

It appears that HexChat on Arch is somehow slow enough at
TLS connections thant it consistently takes longer than
200ms even over localhost, meaning it outright can't connect
to soju any longer.

To make this a lot less painful, have soju pass in a read
timeout of 5 seconds. This feels like a reasonable tradeoff
between keeping (possibly malicious) connections open and
accepting the realities of network connections.

[1]: https://github.com/pires/go-proxyproto/issues/65
2021-09-19 17:00:40 +02:00
Rafael Castillo d1181b3e7a Check for TLS config in wss listeners
Previously http.Server.ListenAndServeTLS would return a not very helpful
error about a failed open. This adds a check similar to the one in the
ircs case that should make it clearer to operators what the error is.
2021-09-09 10:06:31 +02:00
Drew DeVault 61b68d6dfb db: refactor into interface
This refactors the SQLite-specific bits into db_sqlite.go. A future
patch will add PostgreSQL support.
2021-05-25 16:35:39 +02:00
Simon Ser c994ce7092 sojuctl: don't use log.Fatalf in readPassword 2021-04-19 14:11:25 +02:00
Simon Ser c375c7d922 cmd/soju: allow specifying -listen multiple times
Closes: https://todo.sr.ht/~emersion/soju/67
2021-03-31 19:02:40 +02:00
delthas 56bf73716d Increase downstream TCP keepalive interval to 1 hour
The rationale for increasing the TCP keepalive interval from 15 seconds
(default) to 1 hour follows.

- Why increasing TCP keepalives for downstream connections is not an
  issue wrt to detecting connection interruptions

The use case of TCP keepalives is detecting whether a TCP connection was
forcefully shut down without receiving any TCP FIN or RST frame, when no
data are sent from that endpoint to the other peer.

If any data is sent from the peer and is not ACKed because the
connection was interrupted, the socket will be closed after the TCP RTO
(usually a few seconds) anyway, without the need for TCP keepalives.

Therefore the only use of TCP keepalives is making sure that a peer that
is not writing anything to the socket, and is actively reading and
waiting for new stream data to be received, can, - instead of waiting
forever to receive packets that will never arrive because the connection
was interrupted -, detect this disconnection, close the connection
locally, then try to connect again to its peer.

This only makes sense from a client point-of-view. When an IRC client is
not write(2)ing anything to the socket but is simply waiting for new
messages to arrive, ie read(2)ing on the socket, it must ensure that the
connection is still alive so that any new messages will indeed be sent
to him. So that IRC client should probably enable TCP keepalives.

However, when an IRC server is not writing anything to its downstream
socket, it doesn't care if it misses any messages from its downstream
client: in any case, the downstream client will instantly detect when
its messages are not reaching its server, because of the TCP RTO
(keepalives are not even needed in the client in that specific case),
and will try to reconnect to the server.

Thus TCP keepalives should be enabled for upstream connections, in
order to make sure that soju does not miss any messages coming from
upstream servers, but TCP keepalives are not needed for downstream
connections.

- Why increasing TCP keepalives for downstream connections is not an
  issue wrt security, performance, and server socket resources
  exhaustion

TCP keepalives are orthogonal to security. Malicious clients can open
thousands of TCP connections and keep them open with minimal
bookkeeping, and TCP keepalives will not prevent attacks planning to
use up all available sockets to soju.

It is also unlikely that soju will keep many connections open, and in
the event that thousands of dead, disconnected connections are active in
soju, any upstream message that needs to be sent to downstreams will
disconnect all disconnected downstreams after the TCP RTO (a few
seconds). Performance could only be slightly affected in the few seconds
before a TCP RTO if many messages were sent to a very large number of
disconnected connections, which is extremely unlikely and not a large
impact to performance either.

- Why increasing TCP keepalives could be helpful to some clients running
  on mobile devices

In the current state of IRC, most clients running on mobile devices
(mostly running Android and iOS) will probably need to stay connected
at all times, even when the application is in background, in order to
receive private messages and highlight notifications, complete chat
history (and possibly reduced connection traffic due to avoiding all the
initial messages traffic, including all NAMES and WHO replies which
are quite large).

This means most IRC clients on mobile devices will keep a socket open at
all times, in background. When a mobile device runs on a cellular data
connection, it uses the phone wireless radio to transmit all TCP
packets, including TCP packets without user data, for example TCP
keepalives.

On a typical mobile device, a wireless radio consumes significant power
when full active, so it switches between several energy states in order
to conserve power when not in use. It typically has 3 energy states,
from Standby, when no messages are sent, to Low Power, to Full Power;
and switches modes on an average time scale of 15s. This means that any
time any TCP packet is sent from any socket on the device, the radio
switches to a high-power energy state, sends the packet, then stays on
that energy state for around 15s, then goes back to Standby. This
does include TCP keepalives.

If a TCP keepalive of 15s was used, this means that the IRC server would
force all clients running on mobile devices to send a TCP keepalive
packet at least once every 15s, which means that the radio would stay
in its high-power energy state at all times. This would consume a
very significant amount of power and use up battery much faster.

Even though it would seem at first that a mobile device would have many
different sockets open at any time; actually, a typical Android device
typically has at one background socket open, with Firebase Cloud
Messaging, for receiving instant push notifications (for example, for
the equivalent of IRC highlights on other messaging platforms), and
perhaps a socket open for the current foreground app. When the current
foreground app does not use the network, or when no app is currently
used and the phone is in sleep mode, and no notifications are sent, then
the device can effectively have no wireless radio usage at all. This
makes removing TCP keepalives extremely significant with regard to the
mobile device battery usage.

Increasing the TCP keepalive from soju lets downstream clients choose
their own keepalive interval and therefore possibly save battery for
mobile devices. Most modern mobile devices have complex heuristics for
when to sleep the CPU and wireless radio, and have specific rules for
TCP keepalives depending on the current internet connection, sleep
state, etc.

By increasing the downstream TCP keepalive to such a high period, soju
lets clients choose their most optimal TCP keepalive period, which means
that in turn clients can possibly let their mobile device platform
choose best that keepalive for them, thus letting them save battery in
those cases.
2021-03-24 18:04:44 +01:00
Simon Ser c0513013d5 Fix panic on GetCertificate
Fixes the following panic:

    panic: interface conversion: interface {} is tls.Certificate, not *tls.Certificate
2021-03-19 09:27:19 +01:00
Simon Ser 21e9fe9b3c Reload TLS certs on SIGHUP
References: https://todo.sr.ht/~emersion/soju/42
2021-03-18 14:07:03 +01:00
Simon Ser 0c0397407c Don't add "irc" in ALPN list for WebSocket servers
This is incorrect because HTTP listeners don't handle plain IRC
connections. This also prevents net/http from setting up an HTTP/2
server.
2021-03-18 11:33:30 +01:00
Simon Ser 061347f9f9 Add Unix socket listener
Closes: https://todo.sr.ht/~emersion/soju/51
2021-03-16 09:27:40 +01:00
Simon Ser 0954c7da79
Add irc to ALPN protocols
The new ALPN token has been approved [1]. We can start using it now.

[1]: https://mailarchive.ietf.org/arch/msg/tls-reg-review/i8YyT82XUtEgR-oXMG3sbyWYT8E/
2021-02-24 19:41:12 +01:00
Simon Ser 08b1010939 Add support for graceful shutdown
Closes: https://todo.sr.ht/~emersion/soju/45
2021-02-09 17:34:46 +01:00
Kalyan Sriram 586c7ee336
sojuctl: change-password: check if user exists
When changing the password, checks if the user exists *before* prompting
for a password change, instead of after.
2020-11-26 19:27:08 +01:00
Simon Ser bbe67adf1e
Add support for the PROXY protocol
IPs whitelisted in accept-proxy-ip can now use the PROXY protocol to
indicate the original source/destination addresses.

Closes: https://todo.sr.ht/~emersion/soju/81
2020-09-07 21:28:24 +02:00
Simon Ser 2c723823b0
Set Server.AcceptProxyIPs 2020-09-07 20:58:49 +02:00
Simon Ser 65302d3c1e
Add an ident server
Closes: https://todo.sr.ht/~emersion/soju/69
2020-08-11 10:59:06 +02:00
Simon Ser c1f8002428
cmd/sojuctl: read user from DB before updating it
This makes sure we don't overwrite other fields, such as Admin.

Closes: https://todo.sr.ht/~emersion/soju/85
2020-08-11 10:21:49 +02:00
delthas 21af06302a sojuctl: Add support for creating admin users
This adds a new flag, `-admin` for creating admin users, which can
access admin service commands, among which create-user to create other
users on-the-fly.

Since the person running the commands in the README will be the local
soju administrator, the user they create should be admin as well, hence
the README update.
2020-06-08 22:30:09 +02:00
delthas ed943f5451 Fix: Check the stdin scanner for errors when reading the password
Reading from stdin with Scanner.Scan() can either fail because of a read
error, or return no bytes because the EOF was reached.

This adds support for checking these cases before actually reading the
password.
2020-06-08 22:30:09 +02:00
Simon Ser 998546cdc3
Introduce User.Created
For Network and Channel, the database only needed to define one Store
operation to create/update a record. However since User is missing an ID
we couldn't have a single StoreUser function like other types. We had
CreateUser and UpdatePassword. As new User fields get added (e.g. the
upcoming Admin flag) this isn't sustainable.

We could have CreateUser and UpdateUser, but this wouldn't be consistent
with other types. Instead, introduce User.Created which indicates
whether the record is already stored in the DB. This can be used in a
new StoreUser function to decide whether we need to UPDATE or INSERT
without relying on SQL constraints and INSERT OR UPDATE.

The ListUsers and GetUser functions set User.Created to true.
2020-06-08 11:59:03 +02:00
Simon Ser d0cf1d2882
Add support for WebSocket connections
WebSocket connections allow web-based clients to connect to IRC. This
commit implements the WebSocket sub-protocol as specified by the pending
IRCv3 proposal [1].

WebSocket listeners can now be set up via a "wss" protocol in the
`listen` directive. The new `http-origin` directive allows the CORS
allowed origins to be configured.

[1]: https://github.com/ircv3/ircv3-specifications/pull/342
2020-06-07 14:13:46 +02:00
Simon Ser 6c1634799a
Allow multiple listeners, default to ircs
Users can now specify multiple "listen" directives in their
configuration file. If -listen is specified on the CLI, it's added to
the list of listeners.

Listeners are now parsed as URLs. If the scheme is missing "ircs" is
assumed. URLs allow to enable/disable TLS on a per-listener basis and
will be used for Unix sockets too.

The default listening address is changed from irc+insecure://:6667 to
ircs://:6697. This avoids setting up an insecure listener opened to
everybody.
2020-06-04 20:16:23 +02:00
Thorben Günther 1622b772ab Allow to read password when stdin is not a tty. 2020-06-03 15:51:56 +02:00
Thorben Günther 148bbc8102
Add ability to change password 2020-04-10 10:09:02 +02:00
delthas 0607b940e2 Add support for bouncer logs
Add bouncer logs, in a network/channel/date.log format, in a similar
manner to ZNC log module. PRIVMSG, JOIN, PART, QUIT, MODE are logged.

Add a config directive for the logs file, including a way to disable
them entirely.
2020-03-28 00:07:20 +01:00
Simon Ser f3940117d1
Rename project to soju 2020-03-13 18:13:03 +01:00
Simon Ser a572b24702
cmd/jouncectl: new command
Allows to create users.
2020-03-11 19:01:03 +01:00
Simon Ser 84fe3ae255
Add SQLite database
Closes: https://todo.sr.ht/~emersion/jounce/9
2020-03-04 18:22:58 +01:00
Simon Ser 6e12347f2b
cmd/jounce: fix non-TLS listener address 2020-03-03 15:15:57 +01:00
Simon Ser 286fb4b18c
Add a -debug flag 2020-02-18 16:31:18 +01:00
Simon Ser 1f5a72a7cf
Add config file 2020-02-18 14:10:23 +01:00
Simon Ser 603bd6bdef
Add CLI flags for listening address and hostname 2020-02-17 16:25:09 +01:00
Simon Ser 3b2bb58c60
Per-user connections 2020-02-07 11:36:42 +01:00
Simon Ser ae7f162883
Join channels on upstream servers 2020-02-06 19:22:04 +01:00
Simon Ser 56d793543e
Connect to upstream servers 2020-02-06 16:03:07 +01:00
Simon Ser 06cd1ce44f
Add Server.Logger 2020-02-06 15:50:46 +01:00
Simon Ser 5547eb7290
Add connection registration 2020-02-04 18:56:07 +01:00
Simon Ser 6d4581a6d0
Send "unknown command" replies 2020-02-04 11:25:53 +01:00
Simon Ser 8e31fde0ab
Add basic IRC listener 2020-02-04 10:46:22 +01:00