[irc/freenode/web-7.0.git] / content / news / 2013-06-27-new-tlsssl-channel-modes-and-webirc.md

---
author: Pricey
date: 2013-06-27 09:10:13+00:00
slug: new-tlsssl-channel-modes-and-webirc
title: New TLS/SSL Channel Modes & Webchat Features
category: infrastructure
category: technical
category: webchat
imported: yes
robots: noindex
---
We've recently enabled some new functionality in our ircd to further help you manage your channels:


# Channel mode +S


This ensures only users that have connected via TLS/SSL (and so have user mode +Z) are able to join; you can not /invite them through it. It will not prevent the use of the channel by any non-TLS/SSL users already present.


# Extended ban $z


Documented in '/help extban' for some time, this has also been enabled and matches all TLS/SSL users. Usage is similar to the '$a' type (which matches all identified users) and could for example be set as '+q $~z' to to quiet any users not connected over an ssl connection.


# Webchat


WEBIRC has been enabled so that behind their hostmask, users can now be considered to be connecting from their real address. This means that a single ban format can apply to both direct connections and webchat connections.

For example, a user connecting from 171.205.18.52 will still appear as 'nickname!abcd1234@gateway/web/freenode/ip.171.205.18.52' but ban masks of the form '\*!\*@171.205.18.52' will match! This is now the most effective method of matching users using webchat but the realname and hexip username are still available.

Although freenode's webchat is available over SSL, the webchat's localhost connection to the ircd is not SSL, so webchat users do not get user mode +Z. Webchat users will not be able to join a +S channel and will not match the $z extban, even if they are using webchat over SSL.


# Security considerations


These channel modes can not guarantee secure communication in all cases; if you choose to rely on them, please understand what they can and can't do, and what other security considerations there are.

