View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004740 | unreal | module api | public | 2016-08-23 18:07 | 2016-09-02 09:50 |
| Reporter | capitaine | Assigned To | syzop | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Summary | 0004740: STARTTLS fails with CAPS REQ tls | ||||
| Description | Running STARTTLS with the CAP REQ tls is denied with a 487 ERR_NOTFORUSERS. | ||||
| Steps To Reproduce | > CAP LS > NICK john > USER john - - :john < :Test.chat NOTICE * :*** Looking up your hostname... < :Test.chat NOTICE * :*** Couldn't resolve your hostname; using your IP address instead < :Test.chat CAP * LS :userhost-in-names multi-prefix away-notify account-notify tls > CAP REQ :tls > CAP END < PING :64A34452 > PONG :64A34452 < :Test.chat CAP john ACK :tls > STARTTLS < :Test.chat 001 john :Welcome to the Test IRC Network john!john@localhost (...) < :Test.chat 487 john :STARTTLS is a server only command | ||||
| 3rd party modules | |||||
|
|
Hi, STARTTLS works fine on UnrealIRCd-4.0.5 -> irc.n.com CAP LS <- :irc.n.com CAP * LS :userhost-in-names multi-prefix away-notify account-notify tls -> irc.n.com CAP REQ :userhost-in-names -> irc.n.com CAP REQ :multi-prefix -> irc.n.com CAP REQ :tls <- :irc.n.com CAP * ACK :userhost-in-names <- :irc.n.com CAP * ACK :multi-prefix <- :irc.n.com CAP * ACK :tls -> irc.n.com CAP END -> irc.n.com STARTTLS <- :irc.n.com 670 * :STARTTLS successful, go ahead with TLS handshake -> irc.n.com NICK DBoyz -> irc.n.com USER Guest 0 * :DBoyz__ <- PING :30275D47 -> irc.n.com PONG :30275D47 <- :irc.n.com 001 DBoyz :Welcome to the n IRC Network [email protected] |
|
|
I know but this way means the client would not be compatible on servers without the CAP. |
|
|
Hi, STARTTLS on unrealircd is an implementation of ircv3.1 'tls' extension as per its spec - http://ircv3.net/specs/extensions/tls-3.1.html It states "The STARTTLS command will always operate on servers which advertise the capability [CAP LS server reply] regardless of if the client requests [CAP REQ client response] the capability or not." I have briefly checked the source code and it seems to allow STARTTLS without CAP as long as you have not fully connected to the server. Please follow up if you find that it is not the case |
|
|
Yes it works well if STARTTLS is send before CAP LS, and Unreal is properly SSL-enabled. But shouldn't server reply with a "CAP * NACK :tls" in cases STARTTLS not supported ? |
|
|
I might be wrong but currently unreal seems to only send CAP NAK when users try to remove a sticky CAP extension. You seem to have a point here but A more appropriate way to handle this scenario is to remove STARTTLS token from CAP LS response when STARTTLS is bound to fail (i.e. the cases you mentioned above) Of course what you suggested should be implemented also, let's see what Syzop says about this |
|
|
It seems this bug report started re one thing and is now about something else... or.. maybe it's all just one single misunderstanding :) I see your client sends this: CAP LS NICK.. USER.. CAP REQ tls CAP END STARTTLS Which is interpreted as: CAP LS NICK.. USER.. CAP REQ tls CAP END *** Now the client is succesfully registered and welcomed to IRC *** STARTTLS The crucial point here is that the STARTTLS command is processed AFTER the user is registered, which is not permitted. STARTTLS is only permitted before the user is fully registered (before the NICK/USER/CAP handshake ended). You should instead go for something like this: CAP LS NICK.. USER.. STARTTLS ** ssl handshake ** CAP END ** you are now welcomed on IRC ** Well, various possibilities here, some more secure than others (even better would be to send the STARTTLS after CAP LS), but in any case the STARTTLS should be sent before the user is "registered', in other words: before the CAP END in your case. |
|
|
From those, this connection is working well for me : CAP LS CAP REQ :tls CAP END STARTTLS < 670 * :STARTTLS successful, go ahead -- Doing TLS handshake NICK john USER john - - :john < 001 john :Welcome ... < NOTICE john :*** You are connected to Test.chat with TLSv1.2-ECDHE-RSA-AES256-SHA384-256bits ... and invalidate the bug report. Yes, the specs say : "To use STARTTLS a client simply sends the STARTTLS command to the server before the client registers with the server using the NICK and USER commands" But it means a client cannot connect to old disabled-CAP servers, if the client wait for an CAP reply and server wait for registration. I've been confused about it, thinking there was still a way to connect any server. |
|
|
(Closing, as there's no unrealird bug) I know what you mean but if you do as I suggested you won't have a waiting problem on other ircds. BUT it's not secure as the STARTTLS takes place before NICK/USER (and potentially PASS, quite unacceptable). Yes, it's all a hassle and crappy.. I hate servers who don't reply to unknown commands pre-registered, very annoying :( As adoption of CAP increases (it's now about half, see http://www.ircstats.org/server-features ) you could send the STARTTLS and do something with a timeout. Then non-CAP and completely silent servers will hang <timeout> extra seconds during connect. Problem is that <timeout> needs to be big enough for ident and DNS lookups during which client buffers may not get processed, so then you quickly are at 15 seconds or so. I can understand if that's unacceptable, certainly at the moment. Anyway, those were my 2 cents, and this is not really the place for it :D |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-08-23 18:07 | capitaine | New Issue | |
| 2016-08-24 05:35 | dboyz | Note Added: 0019388 | |
| 2016-08-24 13:14 | capitaine | Note Added: 0019389 | |
| 2016-08-26 05:21 | dboyz | Note Added: 0019391 | |
| 2016-08-26 11:09 | capitaine | Note Added: 0019392 | |
| 2016-08-27 06:22 | dboyz | Note Added: 0019393 | |
| 2016-08-29 09:24 | syzop | Note Added: 0019397 | |
| 2016-08-29 09:25 | syzop | Note Edited: 0019397 | |
| 2016-08-29 14:14 | capitaine | Note Added: 0019399 | |
| 2016-09-02 09:50 | syzop | Note Added: 0019402 | |
| 2016-09-02 09:50 | syzop | Status | new => closed |
| 2016-09-02 09:50 | syzop | Assigned To | => syzop |
| 2016-09-02 09:50 | syzop | Resolution | open => no change required |
| 2017-01-06 15:48 | syzop | Category | module => module api |
