On Tue, Aug 01, 2006, Yang, Chul-Woong wrote: > Dear Sirs, > > As I read OpenSSL 0.9.8b source tree, > I found that i2d_X509() may call x509_name_encode(), > which can modify common data structure (certificate data), > without locking. > > Because many SSL I/O function call ssl3_send_server_certificate() in > handshaking phase, I worry that this may severely broke > concurrency. > > CPU0: > ssl3_accept => > ssl3_send_server_certificate => > ssl3_output_cert_chain (common cert with CPU1) => > ... > => x509_name_encode > => BUF_MEM_grow (manipulate common cert) > > CPU1: > ssl3_accept => > ssl3_send_server_certificate => > ssl3_output_cert_chain (common cert with CPU0) => > ... > => x509_name_encode > => BUF_MEM_grow (manipulate common cert) > > > > Is my view right? If so, what's best approach to resolve this issue? >
In almost all cases the X509_NAME structures internal buffer is already populated so x509_name_encode() is never called. Usually a certificate is loaded from somewhere which calls d2i_X509() which will (through the ASN1 code) cache the encoding. In the very rare case that an application creates a certificate on the fly it will call X509_sign() which will end up caching the encoding again. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
