WebIrc secure implementations and it's fails

If your UnrealIRCd is up and running but you have a question about it, then use this forum.
(NOT for installation or connecting issues! Use the other forum instead.)

Moderator: Supporters

Locked
HeXiLeD
Posts: 31
Joined: Mon Jan 16, 2017 8:07 pm
Location: online

WebIrc secure implementations and it's fails

Post by HeXiLeD » Tue Dec 26, 2017 2:16 pm

Although currently unable to connect to the irc chat due to this detail, I have been updated about this problem and tested it myself.

Before the flames come, lets just say that I am 100% in favor of security by default and anti clear text protocols 20 years ago. In fact why are we even allowing the usage of clear text port 6667 and or starttls is pathetic and beyond me and in this day and age falls under major ridiculousness, but anyway...

Recently there was a change in regards to make sure people run webirc clients securely and that change was needed for sure but for people already doing it securely this change lacked the capacity to consider those same people or perhaps the webclient which has been mentioned in the unreal release notes as supported along with others.
&Syzop[AWAY]> PeGaSuS: I knew it would annoy people but.. security :]
Some reading:
https://www.bountysource.com/issues/433 ... ing-webirc (which is all good)
https://www.unrealircd.org/docs/WebIRC_Support
https://www.unrealircd.org/docs/WebIRC_block

UnrealIRCd 4.0.16 released
viewtopic.php?f=1&t=8764
You can now have multiple webirc { } blocks with the same mask. This permits multiple blocks like..
webirc {
mask *;
password "....." { sslclientcertfp; };
};
..should you need it. In other words: we don't stop matching upon an authentication failure.
Question 1:
Which of those 3 mentioned web irc clients is able to load and support { sslclientcertfp; }; for such conf block ? Has this option been tested or just theory ?
Which unrealircd configuration documentation mentions this feature ?

Nothing here at the moment:
https://www.unrealircd.org/docs/WebIRC_block

UnrealIRCd 4.0.17 released
Other changes
• UnrealIRCd will no longer give user mode +z to users on WEBIRC gateways using SSL/TLS IRC, unless the WEBIRC gateway gives us some assurance that the client<->webirc gateway connection is also secure (eg: https).
This is the regular WEBIRC format:
WEBIRC password gateway hostname ip
This indicates a secure client connection (NEW):
WEBIRC password gateway hostname ip :secure
Naturally, WEBIRC gateways MUST NOT send the "secure" option if the client is using http or some other insecure protocol.
Question 2:
Has the head unrealircd developer considered if qwebirc sends the mentioned "secure" option before mentioning as one of the 3 supported clients?

In this case, the client being used: qwebirc which is mentioned by unrealircd along with other web clients as supported.

Why do some people prefer or like to use qwebirc ? And no it is not EOL

So lets see the issue:
https://qwebirc.org/features (among many)
SSL/TLS support for the browser and server.
Supports hot-reconfiguration of backend servers via hadns.
Embedded webserver (no messing around with your existing webserver).
Runs it's own webserver and is very light. Easy to serve with https:// and independent of other web servers and needs of reverse proxys and messy setups.

How it runs: (qwebirc relevant config for the case)

Code: Select all

# OPTION: IRCSERVER
# Hostname (or IP address) of IRC server to connect to.
# OPTION: IRCPORT
# Port of IRC server to connect to.
IRCSERVER, IRCPORT = "127.0.0.1", 6697

# OPTION: SSLPORT
# SSL port of IRC server to connect to.
# If this option is uncommented it will override IRCPORT.
SSLPORT = 6697

# OPTION: BASE_URL  
#         URL that this qwebirc instance will be available at, add the
#         port number if your instance runs on a port other than 80.
BASE_URL = "https://domain.net:9999"

WEBIRC_PASSWORD = "asdfkjas89wejc239”

# EXECUTION OPTIONS
# OPTION: ARGS (optional)
#  These arguments will be used as if qwebirc was run directly
ARGS = "-p 9999 -C /path/to/sslcerts/qwebirc_cert.pem -k /path/to/sslcerts/qwebirc_privkey.pem -H /path/to/sslcerts/fullchain.cer -P pid -l logs/log"
Options for execution:

Code: Select all

Usage: run.py [options]

