View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002640 | unreal | ircd | public | 2005-09-14 00:39 | 2007-04-15 08:42 |
| Reporter | mm_freak | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | no change required | ||
| Product Version | 3.2.4 | ||||
| Summary | 0002640: Public key authentication | ||||
| Description | What is really missing in almost any ircd is public key authentication. For SSL connections the ircd could check the provided public key against the one stored for the provided nickname in the registration phase. If it matches, then any existing connection for that nickname should be killed. If it doesn't match, the connection should be refused or the user renamed. It shouldn't be possible to use this nickname without proper pubkey authentication. This is not only secure, it also replaces NickServ and /oper. The user wouldn't have to remember any passwords anymore. | ||||
| Additional Information | Proper client-side support exists in almost any client. SSL is nearly worthless without authentication. | ||||
| 3rd party modules | |||||
|
|
[quote]SSL is nearly worthless without authentication.[/quote] From what point of view? Because a client can (should!) verify the SSL certificate, and then thus knows it is really talking to the correct server. From that point, it is a secure channel. Or am I missing something? [quote]For SSL connections the ircd could check the provided public key against the one stored for the provided nickname in the registration phase. If it matches, then any existing connection for that nickname should be killed.[/quote] Well, for starters, one of the reason why you wouldn't see that in all those ircds (unreal/hybrid/bahamut/ircu/etc) is that the ircd does not deal with nickname registration; services do. We do support client certificates for opers though (and at many other points where a password is used). oper { [..] password { sslclientcert "blah.crt"; }; }; When connected (and allowed in), you can just use '/oper nickname <somerandomcharacterhere>'. This option is currently un(der)documented. |
|
|
That's not really what I meant. It's not thought to be a replacement for nickname registration. It would just be a good way of authentication ("Is this really the person I want to talk to?") - not only for opers. And not really with certificates, but with public keys - as supported by OpenSSH. Also it should be easy to implement: keep a file with nickname-pubkey pairs (maintained by hand or by a little tool I could write for you). On connect, just look up the pubkey stored for the nickname given in the registration phase. If it matches the pubkey of the SSL connection, kill any existing connection for that nickname and allow the connection. Otherwise refuse it completely. For authenticated users, this information should appear in the /WHOIS informaion. Maybe "is using a secure connection (authenticated)" instead of just "is using a Secure Connection". |
|
|
Hm, doesn't interest me at all then. But I'll keep it open for another person to respond ;p |
|
|
What if I write a patch for that? Would you apply it, if it works? |
|
|
I don't see the usefulness... [quote]It would just be a good way of authentication ("Is this really the person I want to talk to?") - not only for opers.[/quote] Isn't that exactly what services (nickserv, actually) do? [quote]And not really with certificates, but with public keys - as supported by OpenSSH.[/quote] Why? [quote]Also it should be easy to implement: keep a file with nickname-pubkey pairs (maintained by hand or by a little tool I could write for you). On connect, just look up the pubkey stored for the nickname given in the registration phase. If it matches the pubkey of the SSL connection, kill any existing connection for that nickname and allow the connection. Otherwise refuse it completely.[/quote] ??? I'm lost... really... You are basically just redoing nickserv here, but then in a worse way. [quote]For authenticated users, this information should appear in the /WHOIS informaion. Maybe "is using a secure connection (authenticated)" instead of just "is using a Secure Connection".[/quote] We already have services for this, and it adds: "Is a registered user" Or even better, if you are +r (registered) and +z (SSL): "Is a registerd user" "Is using a secure connection" I don't see what your method would add compared to services, in fact I only see many difficulties and downsides. I somehow doubt codemastr will be more enthousiastic about this. |
|
|
You also need to consider that 99% of IRC's SSL users don't know how to make their own certs/keys, so this would create major problems when their clients connect normally, get killed with an invalid cert/key... Once that happens, you would instantly be teaching your whole network how to install PGP, and applying the proper things to the proper places. So basically, 99% of SSL users don't even know what a cert/key is... They just know their connection is secure. |
|
|
[quote]Isn't that exactly what services (nickserv, actually) do?[/quote] [quote]Why?[/quote] The advantage compared to classic NickServ is that you can use the same key on any server, which also prevents that someone pretends to be you on other servers. NickServ on the other hand just reserves your nick. [quote]You also need to consider that 99% of IRC's SSL users don't know how to make their own certs/keys, so this would create major problems when their clients connect normally, get killed with an invalid cert/key... Once that happens, you would instantly be teaching your whole network how to install PGP, and applying the proper things to the proper places.[/quote] Not if this feature is just an option, as I thought it to be. Also: nicknames for which no keys exists are not authenticated at all. Only for users who want it. [quote]So basically, 99% of SSL users don't even know what a cert/key is... They just know their connection is secure.[/quote] Basically, their connection isn't really secure. Example: if the user is in a local area network, then SSL without pubkey-auth is absolutely worthless. Any other user on that network could download an MITM tool and not only intercept, but also manipulate his connection. So there is no real security without proper authentication. |
|
|
I can't follow you on the advantage on proving your identity on other servers/networks by introducing a key-pair-authorization. As far as I understand this concept: each user has to create a key-pair and establish the public key on the server(s) of his choice. It's more or less the same as the nickserv-concept - you have to run through a registration process and have to be the first to grant you access to the nick in question. So where is the difference? If some evil guy is first in laying down his key for your nick on someother network, he can as well pretend to be you as on nickserv-concept-driven networks nowadays. |
|
|
Not really. He would need your private key to prove to be you. This can be done, for example, by providing a fingerprint in the /WHOIS information. Also not every user has to do this. Only those users wishing to do it that way. As I said before: it's not thought to be a replacement for NickServ. It should just be an addition to it. |
|
|
[quote]Basically, their connection isn't really secure. Example: if the user is in a local area network, then SSL without pubkey-auth is absolutely worthless. Any other user on that network could download an MITM tool and not only intercept, but also manipulate his connection. So there is no real security without proper authentication.[/quote] ??? You do understand the server certificate gets validated right? So then this is all crap if you ask me (forgive me my lack of a better english expression), unless you can point me to a research paper otherwise. Because, if it would be truth, and SSL communication would be insecure _when the server certificate got validated (either imported, or via a trusted certificate path)_, then ANY SSL communication on the internet is insecure such as all online https banking sites, since that works exactly the same way! AFAIK when a MITM is in use, from a client p.o.v. you get a different server certificate, and - assuming you imported the original server certificate the first time and verified the fingerprint as it should be, blabla (this is easy in f.e. mirc) - you get a popup warning that the client detected a new certificate. Now if you have any sense of security (granted, many users are idiots -- the well known "human problem"), then you reject it since you know something is wrong. Again, point me to any links to research/security/whatever papers proving a situation where a MITM attack is possible while receiving the same server certificate as a client.... ** So I'm still not seeing the advantage over simple nickserv... - SSL proves the authenticity of the server, and provides encryption - NickServ provides the authentication of the user So what is the added value? |
|
|
There's another problem with this: users would have to contact someone with shell access to get the ssl key added. Plus, it isn't automatically shared with the rest of the network, meaning the user would have to go hoping around for an admin for EVERY server on the network (if he so wanted). Unless you make some module / bot to do all that automatically, it's just not going to be very practical. If you make a module... well you can probably already implement this whole ssl cert stuff in there anyway! |
|
|
[quote]Because, if it would be truth, and SSL communication would be insecure _when the server certificate got validated (either imported, or via a trusted certificate path)_, then ANY SSL communication on the internet is insecure such as all online https banking sites, since that works exactly the same way![/quote] Tell me... how many SSL-users do even know what a certificate is? How many users do own a certificate? How many servers do own a non-self-signed certificate? 1 of 1000? Besides, Bugz was assuming a non-experienced user anyway. [quote]There's another problem with this: users would have to contact someone with shell access to get the ssl key added. Plus, it isn't automatically shared with the rest of the network, meaning the user would have to go hoping around for an admin for EVERY server on the network (if he so wanted).[/quote] Well, that's true. It would be impractical without such a bot/module. Let me think about it for a while. =) |
|
|
And how exactly are you solving the "user stupidity" problem? Because you don't. You are only making it worse :Pp. Actually you are not solving anything here, there's nothing special in your setup that would make the server more trusted than using certs. So it still makes no sense whatsoever. SSL is secure, if you know what you are doing, if you don't.. it's just as with anything: the user is usually the weakest link :). |
|
|
Oh well, let's forget about it. =) When I got time, I'll write a module for that. I hope, there's a chance for it to be made public as a third-party addon. Maybe someone besides me would have use for that. =) |
|
|
If you are still interested in this, 0003254 might be interesting for you, if you want to code a module that sends the SSL client certificate fingerprint on connect to services, for instance. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-09-14 00:39 | mm_freak | New Issue | |
| 2005-09-14 11:05 | syzop | Note Added: 0010465 | |
| 2005-09-14 19:00 | mm_freak | Note Added: 0010466 | |
| 2005-09-14 19:03 | syzop | Note Added: 0010467 | |
| 2005-09-14 21:51 | mm_freak | Note Added: 0010468 | |
| 2005-09-14 22:23 | syzop | Note Added: 0010469 | |
| 2005-09-15 15:58 | Stealth | Note Added: 0010472 | |
| 2005-09-15 18:33 | mm_freak | Note Added: 0010473 | |
| 2005-09-15 18:52 | medice | Note Added: 0010474 | |
| 2005-09-15 20:45 | mm_freak | Note Added: 0010475 | |
| 2005-09-16 11:33 | syzop | Note Added: 0010477 | |
| 2005-09-16 11:57 | aquanight | Note Added: 0010479 | |
| 2005-09-17 01:07 | mm_freak | Note Added: 0010480 | |
| 2005-09-17 11:09 | syzop | Note Added: 0010481 | |
| 2005-09-17 11:11 | syzop | Note Edited: 0010481 | |
| 2005-09-17 11:14 | syzop | Note Edited: 0010481 | |
| 2005-09-17 21:54 | mm_freak | Note Added: 0010484 | |
| 2005-09-19 15:32 | syzop | Status | new => closed |
| 2005-09-19 15:32 | syzop | Resolution | open => no change required |
| 2007-04-15 08:42 |
|
Note Added: 0013385 |
