View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003983 | unreal | ircd | public | 2010-12-23 10:15 | 2015-07-13 22:26 |
| Reporter | reed | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | wont fix | ||
| Product Version | 3.2.8 | ||||
| Summary | 0003983: No way to disable requesting of client certificate when establishing SSL session | ||||
| Description | [Originally reported as https://bugzilla.mozilla.org/show_bug.cgi?id=614975] When SSL is enabled, users connecting via SSL are always requested for a client certificate. This is because when USE_SSL is #define'd, AUTHENABLE_SSL_CLIENTCERT is always #define'd (there's no config option for it). If one were to manually modify include/auth.h to change this, client certificates would still be requested because the SSL_CTX_set_verify() call in src/ssl.c isn't encapsulated in an #ifdef AUTHENABLE_SSL_CLIENTCERT. | ||||
| Steps To Reproduce | (uses ChatZilla as testcase) 1. Create/import a client certificate into Firefox (doesn't have to be for this server). 2. Connect to Unreal server on SSL port. 3. See pop-up for client certificate, even if that's not used or wanted. | ||||
| Additional Information | Patch that only encapsulates the SSL_CTX_set_verify() call in src/ssl.c with #ifdef AUTHENABLE_SSL_CLIENTCERT is attached. I haven't tested it. Credit for figuring this out and most of the patch should go to Richard Soderberg, as I just actually reported the issue, made the patch, and added the needed #include. | ||||
| Attached Files | add_ifdef_clientcert_set_verify.diff (1,577 bytes) unreal-3983-configure-request-clientcert.patch (6,157 bytes) | ||||
| 3rd party modules | |||||
|
|
I don't know of any sane reason why you would want to disable usage of client certificates. |
|
|
Because none of our opers actually use them, and it's annoying to end users who continually get prompted for them every time they connect. |
|
|
You are confusing client certs offered at connection and a PEM-encoded SSL certificate that can be used for opering up. The client cert is for connecting to a ssl enabled port and happens long before the user is able to use the /oper command. The latter can be used instead of the oper giving a password wit the /oper command and is configured in the oper block using oper::password::sslclientcert. As far as constantly getting prompted, I'm not sure about. The first time I used my ssl connection I was offered to save the cert and was never prompted again. The remebering or saving of the client cert is the at the users end, not the ircd's end. I use Windows7 as well as XP and mIRC6.35 and I don't get continually prompted unless the cert changes. |
|
|
katsklaw: You're confused. The client cert is something you *send* to the browser, not the other way around. We're not talking about the actual SSL certificate the server is using that it presents to users when connecting. This is that the server is *requesting* a client certificate from the user, which is abnormal. |
|
|
It must be something with browsers only then. I also agree with stealth. Some security measures shouldn't be bypassed simply because they seem annoying. |
|
|
It affects browsers most definitely, sure, but it may also affect clients, depending on their implementation. Many IRC clients support client certificates, as per the documentation at http://www.oftc.net/oftc/NickServ/CertFP for OFTC client certificates. As for "bypassing security measures", I have no idea what you're talking about. How is this a security measure? If it was actually being used for opers, that would be one thing, but it's not wanted, yet the requesting part is on-by-default, which is lame. |
|
|
It's not being bypassed, because it's not even there to begin with. We don't use this feature. What's happening is unreal is telling the user "I'm willing to accept a client certificate to identify you for this SSL session" when negotiating the SSL. This means that in addition to sending the server certificate to the client, it's telling the client that it can send a client certificate back as well. For most users they won't even notice because they probably don't have any client certificates created for anything because not very many people use them. If you're an oper and you actually have one of these set up, you'll get prompted the first time you connect to pick the client cert to send back, and then most clients will remember that and keep sending the same certificate every time you connect after that. If you have client certificates created that are for some other server or website, and openssl or NSS knows about them, you'll get prompted every time you connect, because you have client certificates to pick from, and none of them are valid to be used for this server. IF you're actually using client certificates to authenticate opers, then this is an unfortunate necessity people will have to live with. But we aren't using client certificates to identify opers, so there's no reason for unreal to be prompting for a client cert to begin with. There's probably two ways to fix this: 1) let the admin decide at compile time (which is what's done in the attached patch), or 2) when stepping through all of the oper blocks at config rehash time, set a flag if any of the opers have sslclientcert set as their auth-type, and only request a client cert if that flag is set. #2 is probably more user friendly, and lets the feature automatically "just work" if someone does set up a client cert for an oper, but I'm sure it's more work, too. |
|
|
#2 isn't needed as it's done with the execution of the /oper command and the certificate isn't needed until then anyway. Opering up isn't a requirement by any means so ircd doesn't need to ask then either. |
|
|
katsklaw: I think that your idea requires the server to do SSL renegotiatation upon receiving the /oper command, which would be a little complicated. How about 3) having a set:: -style configuration option to disable or enable this SSL-certificate request? |
|
|
#3 it is. |
|
|
katsklaw: it's not done when the /oper command is issued. It's done during the initial SSL session negotiation when the user connects. It's not possible to do it at any other time. When you run the oper command it simply checks whether the certificate you authed with matches the one in your oper block. This means every user is asked for a client certificate whether they're an oper or not (because it has no way to know whether they'll attempt to oper during the session). Of course, since oper blocks have authorized hostmasks, you could get really smart with it and only request a client cert if the connection is originating from an IP that matches any oper's configured hostmasks. But that gets even more complicated. :) |
|
|
After reading the whole conversation I still think this would be silly to implement in Unreal. I don't know what reed is talking about with being prompted to select an SSL certificate, and what a browser has to do with connecting to an IRC server. Since I have started using IRC ages ago I have *never* been prompted to select a client certificate to send to the server. Keep in mind this is done using 4+ clients to connect using SSL. If your client is prompting you to select a SSL certificate, it sounds like something the client coders need to implement in the client and not the server coders needing to implement something in the server. |
|
|
Nice contradiction/conflict with 0003984 Anyway, I'd be fine with option 3 which binki proposed. Not that it would be something I would endorse, but if there's a need for this, sure.. why not. As long as it doesn't make the code much more complex (which I doubt)... I think what the reporter means, by the way, is that he is prompted to select a private certificate.. this could be if you have multiple private certificates I guess. Also, it's possible that private certificates are password protected. Still, one could just as easily argue that there should be some way in his client to assign specific, or disable, client certificates per-server. Like I said, I wouldn't mind an option (but I'm not coding it myself ;p). |
|
|
unreal-3983-configure-request-clientcert.patch: Adds the configuration option set::ssl::options::no-request-clientcert which disables asking any SSL clients for certificates. I should probably add the #ifdef stuff as well, since client certificates aren't useful if the SSL-certificate-based authentication mechanism is completely disabled.... but I don't understand why anybody would pass up the best authentication option ;-). |
|
|
Hmm.. I'm sorry to close this but we actually want to *actively* encourage ssl client certificates nowadays. We show the fingerprint in /WHOIS, have an extban for it (eg for +I ~S:...) etc. etc. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-12-23 10:15 | reed | New Issue | |
| 2010-12-23 10:15 | reed | File Added: add_ifdef_clientcert_set_verify.diff | |
| 2010-12-23 17:03 | Stealth | Note Added: 0016492 | |
| 2010-12-23 17:29 | justdave | Note Added: 0016493 | |
| 2010-12-23 17:53 | katsklaw | Note Added: 0016495 | |
| 2010-12-23 17:56 | katsklaw | Note Edited: 0016495 | |
| 2010-12-23 19:29 | reed | Note Added: 0016496 | |
| 2010-12-23 20:05 | katsklaw | Note Added: 0016497 | |
| 2010-12-23 20:12 | reed | Note Added: 0016498 | |
| 2010-12-23 20:14 | justdave | Note Added: 0016499 | |
| 2010-12-23 22:09 | katsklaw | Note Added: 0016500 | |
| 2010-12-23 22:54 | ohnobinki | Note Added: 0016501 | |
| 2010-12-24 00:36 | katsklaw | Note Added: 0016502 | |
| 2010-12-24 01:29 | justdave | Note Added: 0016503 | |
| 2010-12-24 17:58 | Stealth | Note Added: 0016507 | |
| 2010-12-29 18:26 | syzop | Note Added: 0016532 | |
| 2010-12-29 18:26 | syzop | Note Edited: 0016532 | |
| 2010-12-30 16:15 | ohnobinki | File Added: unreal-3983-configure-request-clientcert.patch | |
| 2010-12-30 16:20 | ohnobinki | Note Added: 0016541 | |
| 2015-07-13 22:26 | syzop | Note Added: 0018493 | |
| 2015-07-13 22:26 | syzop | Status | new => closed |
| 2015-07-13 22:26 | syzop | Assigned To | => syzop |
| 2015-07-13 22:26 | syzop | Resolution | open => wont fix |