Options:
  -h, --help            show this help message and exit
  -n, --no-daemon       Don't run in the background.
  --help-reactors       Display a list of reactor names.
  -b, --debug           Run in the Python Debugger.
  -t, --tracebacks      Display tracebacks in error pages (this reveals a LOT
                        of information, do NOT use in production!)
  -r REACTOR, --reactor=REACTOR
                        Which reactor to use (see --help-reactors for a list).
  -p PORT, --port=PORT  Port to start the server on.
  -i IP, --ip=IP        IP address to listen on.
  -l LOGFILE, --logfile=LOGFILE
                        Path to twisted log file.
  -c CLOGFILE, --clf=CLOGFILE
                        Path to web CLF (Combined Log Format) log file.
  -C SSLCERTIFICATE, --certificate=SSLCERTIFICATE
                        Path to SSL certificate.
  -k SSLKEY, --key=SSLKEY
                        Path to SSL key.
  -H SSLCHAIN, --certificate-chain=SSLCHAIN
                        Path to SSL certificate chain file.
  -P PIDFILE, --pidfile=PIDFILE
                        Path to store PID file
  -s, --syslog          Log to syslog
  --profile=PROFILE     Run in profile mode, dumping results to this file
  --profiler=PROFILER   Name of profiler to use
  --syslog-prefix=SYSLOG_PREFIX
                        Syslog prefix
After execution:
Shell:

Code: Select all

netstat -nap | grep 9999
tcp        0      0 0.0.0.0:9999            0.0.0.0:*               LISTEN      2448/python2.7
Confirming that the web irc client runs exclusively on secure protocol:

openssl s_client -connect domain.com:9999

Code: Select all

CONNECTED(00000003)
---
Certificate chain
 0 s:/CN=domain.com
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
..........
-----END CERTIFICATE-----
subject=/CN=domain.com
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3719 bytes and written 443 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
.....
Fact one:
qwebirc runs and serves itself securely from moment of execution. TLS being used with valid certificate.


Unrealircd webirc relevant configurations:

Code: Select all

webirc {
        mask 127.0.0.1; 
        type webirc;
        password asdfkjas89wejc239 
        };

Code: Select all

listen  {       ip      *;
                port    6697;

                options {       ssl;
                                clientsonly;
                        };
        };
IRCD: openssl s_client -connect domain.com:6697

Code: Select all

CONNECTED(00000003)
---
Certificate chain
 0 s:/CN=domain.com
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
....
-----END CERTIFICATE-----
subject=/CN=domain.com
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
---
SSL handshake has read 2965 bytes and written 902 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384
Verify the connection:

Code: Select all

netstat -nap | grep 6697
tcp        0      0 0.0.0.0:6697            0.0.0.0:*               LISTEN      1138/unrealircd     
tcp        0      0 127.0.0.1:34181         127.0.0.1:6697          ESTABLISHED 2448/python2.7 
Facts:
The ircd only accepts ssl connections
qwebirc connects only to a secure unrealircd port
qwebirc is being served on https:// on port 9999


qwebirc client connects:
== Usermode change: +isZp
== #channel Cannot join channel (SSL is required)
-NickServ- Your nickname is not registered. To register it, use: /msg NickServ REGISTER password
-OperServ- We will now scan your host for insecure proxies. If you do not consent to this scan please disconnect immediately.
== BE26B9D5.B06E1170.3A56126A.IP is now your displayed host
== Usermode change: +x
Oper monitor:
*** Client connecting: test (webchat@lan.ip) [192.........] {clients} [secure AES256-GCM-SHA384]
Client connects securely from a web client running on https://

Whois test outputs:
[test] (webchat@BE26B9D5.B06E1170.3A56126A.IP): domain.com
[test] is using modes +isxZp
[test] is connecting from *@lan.ip
[test] test.hub.lan (testing hub)
test] idle: 00 hours 04 minutes 42 seconds, signon at: ...date...
[test] End of /WHOIS list.
Despite the fact that the client connects securely from a web client running on https:// the client is marked as insecure.
&Syzop[AWAY]> PeGaSuS: I knew it would annoy people but.. security :]
I really hate wasting time like this to have to read something that translates into implicitly call dumb to people on the other side when someone has failed to consider some detail in regards to a piece of software mentioned as supported in the documentation.

In this case, qwebirc runs from the beginning to the end with ssl/tls. There are no clear text communications. It executes itself securely by loading the ssl/tls certificats, only allows secure client connections and connects securely to the ircd.

This definitely annoys some people that have been running these apps and protocols securely since many many years ago and now it is their fault that it does not work anymore ?

