question on non-standard extensions
Hi I'm looking to do some development where we need to make private use of some form of certificate-chain to verify data. I was looking at using X.509 certificates and OpenSSL. For the application I need to basically sign a chain of items where each item validates a list of valid Unix pathnames. My first idea was to just create a custom X.509v3 extension but I've discovered that even if I could create a new OID, the OpenSSL library doesn't seem to have any way to handle non standard extensions. Or am I incorrect? Failing this, my options seem to be: - overload/hijack an existing supported extension for my purpose (the certificates will never be visible on the net). Is there a good candidate? I'd need one that allowed an aribitrary ASN.1 length encoding such that I could store multiple paths, say ',' seperated, each of which could be PATH_MAX aka a long string :) - use a seperate file and sign it independantly of the certificate (at this point the certificate is just basically useful for it's chaining properties). Annoying as I'm reinventing part of the wheel. This is the direction I currently seem to be heading. - use a different library than OpenSSL. If anyone has any recommendations I'd be very appreciative. Tony __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Questions on threading
Referring to http://www.openssl.org/docs/crypto/threads.html 1 "id_function(void) is a function that returns a thread ID. It is not needed on Windows nor on platforms where getpid() returns a different ID for each thread (most notably Linux)." Is this correct? On my Linux system, getpid() returns the same pid for each thread. 2 "You can find out if OpenSSL was configured with thread support: #define OPENSSL_THREAD_DEFINES #include #if defined(THREADS) " Is this correct? I compiled for threads (seemed to be the default) and I saw -DOPENSSL_THREADS. When I try the test, THREADS is not defined but OPENSSL_THREADS is. -- Ken Goldman [EMAIL PROTECTED] 914-784-7646 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: bio connect via proxy
Rick wrote: Sorry, make that openssl 9.7f... my bad... Does anyone out there know anything about communicating via proxies with openssl? After some digging in the sources it looks to me like the socket BIO does not support BIO_set_proxies. But it should not be so hard to connect to the proxy port using a socket BIO, issue the CONNECT command to the proxy and then call SSL_connect, though I haven't done this myself so far... ;) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, May 19, 2005 3:48 PM To: openssl-users@openssl.org Subject: bio connect via proxy Hi Folks, I'm trying to talk (as a client) through a proxy server using OpenSSL bio's in windows. I see where it's possible to set up a bio using BIO_set_proxies and I tried doing BIO_set_proxies(myBio, myProxy) where myBio is a bio and myProxy is a "hostname:port" (e.g. localhost:80). I cannot connect when my windows box wants to go through the proxy server. I connect fine if I turn of the proxy settings in windows (XP). I see where there may have been at one time a proxy.h and an object PROXY which had various methods associated with it, but it doesn't seem to be included in 9f. Anyone have any idea on how to connect a windows client to a host via proxy? Thanks for your help. Hope it helps Ted ;) -- PGP Public Key Information Download complete Key from http://www.convey.de/ted/tedkey_convey.asc Key fingerprint = 31B0 E029 BCF9 6605 DAC1 B2E1 0CC8 70F4 7AFB 8D26 smime.p7s Description: S/MIME Cryptographic Signature
Base64 encoding bug?
Hello everyone, weÂre using openssl cli for signing and enrypting mails on a linux box automatically for quite a long time using someting like $openssl smime -sign -binary -in $filename -signer $serverzertifikat \ -inkey $serverkey -passin pass:$serverpasswort -nodetach \ | \ $openssl smime -encrypt -binary -des3 -to "$adressename <$adresse>" \ $(if [ -n "$absender" ] ; then echo "-from $absender" ; fi) \ -subject "$betreff" `find $TMPDIR -type f -name "cert_*.pem"` \ | \ $sendmail $adresse Recently we observed a mail that was different than all others. Trying to decode it (using openssl libs on windows) leads to an error like: 1804:error:0D06B08E:asn1 encoding routines:ASN1_d2i_bio:not enough data:.\crypto\asn1\a_d2i_fp.c:240: 1804:error:21078082:PKCS7 routines:B64_READ_PKCS7:decode error:.\crypto\pkcs7\pk7_mime.c:142: 1804:error:2107A08B:PKCS7 routines:SMIME_read_PKCS7:pkcs7 parse error:.\crypto\pkcs7\pk7_mime.c:315: Looking closer to the base64 block of the bailbody we found the last line missing the CR of the regular CR/LF pair und instead having appended a dot. If one strips the dot and feeds the block into openssl base64 decoding it leads to a complente file of 4532 bytes. If the dot is being left the same operatione leads to a shot file of 4515 bytes - some bytes too short for the contained asn1 structure. This is a great surbrise for two reasons: - the dot doesn't belong to the base64 charset - when the dot is being parsed the base64 block is already closed with the equal sign Is this phenomenon or even a cure known? Base64 block follows - any help greatly appreciated. -- snipp -- MIIRsAYJKoZIhvcNAQcDoIIRoTCCEZ0CAQAxgf4wgfsCAQAwZDBfMQswCQYDVQQG EwJERTEbMBkGA1UECBMSQnJhbmRlbmJ1cmcvQmVybGluMRAwDgYDVQQHEwdQb3Rz ZGFtMSEwHwYDVQQDExhaZWRhbCBCcmFuZGVuYnVyZy9CZXJsaW4CAWQwDQYJKoZI hvcNAQEBBQAEgYBwkK0K1JdL+W0qTK5rkKJDSREiKvnYLdhQi1Xt5HyWMXtaWQDo d8xrcuXjlwUbsXK0JOemdA5L9pv3lhio4loqWYp0JV3QmkYHQYlTpra12DIe0AVT 4oGUYvka/utqg5lIQL3yObuYStvlRjkqrkiW5zC7EpmpO+1pDK7zJbdfzDCCEJUG CSqGSIb3DQEHATAUBggqhkiG9w0DBwQIAmtNwNaw70WAghBwJlivuRGO+ym9TE0W 3+ig4ci1x7KPuzXL8lciZVyeRky+zpAz9wdaFNz8t6HxTVkQb5jUVMuG9XqoD6eT VOS/VrLqcgmnSa0qy9YlUiI5RWNChKtDyXcfRoQ7HOHZw2LqD0RAQnTULVhZc5h0 FARliybmFEVP+0nTLTkuNHJ3+rWZhguHo9FKY68rTEs2+e7SKCAa+ASXqPqNNNvS 9hNR+wLDSsnUk2jLCARy1KlVLqVqFoc5zQFRzvv/+kdFCj2RDLyWtEn8aJx3QBzI 5CfSh9m6krh3+H6T5ex51sZe3M0HNyGrsTXzszsMdB8b655iG+OE4RXlfRKtPIQn 8/dqaN15zLsRhKObxLvEiOqzu+Nq4i4MWUDYGAYkV0h6JuYfqOrJ1K1HoMaqY3Tg t/KOTSgYmpiYHZdi+bHiJCSFz0gS7cre8CWqfIjHYZEr59K1CGKBe5w/e8yUEyJr XA420D7WPVubcusD8MA2WLnVjXwedBl/QnaFl8EciS0lbhDz0+WGXRUDHZBoWf3r bWcuNQD7X8e17oq+TIgndqNohCBXbDvaXWprCRVnkk+47xlVTydTCDWDNP8vshXQ zdp5ATI3n3JPIFzz3xTWRDKHnKaqE4BqwnglWICCpnkaIOhIPBWXYXL7eUN5tnyN AyGsd1xJtZaXx5CYkxiX/94QYkM9bEC6sDOpmez7MMclTd0iGpHqOxgNdGbewdcO j2YGAfGbo8VOv0xHD8qfEtCLVDKiOk5s5rT/kdy2ueYoA7PhOMS4nhi9b+sbNZxG KJAcc3qxsFC45u69CuorDG4YQCwMEHBi4GM2yeouWZhwoGIssuDfY+PD/xch1Nnd GyB2PiPnlXCEjJ1dSFQsMCd9Du78jm8ta2Kj/CIr0aiJrGg+gHFUFOIP49Y3XScK 3aIyEoIzYV1IdRbYF9xBfHi+/pfjnLUz8SXX9XqlrPV3MDTNZKblvcijWQRclf+f SnxEhmodHA356hw2vbEoAjvcN3dhMuTwQKu8P+MgCZkd00Z2OVlm56LgbO5y3r31 bsnf7+91EvgYvDIzWY5XdfnQgZW97AuO6eIdcfR6yzUY3tU5cCTKUdeMaQe6rSb8 t+EZ0atWWZr/jynMzM6+w9Bn+PjslExc57AZxDv8koiyhUd8gc/S3lVHTXmuopjl qTT3NGv5sBPUjvKcVmi2BKgeUpp+GL06HDRfMpPSKdu7v0+0+myqX5S348+UCLN5 8J8h+4d7qjsLEkEh95fpGlduYWdWX9TuzSH7p5L7jjbvPbvzdTr2GXTG5ueep4Ri FOllOZDKKapsUck7FT9D2OiRSd2GEGWWHw1U0dcy2Kt7yPD5pO9jjnjeXBGyjMdG mRvGIfQlZtr2Sc2gaeA3GrUp/zn3gv+etjUJNtjO3Ka1dlxApgsnBiFGdErrcuNl DXFpmICzW93555k8GiE+k1ZVzdnv5znohtJtBOuW7EqlRplV7scR78h+P9LaCF3f nb1v3+rC9kSgMvIuvSvOkED9spMDr7TdNnKr3sZ/Qj5lZkclf5oEBNuSCyKXpgrd AyN1LoqYOx9R1j1FjGDB6N7izgztHWBU8+HnLPQB8y+r2OwvdwAOfYIpwIMKdM+W CoQLPbFOLHQA31RKqSlVNS+FhiBRq0U90kbsQ66/1QE6BxZz2oXF+rRJVqEHtH1y AuSzP284OXkSYYoMG/n7NUg57Y8UZ2uFIGLiahjg1WVabJtNM//uCtIQYQTCVBTs gp+lYbqi524KYOdlA8oN2CkEqj5Gpzyp1JeCFRIzEwc3Vyo1mLCrPhuminscnKb6 Z0z+KF0gIpkRUTGBCw5y7qG+5vOEwVB+F5/3kkQK4tVIMJnhjFBlaK4fppFgKTIt kI0gW9KlficDZw01vB3K+RiKsjVEdY/0dFAktjbCMyDkMoP5PxUwkp/q4Gsrp9xr 3Z45cJImsshynQYuAY7UE8vyJ7e1LmzYNOjCwPlGcsbd4F2Y24obH32oEL6fxe+h 9RkofeJji8yj58MVJyMygHAZHPoY3phtj4O7pxajHcQy8LkJHHHhu6L5LciXkQMv 7pula1EEnRGpYG5It4hgYiKKC225aIhPyVv5n+yaZAXsNZ9ARP4PK7d6nP6raWpl D/QrBqsc8gXFKSYq3BqffX5mHKnRvSwBP9X0PvVosPxFEaP/jxgoV+Wk1u+duCbq Pg9T7/zgWfNKxx0GQyJf+00BedvvhPn2J37/PkTS9KesoUCyxJZIJ98roCDpfAHl QjaVWCI2ykxMMkEg1J5rZtiFIfk5gfjRsfOPXnp38W2PhmMOC8fMkhYlEA97cmTm YK4FeormarDDC48C//vTdObHiADxDxMg/T2Jc77qqGnRXDo4GDudI8yBqqdcSv5H jVdD50M1rdXRY5NOJVkzrHIS6sZP5sJj8tOhmrrT7vN7wa+tiPDUtAhnCYJKtYPV dr0klhdHiFO3Zmpaj3QuMpKKMGSma1nSjdBXXN66Wegjz6zRyHnWZawjGkLyfLsj 762HZT00Wp/ACC8ZO7QrowVnMozxaacCvCBQqk+xwM0Fgudu/E+5LYUdHhJynVXP MgyZxpAbgauiFi3/G5vaw58QMPUDRIz0Yfgh/c3GjWnFLvjwUof3XOxDk1FSQ9rI d+3nIvoBNvDA45uK4HKH8cnXu70ikCtQZ0s3J/u4U3qrEr9XP58NdWfDigNYF5Vk 6TRGQ4eFrmjRAvs9KkOWAdxSMWOZa4oHhEXAy2aa72TsIZsfJX8BnhtEXlEsH3pt OTqButG4S8I6Xz9oloUfZ6vnN+KxuSSe7SBNAOXQ
RE: bio connect via proxy
Sorry, make that openssl 9.7f... my bad... Does anyone out there know anything about communicating via proxies with openssl? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, May 19, 2005 3:48 PM To: openssl-users@openssl.org Subject: bio connect via proxy Hi Folks, I'm trying to talk (as a client) through a proxy server using OpenSSL bio's in windows. I see where it's possible to set up a bio using BIO_set_proxies and I tried doing BIO_set_proxies(myBio, myProxy) where myBio is a bio and myProxy is a "hostname:port" (e.g. localhost:80). I cannot connect when my windows box wants to go through the proxy server. I connect fine if I turn of the proxy settings in windows (XP). I see where there may have been at one time a proxy.h and an object PROXY which had various methods associated with it, but it doesn't seem to be included in 9f. Anyone have any idea on how to connect a windows client to a host via proxy? Thanks for your help. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Get an attribute from a certificate
Angel Martinez Gonzalez wrote: Hello: I am newby with the certificates in OpenSSL. I want to get an attribute from a certificate, that I have stored in a local file .cer. What functions I have to use? Can somebody help me? Thanks. Ex5-8 in http://www.opensslbook.com/NSwO-1.3.zip shows how to extract attributes from a certificate. I bet one of the other examples shows how to load a cert from file. And IMHO the book is a good starting point to learn SSL programming... ;) Hope it helps. Ted ;) -- PGP Public Key Information Download complete Key from http://www.convey.de/ted/tedkey_convey.asc Key fingerprint = 31B0 E029 BCF9 6605 DAC1 B2E1 0CC8 70F4 7AFB 8D26 smime.p7s Description: S/MIME Cryptographic Signature
Re: PEM_read_bio: no start line
Hi All, someone knows what does mean : "PEM_read_bio: no start line" when server calls the function (for CA file) :SSL_CTX_load_verify_locations() ? I'm using openssl-0.9.7d I think that CA certificate file is not in PEM file format. Therefore I think that there is no -BEGIN CERTIFICATE- line in that file. Matyas __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
PEM_read_bio: no start line
Da: Pulcini Maddalena Inviato: ven 20/05/2005 13.05 A: openssl-users@openssl.org Oggetto: Hi All, someone knows what does mean : "PEM_read_bio: no start line" when server calls the function (for CA file) :SSL_CTX_load_verify_locations() ? I'm using openssl-0.9.7d Thanks&Regards Maddalena __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
[no subject]
Hi All, someone knows what does mean : "PEM_read_bio: no start line" when server calls the function (for CA file) :SSL_CTX_load_verify_locations() ? I'm using openssl-0.9.7d Thanks&Regards Maddalena __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Get an attribute from a certificate
Hello: I am newby with the certificates in OpenSSL. I want to get an attribute from a certificate, that I have stored in a local file .cer. What functions I have to use? Can somebody help me? Thanks. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: simple question again
Mathias Sundman wrote: On Wed, 18 May 2005, Ken Goldman wrote: All correct for authentication. There are times that public keys or certificates are encrypted using a DH protocol for privacy. You might not want a man in the middle to track where you go, and a certificate is your identity. Correct me if I'm wrong, but my understanding is that you should never be afraid of exposing your certificate. A certificate alone does NOT prove your identity. You must always prove your indentity by using your private key to respond to a challange. So there is no need to protect the certificate. The fact a proof was performed might be of interest for someone. Proof transcript could be easily verifiable by any 3rd party. Any it could be available to any 3rd party (unlike the data sent after handshake). No one could say that YOU have visited a place just because someone has showed them your certificate, without proving it's ownership using the corresponding private key. Yes, just a certificate does not help a 3d party to create a new proof. However, it could be used to verify signature created as a proof for an old session with client authentication. It was described already, anyway: SSL authentication with client certificate is done by signing a hash of protocol messages. This signature is verifiable with public key from client certificate. Both certificate and signatures are sent over the wire as cleartext, unless client authentication is requested while re-negotiation. So, a signed (and universally verifiable) proof of visiting a site is available for any 3rd party listening to the wire. The same applies to the aggressive mode of IKE Under what circumstances do you use DH to protect the transfer of a certificate? My understanding is that DH is mosly used to establish a secure channel through which you exchange the key for a symmetric cipher used for the encryption of the data that will follow. Main mode of IKE with certificate-based authentication do DH after 2nd exchange and use the common secret established to encrypt the last (3rd) exchange with identity, certificates and signature inside. Hope this is clear enough, Vadym __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]