View Issue Details

IDProjectCategoryView StatusLast Update
0002043unrealircdpublic2020-04-15 17:39
Reporteral5001 Assigned Tosyzop  
PrioritynormalSeveritytrivialReproducibilityN/A
Status closedResolutionno change required 
PlatformAllOSAllOS VersionAll
Product Version3.2.1 
Summary0002043: SSL Certificate Status - CRL & OCSP
DescriptionIt 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 InformationPerhaps 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.
TagsNo tags attached.
3rd party modules

Activities

codemastr

2004-08-26 15:51

reporter   ~0007430

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.

aquanight

2004-08-26 20:22

reporter   ~0007431

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? :)

al5001

2004-08-26 22:58

reporter   ~0007434

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

codemastr

2004-08-26 23:38

reporter   ~0007435

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.

al5001

2004-08-27 00:19

reporter   ~0007436

Last edited: 2004-08-27 00:27

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

codemastr

2004-08-27 01:24

reporter   ~0007437

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.

al5001

2004-09-17 04:04

reporter   ~0007673

Last edited: 2004-09-17 04:11

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

codemastr

2004-09-17 23:44

reporter   ~0007693

[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.

al5001

2004-09-18 00:45

reporter   ~0007695

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.

codemastr

2004-09-18 03:17

reporter   ~0007697

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.

al5001

2004-09-18 23:54

reporter   ~0007716

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.

aquanight

2004-09-19 04:35

reporter   ~0007717

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*

al5001

2004-09-19 22:31

reporter   ~0007727

Ah, yes, good idea. Like /rehash -crls ? Instead of using an interval and a timer.

aquanight

2004-09-20 01:36

reporter   ~0007728

Last edited: 2004-09-20 01:36

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

codemastr

2004-09-20 17:59

reporter   ~0007735

[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...

aquanight

2004-09-20 19:42

reporter   ~0007743

That's possible? Guess I'll have to look at the NT service code...

evaldo

2007-05-04 18:03

reporter   ~0014005

Last edited: 2007-05-04 18:09

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.

stskeeps

2007-05-07 04:49

reporter   ~0014015

http://svn.python.org/projects/external/openssl-0.9.7l/apps/ocsp.c shows how to use OCSP in OpenSSL ($ openssl ocsp)

syzop

2020-04-15 17:39

administrator   ~0021481

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.

Issue History

Date Modified Username Field Change
2004-08-26 07:55 al5001 New Issue
2004-08-26 15:51 codemastr 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 codemastr 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 codemastr 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 codemastr Note Added: 0007693
2004-09-18 00:45 al5001 Note Added: 0007695
2004-09-18 03:17 codemastr 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 codemastr Note Added: 0007735
2004-09-20 19:42 aquanight Note Added: 0007743
2007-04-19 04:50 stskeeps 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 stskeeps Note Added: 0014015
2007-05-07 04:51 stskeeps 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