This implementation and in specific the way it was done is also flawed and can easily bypassed to still allow an insecure webclient to connect.
Naturally, WEBIRC gateways MUST NOT send the "secure" option if the client is using http or some other insecure protocol.
So much trouble and annoyance for basically nothing which actually breaks proper configuration already being done by people concerned about security.

In terms of security, the only thing qwebirc needs to have done is to make sure it can never be executed without loading ssl/tlc certificates. All other web ircd clients that do not work this way are basically crap and can bypass this so called :secure pseudo feature.
Constructive criticism leads to evolution and progress. Negative criticism leads to obsolescence. We should not be living in 1990s irc management & developing standards just because it was cool.

k4be
Posts: 24
Joined: Sun Jan 09, 2005 12:19 pm

Re: WebIrc secure implementations and it's fails

Post by k4be » Tue Dec 26, 2017 3:00 pm

The reason for the new feature is quite simple. You know both that your webirc connects to the ircd via a secure protocol, and that your web users connect to the webirc via a secure protocol. Unrealircd has no way to know the latter (it sees only an incoming secure connection to itself). So, theoretically, it was possible for the webirc to connect to ircd with ssl, but clients to connect to webirc via plain http, and ircd had no way to know it, thinking the whole connection chain is secure (though in fact it was not).
So the new feature was added (and, unfortunately for you, can't be disabled temporarily), that relies on the webirc gateway to tell the IRCD, if the web user connection is secure or not, by connection basis.
For this to work, your webirc (qwebirc) should support that, but it looks like that it currently does not. Normally you would reconfigure temporarily Unreal to disable this check, and wait for qwebirc developers to add this new functionality. But it can't be done, because Unreal has no such config options. So, you have three other ways to deal with it:
- Use older Unreal version and wait for a needed qwebirc functionality.
- Accept your secure users not having the +z umode, and wait for a needed qwebirc functionality.
- Modify qwebirc yourself, to always tell Unreal that its clients are secure, and make sure that they really are.
Probably the correct modification (i haven't tested it) would be following:
Replace the line:
self.write("WEBIRC %s qwebirc %s %s" % (config.WEBIRC_PASSWORD, hostname, ip))
with
self.write("WEBIRC %s qwebirc %s %s :secure" % (config.WEBIRC_PASSWORD, hostname, ip))
in qwebirc/ircclient.py file contained in your installation.
All other webirc gateways would need a similar modification.

Syzop
UnrealIRCd head coder
Posts: 1815
Joined: Sat Mar 06, 2004 8:57 pm
Location: .nl
Contact:

Re: WebIrc secure implementations and it's fails

Post by Syzop » Tue Dec 26, 2017 3:10 pm

I doubt my post will in any way change your feelings, but I just want to mention our position anyway:

We did this to prevent users showing up as "secure" when they are in fact communicating over an "insecure" channel like HTTP (not HTTPS). As mentioned in the release notes:

Code: Select all

* UnrealIRCd will no longer give user mode +z to users on WEBIRC
  gateways using SSL/TLS IRC, unless the WEBIRC gateway gives us
  some assurance that the client<->webirc gateway connection is 
  also secure (eg: https).
  This is the regular WEBIRC format:
  WEBIRC password gateway hostname ip
  This indicates a secure client connection (NEW):
  WEBIRC password gateway hostname ip :secure
  Naturally, WEBIRC gateways MUST NOT send the "secure" option if
  the client is using http or some other insecure protocol.
Keep in mind that not everyone is as security-aware as you. It is indeed unfortunate that it also hits people who have a perfectly fine configuration, but that was unavoidable to plug this security hole. It's really not good if someone with +z can join a +z channel and communication is actually going on in cleartext (unencrypted). In my view that is a real sin.

There was a clear consensus on https://github.com/ircv3/ircv3-ideas/issues/12 by both client and server developers in favor of this feature. The only debate was over the exact token syntax (not so relevant for just one token) and the speed. For example an inspircd dev pointed out he didn't like my speed of implementing this. It's a fair point and if it were some random feature I'd agree with him. However, since it's such a security hole, we at UnrealIRCd chose to plug the security hole in next release instead (4.0.17), as announced there at November 9th. I can understand how this put some pressure on client devs but if we hadn't done that then how long would it have taken? I'm not happy with this security issue persisting for another 12, 6, or even 3 months.

Anyway, the fix/suggestion is to check with your webclient vendor for an updated version to rectify the issue, if you haven't done already.

Perhaps others can answer your other questions.

HeXiLeD
Posts: 31
Joined: Mon Jan 16, 2017 8:07 pm
Location: online

Re: WebIrc secure implementations and it's fails

Post by HeXiLeD » Tue Dec 26, 2017 3:43 pm

Unacceptable since it decreases general security:
So, you have three other ways to deal with it:
- Use older Unreal version and wait for a needed qwebirc functionality.
- Accept your secure users not having the +z umode, and wait for a needed qwebirc functionality.
- Modify qwebirc yourself, to always tell Unreal that its clients are secure, and make sure that they really are.
This is not a problem from qwebirc. This is a problem of every other webirc client has which is allowed to run without loading it's own ssl/tls certificate.
Why are we favoring every other garbage irc client and invalidate a more secure one ? Popularity ? geee...
Replace the line:

Code: Select all

self.write("WEBIRC %s qwebirc %s %s" % (config.WEBIRC_PASSWORD, hostname, ip))
with
self.write("WEBIRC %s qwebirc %s %s :secure" % (config.WEBIRC_PASSWORD, hostname, ip))
in qwebirc/ircclient.py file contained in your installation.
Currently not working to solve the problem and is really just a pseudo secure fix.
And in regards to this solution: https://bugs.unrealircd.org/view.php?id=5041
Sending 7 or so characters to the ircd (:secure) to deceive it is not security.
Really ? Honestly ? Is this how security is seen ? Lie to a piece of software to make it think the problem is not there anymore ?

Code: Select all

 by Syzop » Tue Dec 26, 2017 3:10 pm
I doubt my post will in any way change your feelings, but I just want to mention our position anyway:
I do not make make decisions based on feelings and am quite aggressive towards such practice. What humans think or feel is irrelevant for engineering, science and math.
We did this to prevent users showing up as "secure" when they are in fact communicating over an "insecure" channel like HTTP (not HTTPS). As mentioned in the release notes:
Although the intention is good, the reality is:
Sending 7 or so characters to the ircd (:secure) to deceive it is not security.
Keep in mind that not everyone is as security-aware as you. It is indeed unfortunate that it also hits people who have a perfectly fine configuration, but that was unavoidable to plug this security hole. It's really not good if someone with +z can join a +z channel and communication is actually going on in cleartext (unencrypted). In my view that is a real sin.
and I agree that something should and must be done and I have implemented these and other secure features for over a decade now. I also have proposed a solution that solves many of these problems: https://bugs.unrealircd.org/view.php?id=5041
Proposed solution is quite simple for people fully and realistically interested in security by default.

Have the ircd by default (hardcoded) banning any client which is known for not run on https:// by default is one of them.

This is how it should be done and how I have my setup in the config and not by using strings that can be spoofed, forged or faked to trick the ircd to think that the client is actually secure.

On my network clients that have security bugs, holes, exploits, do not support secure features, share their info with third party entities are not able to connect and are banned and I have been doing it for over a decade because security matters first.

Policy is and should be DENY ALL / ALLOW secure only

Anything that does not evolve to meet the requirements of today and needs of tomorrow will become obsolete.
Most irc clients are garbage. Why are we running irc stuff today with the same mentality of the 80s just because it is cool go chat on 'mirc'

What most of other ircd and irc client devs think is on the 80's chat mentality. Evolve or face extinction...

I am seriously disappointed in this type of implementation by the way it hurts clients that actually work properly secure and favors clients that can lie about their actually security. This is horrible. Security by spoofing is the only way to describe it.
Constructive criticism leads to evolution and progress. Negative criticism leads to obsolescence. We should not be living in 1990s irc management & developing standards just because it was cool.

Syzop
UnrealIRCd head coder
Posts: 1815
Joined: Sat Mar 06, 2004 8:57 pm
Location: .nl
Contact:

Re: WebIrc secure implementations and it's fails

Post by Syzop » Tue Dec 26, 2017 3:59 pm

I'm sorry to say but so far you have said nothing that we had not considered. Including the last "to bypass security" argument, see https://github.com/ircv3/ircv3-ideas/issues/12. It came by in the discussion that we had with client devs and server devs and we considered it.
We just weigh things differently / have a different opinion than you.

There's a lot of anger in your posts. I don't consider that constructive at all, despite your signature.

I'm closing this thread. It's clear you have a different view. Each to their own.

Locked