There are a variety of known security problems with SSL, and reasons why the +S mode may not guarantee transport security on freenode. Some of these are:


  * These modes may be unset by channel operators at any time, allowing non-TLS/SSL users to join, and the mode may subsequently be reapplied;

	
  * If network splits occur it may also be possible for users to bypass +S intentionally or by chance;

	
  * Clients may be compromised or malicious, or using a malicious shared host;

	
  * Clients may have traffic intercepted as part of a Man In The Middle (MITM) attack and then transparently forwarded via SSL, invisibly to channel users;

	
  * There may be issues with TLS/SSL itself in server or client configuration or architecture which compromise its ability to provide effective transport security at the network level (there have been several published attacks against SSL recently - [see here](http://en.wikipedia.org/wiki/Secure_Socket_Layer#Security)).


This is not an authoritative list, so before using +S as part of any channel which requires strong anonymity, please ensure you understand what it does and its drawbacks.

There are other security tools you may want to look at - you may want to consider using client plugins that provide additional encryption or route your connection through Tor. Tor also allows you to create spurious traffic to hide real traffic patterns. freenode provides its own hidden Tor node which means you can trust this connection as much as you trust freenode. Your IRC traffic with freenode via Tor is end-to-end encrypted from your Tor client to our Tor node. It does not pass through any third party nodes in unencrypted form.

Finally, unless you can trust everyone in a channel and are sure it is configured properly and you understand the other technical risks, do not rely on these channel modes exclusively. Security is generally layered; ensure you have good defense in depth and don't rely on individual controls which may be a single point of failure.


## Using other websites or services via Tor


Remember to **always** encrypt your traffic when using Tor as you have no control over who is running exit nodes and if they are doing traffic analysis on them. While your traffic to the exit node is encrypted and the ingress node can not read it, the exit node will always need to be able to remove Tor encryption. If your traffic is clear-text said exit node will be able to read it.
Commit	Line	Data
c5293e15	1	---
849bdd6f SB	2	author: Pricey
	3	date: 2013-06-27 09:10:13+00:00
	4	slug: new-tlsssl-channel-modes-and-webirc
	5	title: New TLS/SSL Channel Modes & Webchat Features
c5191f36 EK	6	category: infrastructure
	7	category: technical
	8	category: webchat
df8e5765	9	imported: yes
3406dcfa	10	robots: noindex
849bdd6f	11	---
849bdd6f SB	12	We've recently enabled some new functionality in our ircd to further help you manage your channels:
	13
	14
	15	# Channel mode +S
	16
	17
	18	This ensures only users that have connected via TLS/SSL (and so have user mode +Z) are able to join; you can not /invite them through it. It will not prevent the use of the channel by any non-TLS/SSL users already present.
	19
	20
	21	# Extended ban $z
	22
	23
	24	Documented in '/help extban' for some time, this has also been enabled and matches all TLS/SSL users. Usage is similar to the '$a' type (which matches all identified users) and could for example be set as '+q $~z' to to quiet any users not connected over an ssl connection.
	25
	26
	27	# Webchat
	28
	29
	30	WEBIRC has been enabled so that behind their hostmask, users can now be considered to be connecting from their real address. This means that a single ban format can apply to both direct connections and webchat connections.
34876803	31
5ad99a3a	32	For example, a user connecting from 171.205.18.52 will still appear as 'nickname!abcd1234@gateway/web/freenode/ip.171.205.18.52' but ban masks of the form '\!\@171.205.18.52' will match! This is now the most effective method of matching users using webchat but the realname and hexip username are still available.
34876803	33
849bdd6f SB	34	Although freenode's webchat is available over SSL, the webchat's localhost connection to the ircd is not SSL, so webchat users do not get user mode +Z. Webchat users will not be able to join a +S channel and will not match the $z extban, even if they are using webchat over SSL.
	35
	36
	37	# Security considerations
	38
	39
	40	These channel modes can not guarantee secure communication in all cases; if you choose to rely on them, please understand what they can and can't do, and what other security considerations there are.
34876803	41
849bdd6f SB	42	There are a variety of known security problems with SSL, and reasons why the +S mode may not guarantee transport security on freenode. Some of these are:
	43
	44
	45
	46
	47	* These modes may be unset by channel operators at any time, allowing non-TLS/SSL users to join, and the mode may subsequently be reapplied;
	48
	49
	50	* If network splits occur it may also be possible for users to bypass +S intentionally or by chance;
	51
	52
	53	* Clients may be compromised or malicious, or using a malicious shared host;
	54
	55
	56	* Clients may have traffic intercepted as part of a Man In The Middle (MITM) attack and then transparently forwarded via SSL, invisibly to channel users;
	57
	58
	59	* There may be issues with TLS/SSL itself in server or client configuration or architecture which compromise its ability to provide effective transport security at the network level (there have been several published attacks against SSL recently - [see here](http://en.wikipedia.org/wiki/Secure_Socket_Layer#Security)).
	60
	61
	62	This is not an authoritative list, so before using +S as part of any channel which requires strong anonymity, please ensure you understand what it does and its drawbacks.
34876803	63
849bdd6f	64	There are other security tools you may want to look at - you may want to consider using client plugins that provide additional encryption or route your connection through Tor. Tor also allows you to create spurious traffic to hide real traffic patterns. freenode provides its own hidden Tor node which means you can trust this connection as much as you trust freenode. Your IRC traffic with freenode via Tor is end-to-end encrypted from your Tor client to our Tor node. It does not pass through any third party nodes in unencrypted form.
34876803	65
849bdd6f SB	66	Finally, unless you can trust everyone in a channel and are sure it is configured properly and you understand the other technical risks, do not rely on these channel modes exclusively. Security is generally layered; ensure you have good defense in depth and don't rely on individual controls which may be a single point of failure.
	67
	68
	69	## Using other websites or services via Tor
	70
	71
	72	Remember to always encrypt your traffic when using Tor as you have no control over who is running exit nodes and if they are doing traffic analysis on them. While your traffic to the exit node is encrypted and the ingress node can not read it, the exit node will always need to be able to remove Tor encryption. If your traffic is clear-text said exit node will be able to read it.