New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Built-in SASL authentication (IRCv3.1) #4
Comments
Agreed. We need this. |
As for what mechanisms to implement, I'd suggest looking at what mechanisms Atheme implements, as it's the de-facto reference implementation (see https://github.com/atheme/atheme/tree/master/modules/saslserv). Furthermore, according to http://ircv3.atheme.org/documentation/sasl-dh-blowfish, the DH-BLOWFISH method is deprecated, so I'd suggest dropping it unless there are excess resources to allocate to SASL handling. I'd suggest that the following mechanisms be implemented:
|
@culex is this something you would have an interest in looking into? :-) |
I'm completely unfamiliar with the irssi codebase and have only limited time right now. If nobody's done anything until the 7th of July, I'll see what I can do. SASL is a relatively complex matter to implement correctly, and we don't even have CAP support from what I can tell, which is a requirement for handling SASL. Given that IRCv3 is starting to become relatively ubiquitous, for better or for worse, I'd suggest that CAP support be done in a correct and proper way. To be honest, I'm hoping for someone with previous experience of implementing IRCv3 features to handle it. |
Cool, I will leave this assigned to me for now. I will continue to focus on the migration stuff and getting all the patches for 0.8.17 in. |
|
I doubt I'll get around to implementing this. I'd suggest someone else pick this up. |
@culex Thanks for letting us know! :-) |
Irssi really needs this feature as SASL is widely agreed as the best method to identify to services and some networks have difficulties, because some people (Finns who mainly use IRCnet) don't ever identify or register channels and then go to complain to operators when they have lost ops on unregistered channels. CertFP isn't an option (yet(#188). The mechanisms that I would support are:
As you can see, I removed DH-AES @culex list because it was dropped from Atheme atheme/atheme@15f6d84 and added EXTERNAL which was forgotten from that list. EXTERNAL requires support from IRCd in addition to services and is supported on most of networks that I am on that support SASL with the exception of freenode's ircd-seven as they haven't merged that feature from Charybdis yet (freenode/ircd-seven#1). There is also issue of Atheme discontinuing, because Atheme hosted the script before and now it will be at all repositories of Atheme forks and some networks like freenode are hosting different versions of the script. |
@Mkaysi While I concur that I forgot SASL EXTERNAL, I'd strongly plead for keeping DH-AES or DH-BLOWFISH. While indeed, Atheme has removed DH-AES, Anope 2.0 (anope/anope) has no support for ECDSA-NIST256p-CHALLENGE but does support DH-AES (and DH-BLOWFISH). As http://ircv3.atheme.org/documentation/sasl-dh-aes and http://ircv3.atheme.org/documentation/sasl-dh-blowfish state, the mechanisms are still vulnerable to MITM attacks. However, Anope 2.0 administrators may enable DH-AES or DH-BLOWFISH exclusively, thinking it is secure. From my undestanding of the DH-AES mechanism, it is secure in some constellations, particularly over SSL where the user may not wish/is unable to to use a client certificate for whatever reason, or where an attacker can only listen to the plain-text conversation (for example, via strace) but not create a layer inbetween. In that sense DH-AES is a step up from PLAIN, even if it is not an ideal solution. |
Being able to use Also, strace generally wouldn't show the plain-text conversation, since it only shows syscalls, and clients don't output the plain-text that way – they only call into the kernel in the end, to send encrypted TLS records. (One very rare exception is hardware crypto accelerators.) On the other hand, you could see what data is being read from |
@grawity The strace scenario and the SSL/TLS scenario I came up with are separate. That said, having only strace and no gdb is indeed a rare scenario, but doesn't change the fact that there may be misguided Anope 2.0 admins who believe DH-{AES,BLOWFISH} are still appropriate over plaintext IRC. |
If you consider the root user to be an attacker, I think you've got bigger problems.
DH-AES over SSL is as secure as PLAIN over SSL. And I'm not saying PLAIN over SSL is bad, it's actually quite decent thanks to SSL. But once you've got decent crypto at the transport level, what kind of attackers are you protecting against? (with something like DH-AES, that is) |
Well, I imagine it might help against passive monitoring done by a server's operators (who could technically see all messages passing through it, including SASL commands). But they could rather easily MITM it anyway. |
Status update on DH-AES and DH-BLOWFISH: freenode upgraded Atheme and support for these two mechanisms was dropped there. |
I asked from one Anope 2 admin and they said that they think that SASL PLAIN and EXTERNAL are in code and cannot be disabled. EDIT: They checked it. SASL PLAIN and EXTERNAL are parts of their core SASL solution and thus cannot be disabled without editing the code and losing Anope support. https://github.com/anope/anope/blob/2.0/modules/m_sasl.cpp |
@culex DH-AES/DH-BLOWFISH should be dropped from Anope 2 as they were in Atheme. They are dangerous to have enabled as the DH component is used with insecure parameters, which means the key used to encrypt the ciphertext is extremely weak (DH can only provide strong security for half the size of the DH parameters). I would not advise that Irssi implement these mechanisms, as their use should be actively discouraged. |
As of today, with the deprecation of the DH-{AES,BLOWFISH} and the introduction (?) of SCRAM-SHA-256, what is the minimum set of mechanisms to support that provides the most compatibility and security ? |
There is also already IRCv3.2 SASL which features SASL REAUTH which allows SASL to be used after the initial connection e.g. when you have connected to splitted servers or services were down. Before it the only way to automatically identify in that case was CertFP. I think that irssi should also get it implemented. |
Well, IRCv3.2 isn't a priority right now since not even IRCv3.1 is supported, getting in some solid CAP and SASL support is a big step in the right direction (and it's being done in #222). [1] https://tools.ietf.org/html/draft-hansen-scram-sha256-02 |
What she is saying is that SASL REAUTH should be considered for implementation at the same time as the rest of it to ensure it actually gets done. REAUTH is essentially just a clarification that authentication could be implemented after registration, and can be done on 3.1 servers (assuming that they have gotten patched to allow it). |
#278 is now merged, with SASL PLAIN and EXTERNAL support. Huge thanks to @LemonBoy for contributing this and addressing the issues that were brought up during the review... some of which may have been a bit nitpicky. Things left out of the scope of that pull request, to be addressed before the release:
|
A little offtopic, but in case you are interested, ZNC won't be implementing it, because of the log at znc/znc#746 (comment). |
That's good to know. Basically the same reason ahf doesn't want it, nist curves. But still good to allow scripts to implement it since some people currently use it through cap_sasl.pl. |
SASL based authentication is a required extension for IRCv3 compliance (CAP and multi-prefix are required too). This approach solves many of the caveats of methods like "nickserv", and is required in some cases, such as connecting to freenode through tor.
This is currently implemented with third party scripts. I believe it should be a built-in feature (or at the very least, include the script with the default distribution)
Description of the current script based approach: https://freenode.net/sasl/sasl-irssi.shtml
The script itself: https://freenode.net/sasl/cap_sasl.pl
Spec: http://ircv3.org/extensions/sasl-3.1
IRCv3 general information: http://ircv3.org/ (irssi is notably missing from the "Compliant Software" section)
The text was updated successfully, but these errors were encountered: