View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002043 | unreal | ircd | public | 2004-08-26 07:55 | 2020-04-15 17:39 |
Reporter | al5001 | Assigned To | syzop | ||
Priority | normal | Severity | trivial | Reproducibility | N/A |
Status | closed | Resolution | no change required | ||
Platform | All | OS | All | OS Version | All |
Product Version | 3.2.1 | ||||
Summary | 0002043: SSL Certificate Status - CRL & OCSP | ||||
Description | It wold be very nice to have an optional conf option for the IRCd to check the CRLs (Certificate Revocation Lists) from each CA to validate client certificates (only if the client has presented a certificate). | ||||
Additional Information | Perhaps one way to do this is (assuming fingerprint is the fingerprint of each CA root certificate): set { ssl { fingerprint "A6:1B:37:5E:39:0D:9C:36:54:EE:BD:20:31:46:1F:6B" { crl "http://www.cacert.org/revoke.crl"; }; }; }; Again, this is just a suggestion. I don't know how else one would check the CA list like this. However, CRLs are very important, especially when private keys get comprimised frequently by attackers, requiring those stolen keys' certificates' serial numbers to be revoked. | ||||
Tags | No tags attached. | ||||
3rd party modules | |||||
|
Well that could be useful, yes. However, first of all, I don't know how to do it (yet). Secondly, it would only work with remote-include builds since it needs to be able to download that file from HTTP. So that kinda limits its usability. |
|
OpenSSL doesn't have routines to do this? :/ I know things like IE that use SSL will check revocations or expirations... (but that's not OSSL). Hm... OpenSSH uses OSSL I think... does it check CRLs? If not, maybe we could make a request to the OpenSSL developers to implement this? :) |
|
First thing, OpenSSL version 0.9.7 or higher is required. Libraries: openssl/x509_vfy.h, openssl/err.h, openssl/pem.h Objects: X509, X509_STORE, X509_LOOKUP, X509_STORE_CTX /* read client certificate */ ...#define CLIENT_CERT "cert.pem" ...fp = fopen(CLIENT_CERT, "r") ...X509 *cert; cert = PEM_read_X509(fp, NULL, NULL, NULL) /* create cert store and verify callback */ ... if (!(store = X509_STORE_new())) /* error creating X509_STORE_CTX object */ ...X509_STORE *store; X509_STORE_set_verify_cb_func(store, verify_callback) int verify_callback(int i, X509_STORE_CTX *stor) { if(!i) ... /* error X509_verify_cert_error_string(stor->error) */ return i; } /* load the CA certs and CRLS */ ...#define CA_FILE "cafile.pem" ...#define CA_DIR "/usr/local/etc/openssl" ...#defile CRL_FILE "revoke.crl" ...if (X509_STORE_load_locations(store, CA_FILE, CA_DIR) !=1) ... /* error handler, cant open CA file or directory */ ...if (X509_STORE_set_default_paths(store) !=1) ... /* error handler, cant load the system wide CA certs */ ...X509_LOOKUP *lookup;if (!(lookup = X509_STORE_add_lookup(store, X509_LOOKUP_file()))) ... /* error handler, cant create X509_LOOKUP object */ ...if (X509_load_crl_file(lookup, CRL_FILE, X509_FILETYPE_PEM) !=1) ... /* error handler, cant read CRL file */ /* cant verify with CRL on old versions of openssl (for those who are lazy to upgrade openssl) */ ...#if (OPENSSL_VERSION_NUMBER > 0x00907000L) ...X509_STORE_set_flags(store, X509_V_FLAG_CRL_CHECK | ... X509_V_FLAG_CRL_CHECK_ALL) #endif ...X509_STORE_CTX *verify_ctx;if (!(verify_ctx = X509_STORE_CTX_new())) ... /* error handler, cant create X509_STORE_CTX object */ ...#if (OPENSSL_VERSION_NUMBER > 0x00907000L) ...if (X509_STORE_CTX_init(verify_ctx, store, cert, NULL) !=1) ... /* error handler, cant initialize verification context */ ...#else ...X509_STORE_CTX_init(verify_ctx, store, cert, NULL) ...#endif ...if (X509_verify_cert(verify_ctx) !=1) ... /* error handler, cant verify cert */ ...else .../* certificate verified correctly */ I hope this is helpful :P |
|
Yeah OpenSSL has functions to do the checking, but look at that. It's using a local file called "revoke.crl" it's not fetching it from a URL. |
|
Well I don't know. Using a thread+socket to fetch the CRL list every time a client connected (with a client cert) would be a bandwith killer... So, maybe we can have the IRCd check the CRL list for each trusted CA in user-defined intervals (and then store those downloaded CRLs in a subdirectory). Then have the IRCd check the CRLs in the subdirectory. edited on: 2004-08-27 00:27 |
|
You're skipping over one very key point. Unreal can download files, that's how remote includes work. However, Unreal *requires* libcurl to implement remote includes. If the user does not configure Unreal to use libcurl, there would be no way to implement this. There is no standard download_from_url function. And even if there was, Unreal needs to do it asynchronously which is why we use libcurl. If I can figure out how to implement CRLs, it certainly sounds like a good idea. The thing is, it would *require* remote includes to be enabled. |
|
Ok, forget libcurl, how about the 'ftp' program? I'm guessing that every version of Linux and Unix have it by default. Even Windows has it in C:\Windows\System32 (C:\Windows on older versions of Windows)... which leads to code portability*... The ftp program could be run from a thread to fetch the files. * - I know, libcurl is portable, but what I mean here is that 'ftp' does not normally have to be installed separately, because it is usually on the system by default. edited on: 2004-09-17 04:11 |
|
[quote]Ok, forget libcurl, how about the 'ftp' program? I'm guessing that every version of Linux and Unix have it by default. Even Windows has it in C:\Windows\System32 (C:\Windows on older versions of Windows)... which leads to code portability*... The ftp program could be run from a thread to fetch the files.[/quote] Ok, first of all, most CRLs are on HTTP servers, not FTP. So an FTP tool is useless. And though *nix has a commandline HTTP downloader (wget/lynx/fetch/etc.) Windows does not, so that suggestion is gone. And think about what you're saying here... we don't want the hassle of installing libcurl, so lets add the hassle of threading??? That's insane! It would be slow, CPU/memory hogging, and it would likely still require the user to install another library (just like Linux needed FSU Pthreads when Unreal used threading for the proxy scanner). Your solution doesn't solve anything, it just complicates it. But for the record, let me clarify. I wasn't saying "no we can't use libcurl," if this feature were added it would indeed use libcurl, that's definate. I'm not about to add some crazy hack just because some people don't want libcurl support. |
|
Ok, let's just forget about CRLs then. If it's really a big deal, and if convenience overrides security, let's go the MS way. |
|
What are you talking about??? No one has said anything about not adding CRLs. In fact, I said it was a good idea. I simply said it would rely on libcurl. I don't know what you're reading, but it certainly doesn't seem to be what I'm writing. |
|
Heh, well anyways... ftp actually does work for downloading http files, I've already done it: pomme@alsbox:/home/pomme> ftp http://www.cacert.org/revoke.crl Requesting http://www.cacert.org/revoke.crl 100% |*************************************| 29905 8.05 KB/s 00:00 ETA 29905 bytes retrieved in 00:03 (8.04 KB/s) pomme@alsbox:/home/pomme> ls revoke.crl revoke.crl pomme@alsbox:/home/pomme> Unfortunately, it does not work on Windows. |
|
Doesn't Windows have some system DLL for HTTP stuffs? I figured ever since explorer and iexplore started integrating... HTTP usage would be part of the shell API at the least... and if not, well... I'd say stick with libcurl in either case... As for downloading at user-defined intervals... *coughrehashcough* |
|
Ah, yes, good idea. Like /rehash -crls ? Instead of using an interval and a timer. |
|
Well, there's one problem that a certificate may be put on the CRL between rehashes, and who knows how long it will be before a rehash occurs on the server, thus that certificate - to us - remains valid? In other words, I think some kind of expiration timeout on the CRLs should be used, and when that timeout expires, reload the CRL and reapply it. Alternatively, on *nix, you run a cron job to ./unreal rehash at the appropriate intervals. Definately full rehash == CRL rehash. Dunno about having a rehash switch for it though. For Windows, you'll have to run some kind of automated client to connect, oper up to an oper block that has only the can_rehash flag, and then rehash the server and quit. (Why limited operblocks are useful :P .) Then hook up that client into Task Scheduler (make sure it's enabled!). *edit* Wrong app :( . */edit* edited on: 2004-09-20 01:36 |
|
[quote]For Windows, you'll have to run some kind of automated client to connect, oper up to an oper block that has only the can_rehash flag, and then rehash the server and quit. (Why limited operblocks are useful :P .) Then hook up that client into Task Scheduler (make sure it's enabled!).[/quote] Or you could use a version of Windows that was designed for running servers, NT/2k/XP/2003 and simply use the builtin service manager to tell Unreal to rehash... |
|
That's possible? Guess I'll have to look at the NT service code... |
|
Instead of using CRLs, you should be using OCSP - Online Certificate Status Protocol (RFC2560) Also take a look at RFC4557 and RFC4806 for reference. Also, I should note that the CAcert.org CRL's size is over a megabyte now, not very practical to keep downloading. OCSP is a better method. |
|
http://svn.python.org/projects/external/openssl-0.9.7l/apps/ocsp.c shows how to use OCSP in OpenSSL ($ openssl ocsp) |
|
This is unlikely to happen. OCSP stapling perhaps one day, but.. only once a lib provides functions for it... it is hard to do and easy to break.. even apache and nginx fuck things up. |
Date Modified | Username | Field | Change |
---|---|---|---|
2004-08-26 07:55 | al5001 | New Issue | |
2004-08-26 15:51 |
|
Note Added: 0007430 | |
2004-08-26 20:22 | aquanight | Note Added: 0007431 | |
2004-08-26 22:58 | al5001 | Note Added: 0007434 | |
2004-08-26 23:38 |
|
Note Added: 0007435 | |
2004-08-27 00:19 | al5001 | Note Added: 0007436 | |
2004-08-27 00:20 | al5001 | Note Edited: 0007436 | |
2004-08-27 00:25 | al5001 | Note Edited: 0007436 | |
2004-08-27 00:26 | al5001 | Note Edited: 0007436 | |
2004-08-27 00:27 | al5001 | Note Edited: 0007436 | |
2004-08-27 00:27 | al5001 | Note Edited: 0007436 | |
2004-08-27 01:24 |
|
Note Added: 0007437 | |
2004-09-17 04:04 | al5001 | Note Added: 0007673 | |
2004-09-17 04:08 | al5001 | Note Edited: 0007673 | |
2004-09-17 04:11 | al5001 | Note Edited: 0007673 | |
2004-09-17 23:44 |
|
Note Added: 0007693 | |
2004-09-18 00:45 | al5001 | Note Added: 0007695 | |
2004-09-18 03:17 |
|
Note Added: 0007697 | |
2004-09-18 23:54 | al5001 | Note Added: 0007716 | |
2004-09-19 04:35 | aquanight | Note Added: 0007717 | |
2004-09-19 22:31 | al5001 | Note Added: 0007727 | |
2004-09-20 01:36 | aquanight | Note Added: 0007728 | |
2004-09-20 01:36 | aquanight | Note Edited: 0007728 | |
2004-09-20 17:59 |
|
Note Added: 0007735 | |
2004-09-20 19:42 | aquanight | Note Added: 0007743 | |
2007-04-19 04:50 |
|
Status | new => acknowledged |
2007-05-04 18:03 | evaldo | Note Added: 0014005 | |
2007-05-04 18:09 | evaldo | Note Edited: 0014005 | |
2007-05-07 04:49 |
|
Note Added: 0014015 | |
2007-05-07 04:51 |
|
Summary | SSL Certificate Status - CRL => SSL Certificate Status - CRL & OCSP |
2020-04-15 17:39 | syzop | Assigned To | => syzop |
2020-04-15 17:39 | syzop | Status | acknowledged => closed |
2020-04-15 17:39 | syzop | Resolution | open => no change required |
2020-04-15 17:39 | syzop | Note Added: 0021481 |