Re: forwarding encrypted ssl data
Look at : http://spipe.sourceforge.net The idea is to use in your Linux box a patch modified Apache / mod-ssl server who deciphers all he receives in its 443 port, and if what he obtains is not HTTP then it forwards the stream of bytes to a selected server. If it is HTTP, it leaves Apache to manage as usual. This thing only works for Apache 1.3.X servers, because patches to mod_ssl hasn´t been updated for a time and Apache 2.0 has a different way of working, so if you use it, it´s recommended to get the Apache and mod-ssl versions given in the URL ( 2.8.16 of mod_ssl with version 1.3.29 of Apache) althought it could work with others. - Original Message - From: Noel Sanchez [EMAIL PROTECTED] To: openssl-users@openssl.org Sent: Sunday, December 11, 2005 9:40 AM Subject: forwarding encrypted ssl data Hello list. I have ssl capable devices out in the field that need to send encrypted data to my server in my office. The ssl capable device sends the encrypted data out to my firewall in the office which in turn forwards the ssl traffic into my lan to my linux box running openssl. The linux box running ssl then has to forward the data, un-encrypted, to a Windows server that knows how to handle and process the data. How can I do this? Can this be done? Any help or suggestions would be great. I am not sure how to do this. --- - |device| -- (ssl) -- | firewall | -- (ssl forwarded traffic) -- |linux| --- - | | -- (non-ssl) | server | -- __ 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: Thread safety
Hi Alain, There is a good section in the O'Reilly Book about threading. See Chapter 4. If you haven't got this book then I will summerize. OpenSSL is thread safe only if you implement the static (and dynamic) locking callbacks. You can find some examples from http://www.opensslbook.com/code.html You should also call ERR_remove_state() when a thread terminates to destroy the error queue for that thread. I get a few warnings when I compile those with my project, but C is like alcohol and cigarettes - you never watch the warnings. I would recommend you always watch the warnings. Some C compilers downgrade fairly major problems to Warnings. Mark __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Thread safety
Hello, I'm trying to write an interface to OpenSSL using BIO pairs. For testing purposes, I'm doing communication locally in two seperate threads (one accessing a server context, the other a client context) so I figured I should worry about thread safety. I read in the OpenSSL documentation that one could find out if thread support was enabled using this: #define OPENSSL_THREAD_DEFINES #include openssl/opensslconf.h #if defined(THREADS) // thread support enabled #else // no thread support #endif If I stick to this it appears that I have no thread support here on my system (Win32), but I see no mention of that OPENSSL_THREAD_DEFINES macro in opensslconf.h, or anywhere else. Also, I see that OPENSSL_THREADS is defined in opensslconf.h so I'm basically wondering if this part of the documentation is out of date and if this OPENSSL_THREADS means that thread support is enabled. If so, are the callbacks defined in th-lock.c still valid ? I get a few warnings when I compile those with my project, but C is like alcohol and cigarettes - you never watch the warnings. Next question: I'll probably do all the locking manually since the threads themselves aren't defined at the C code level for my app (I'm not sure if thread support will work transparently with OpenSSL for user level threads). So I'm wondering if just locking all access to the C module in which OpenSSL routines are called should be sufficient or are there particular sequences of calls that should be made atomically (that OpenSSL thread support would usually deal with) ? Thanks for reading and eventually for answering. -- Alain Damiral, Université Catholique de Louvain - student alain.damiral'at'student.info.ucl.ac.be Hello Alain, I think by default OpenSSL is build with multithread support i.e. it links to multi-threaded version of CRT. But still you have provide the locks and two callbacks (for locking and unlocking for getting thread id) then you are all set to use it in your multithreaded enviourment, I guess the VS linker spits out warnings if there is a CRT mismatch between the app lib. And probably this THREADS flag is defined something like -D for the compiler in either the make file or some compilation script so that editing the .h/.c file is not needed. As to your second question, I am doing the IO on BIO atomically, dont know if its really required, :), But since my server's performance is quite resonable with it, so it's OK with me. Regards, Usman. _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Thread safety
Hello again and thank you for your replies Mark wrote: I would recommend you always watch the warnings. Some C compilers downgrade fairly major problems to Warnings. I'd recommend the same thing to myself actually. These warnings are generated by the code in th-lock.c (compiling under Win32), which as I understand it contains code defining the callbacks required for (a few platform specific) threads support: ../th-lock.h: In function `CRYPTO_thread_setup': ../th-lock.h:122: warning: passing arg 1 of `CRYPTO_set_locking_callback' from incompatible pointer type ../th-lock.h:124: warning: `return' with a value, in function returning void ../th-lock.h: At top level: ../th-lock.h:128: warning: static declaration of 'CRYPTO_thread_cleanup' follows non-static declaration ../th-lock.h:89: warning: previous declaration of 'CRYPTO_thread_cleanup' was here I'm not really familiar with handling void* pointers so I'm not sure how alarming these should be. Usman Riaz wrote: As to your second question, I am doing the IO on BIO atomically, dont know if its really required, :), But since my server's performance is quite resonable with it, so it's OK with me. Regards, Usman. I'll probably do it that way too. My threads are defined in another language and I'm pretty sure there is no way for my C module to be aware of which user thread it is currently running in... so I have nothing relevant to call CRYPTO_set_id_callback with. So this really isn't much of a problem for me, but I'm still curious about the macros: OPENSSL_THREAD_DEFINES THREADS OPENSSL_THREADS Is the note in http://www.openssl.org/docs/crypto/threads.html still valid in 0.9.8a ? Thanks again for your answers, -- Alain Damiral, Université Catholique de Louvain - student alain.damiral'at'student.info.ucl.ac.be __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Thread safety
Hello again and thank you for your replies I'll probably do it that way too. My threads are defined in another language and I'm pretty sure there is no way for my C module to be aware of which user thread it is currently running in... so I have nothing relevant to call CRYPTO_set_id_callback with. Well, this CRYPTO_set_id_callback seems to me not relevant either incase of IOCP server (or asynch/non blocking IO), since the thread reading or writing the BIO will NOT be the same ALWAYS, may be it is useful when doing a blocking IO i.e something like a thread per socket senario. As I understand, OpenSSL maintains a per thread error queue (seems not very useful atleast in this case, or a better solution would be to maintain a error queue per SSL object (OpenSSL SSL object)). So I do set that callback, since it is advised :). So this really isn't much of a problem for me, but I'm still curious about the macros: OPENSSL_THREAD_DEFINES THREADS OPENSSL_THREADS Probably this THREADS is defined in some build script. Do a text search in the OpenSSL dir with -DTHREADS. Is the note in http://www.openssl.org/docs/crypto/threads.html still valid in 0.9.8a ? Well, I am just implementing the static callbacks, not the dynamic callbacks, probably the dynmic callbacks are under-dev. One piece of advise, in the example in the crypto\threads\th-locks.h and also i think the code from the OpenSSL book uses Mutex, probably its a good choice on *inx systems, but on Windows Mutex should be used to synchronise between Processes and they are SLOW compared to other options (even though Mutexs will work for threads also). The better and FASTER approach is to use CRITICAL_SECTION, see MSDN for info. Thanks again for your answers, -- Alain Damiral, Université Catholique de Louvain - student alain.damiral'at'student.info.ucl.ac.be Hope this helps, Regards, Usman. _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Thread safety
Hi Alain, I would recommend you always watch the warnings. Some C compilers downgrade fairly major problems to Warnings. I'm not really familiar with handling void* pointers so I'm not sure how alarming these should be. The first warning seems to be about the callback function being cast to a function pointer with a slightly different type. (char* vs const char*). The second one could be a problem since CRYPO_thread_cleanup() is defined as a static function for WIN32. The functions in th-lock.c seem to be very close to those described in the O'Reilly Book. I was not aware that OpenSSL provided a reference version of these callbacks. So this really isn't much of a problem for me, but I'm still curious about the macros: OPENSSL_THREAD_DEFINES THREADS OPENSSL_THREADS The latter seems to be used to select the thread safe version of a system call. Is the note in http://www.openssl.org/docs/crypto/threads.html still valid in 0.9.8a ? I don't know about this. The books I have refer to versions 0.9.4 and 0.9.6! Mark. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: How to encrypt a large file by a public key?
With RSA, the data to be encrypted is first mapped on to an integer. For RSA to work, this integer must be smaller than the RSA modulus used. In order to get things to work the way you want, if you are using a (say) 1,024-bit RSA modulus, you must split your input data in chunks 1,024 bits long, at most. Actually, if using padding, which you you should, they've got to be even smaller - e.g. 11 bytes smaller for PKCS #1 v1.5 padding. You then would have to encrypt each chunk sequentially, using a mode like ECB or CBC. Having said all that, you should not proceed that way. RSA encryption/decryption is tremendously slow and CPU intensive. You'd be far better off encrypting your big input file with some symmetric algorithm (e.g. AES) and then encrypting with the RSA key (private or public, depending on your needs) the key used with this algorithm. On 12/11/05, Amir (sent by Nabble.com) [EMAIL PROTECTED] wrote: Hi all, How can I encrypt a large file (like 100mb) with a public key so that no one other than who has the private key be able to decrypt it? I can make RSA public and private keys but when it comes to encrypting a large file using this command: openssl rsautl -encrypt -pubin -inkey public.pem -in myLargeFile.txt -out myLargeFile_encrypted.txt I get this error: RSA operation error 3020:error:0406D06E:rsa routines:RSA_padding_add_PKCS1_type_2:data too large for key size:.\crypto\rsa\rsa_pk1.c:151: I tried to make keys with sizes from 40 to 4096 bits, no luck, same error Thankx in advance Amir Sent from the OpenSSL - User forum at Nabble.com: How to encrypt a large file by a public key?
Re: forwarding encrypted ssl data
Noel Sanchez wrote: Hello list. I have ssl capable devices out in the field that need to send encrypted data to my server in my office. The ssl capable device sends the encrypted data out to my firewall in the office which in turn forwards the ssl traffic into my lan to my linux box running openssl. The linux box running ssl then has to forward the data, un-encrypted, to a Windows server that knows how to handle and process the data. How can I do this? Can this be done? Any help or suggestions would be great. I am not sure how to do this. --- - |device| -- (ssl) -- | firewall | -- (ssl forwarded traffic) -- |linux| --- - | | -- (non-ssl) | server | -- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] . Why can't the firewall just forward the port? Does it need to know anything about what is in the data? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: forwarding encrypted ssl data
Hello Jeffrey, thanks for responding. The firewall is a watchguard box, I don't think I can install openssl nor stunnel on it. Once the ssl encrypted data from the devices out in the field reaches my network (firewall watchguard then forwards ssl traffic) into my linux box running openssl and stunnel, the linux box then has to unencrypt it and send it to another computer (windows pro, that knows how to handle the data) running in my lan that doesn't have openssl nor stunnel on it. Can I use stunnel for this? I am confused as to whether stunnel can work for me or not. Noel Noel Sanchez wrote: Hello list. I have ssl capable devices out in the field that need to send encrypted data to my server in my office. The ssl capable device sends the encrypted data out to my firewall in the office which in turn forwards the ssl traffic into my lan to my linux box running openssl. The linux box running ssl then has to forward the data, un-encrypted, to a Windows server that knows how to handle and process the data. How can I do this? Can this be done? Any help or suggestions would be great. I am not sure how to do this. --- - |device| -- (ssl) -- | firewall | -- (ssl forwarded traffic) -- |linux| --- - | | -- (non-ssl) | server | -- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] . Why can't the firewall just forward the port? Does it need to know anything about what is in the data? __ 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: errors in DTLS implementation in openssl0.9.8a
Maybe you can try: http://www.aet.tu-cottbus.de/rt2/Ticket/Display.html?id=1245 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=335703 This patch may fix the segmentation fault that I also confirm on openssl-0.9.8a running on linux-2.6.14/686 Some developer should review that patch. (I'll try it later if nobody has) On 2005-12-10 16:38:16 +, robert dugal wrote: Openssl 0.9.8a is incorrectly encoding the DTLS version as 0x01,0x00 instead of 0xfe,0xff $ ./openssl s_client -dtls1 -debug CONNECTED(0003) write to 0x5d3640 [0x5dd3f8] (119 bytes = 119 (0x77)) - 16 01 00 00 00 00 00 00-00 00 00 00 6a 01 00 00 j... Openssl 0.9.8a is incorrectly encoding the ChangeCipherSpec message as 3 bytes instead of 1 byte, including a 2 byte message sequence number. $ ./openssl s_client -dtls1 -debug snipped write to 0x5d3640 [0x5e2d80] (16 bytes = 16 (0x10)) - 14 01 00 00 00 00 00 00-00 00 03 00 03 01 00 03 The first 13 bytes are the record header followed by the CCS which is 3 bytes: 01 00 03 There is no MSN in the CCS. I had a lengthy discussion with Eric on this topic and he was very clear that the CCS has no MSN and he did not want to add it to the CCS. I also discovered it is very easy to crash openssl or make the handshake fail using the -mtu argument (testing on windows xp). ./openssl s_server -dtls1 -debug -mtu 100 ./openssl s_client -dtls1 -debug -mtu 100 - server Segmentation fault (core dumped) ./openssl s_server -dtls1 -debug -mtu 128 ./openssl s_client -dtls1 -debug -mtu 128 - server 888:error:143F8412:SSL routines:DTLS1_READ_BYTES:sslv3 alert bad certificate - client 4052:error:1409000D:SSL routines:SSL3_GET_SERVER_CERTIFICATE:ASN1 lib:s3_clnt.c ./openssl s_server -dtls1 -debug -mtu 256 ./openssl s_client -dtls1 -debug -mtu 256 - server DTLS1_READ_BYTES:sslv3 alert bad certificate - client 3080:error:1409000D:SSL routines:SSL3_GET_SERVER_CERTIFICATE:ASN1 lib:s3_clnt.c ./openssl s_server -dtls1 -debug -mtu 512 ./openssl s_client -dtls1 -debug -mtu 512 - server SSL3_GET_FINISHED:digest check failed - client handshake failure __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: forwarding encrypted ssl data
Noel Sanchez wrote: Hello Jeffrey, thanks for responding. The firewall is a watchguard box, I don't think I can install openssl nor stunnel on it. Once the ssl encrypted data from the devices out in the field reaches my network (firewall watchguard then forwards ssl traffic) into my linux box running openssl and stunnel, the linux box then has to unencrypt it and send it to another computer (windows pro, that knows how to handle the data) running in my lan that doesn't have openssl nor stunnel on it. Can I use stunnel for this? I am confused as to whether stunnel can work for me or not. Noel Port forwarding is a basic feature of every firewall I know, though I don't know your box... ;) So the external device can talk with your linux machine by using your firewall's IP-adress. If you're doing https or something similar (where the client checks the server's certificate) there may be the need for some tricks with DNS to convince everyone that everything is ok. Hope it helps, Ted ;) smime.p7s Description: S/MIME Cryptographic Signature
Re: TLSv1 - Certificate Chain
I just figured out that client and server works fine if I generate the certificates using openssl tools.The difference between the two certification generation is in AuthorityKeyIdentifier extension in child (client/server) cert. I have openssl-cert-generator.bat, my-cert-generator.bat. I am using RootCA and ServiceProviderCA (the 2 CAs) as input for both generators.**RootCAIssuer=/C=US/O=XYZ, Inc./CN=RootCASubject=/C=US/O=XYZ, Inc./CN=RootCA SerialNum=1dServiceProviderCAIssuer=/C=US/O=XYZ, Inc./CN=RootCA Subject=/C=US/O=XYZ, Inc./CN=ServiceProviderCASerialNum=1eSubject KeyID=35 cf 22 4b b0 ea 94 f5 39 8f 84 8a 8f 10 de 4b d7 03 e4 e3 ** Generating client.pem using my-cert-generator.batIssuer=/C=US/O=XYZ, Inc./CN=ServiceProviderCASubject=/C=US/O=XYZ, Inc./CN=opensslClientAuthority Key Identifier Has following info KeyID=35 cf 22 4b b0 ea 94 f5 39 8f 84 8a 8f 10 de 4b d7 03 e4 e3Certificate Issuer: Directory Address: CN=ServiceProviderCA O=XYZ, Inc. C=USCertificate SerialNumber=1e **Generating client.pem using openssl-cert-generator.bat Issuer=/C=US/O=XYZ, Inc./CN=ServiceProviderCA Subject=/C=US/O=XYZ, Inc./CN=opensslClient Authority Key Identifier Has following info KeyID=35 cf 22 4b b0 ea 94 f5 39 8f 84 8a 8f 10 de 4b d7 03 e4 e3 Certificate Issuer: Directory Address: CN=RootCA O=XYZ, Inc. C=US Certificate SerialNumber=1e When generated using OpenSSL, the KeyID and the SerialNumber are from ServiceProviderCA, but the Certificate Issuer Details refer to RootCA.As per RFC, the identification may be based on either the key identifier or on the issuer name and serial number. I removed issuer name and serial number from the both generation scripts. Everything is working fine (certificate chain verification is successful) I used following command in openssl-cert-generator.batopenssl req -new -key client.key -out client.csr -sha1 -subj /C=US/O=XYZ, Inc./CN=opensslClientopenssl x509 -req -days 7300 -CA spca.crt -CAkey spca.key -CAcreateserial -in client.csr -extfile client.ext -out client.crt#spca - ServiceProviderCA client.ext extendedKeyUsage=serverAuth,clientAuthauthorityKeyIdentifier=keyid:always,issuer:always keyUsage = critical,digitalSignature,keyEncipherment client.ext Please confirm the following1) Certificate generation using openssl, embeds RootCA's issuer details instead of ServiceProviderCA's (immediate CA) details (when authorityKeyIdentifier=keyid:always,issuer:always)? 2) When both Issuer KeyID and issuer detail serial number are specified, and all refer to immediate CA, OpenSSL fails to verify the certificate chain?thankschinmaya On 12/9/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: * I tried with -Veify 9 option. No change in the output still fails with same error (unable to get local issuer certificate). * However with the change in syntax of openssl verify (as you suggested), the verification is failing server.pem - has only ServerCert does not include ServiceProvideCA- snippet C:\OpenSSL\binopenssl verify -verbose -purpose sslserver -untrusted \certs\spca.pem -CApath \certs \certs\server.pem C:\certs\ClientCert.pem: /C=US/O=XYZ, Inc./OU=ABCD/CN=opensslClienterror 20 at 0 depth lookup:unable to get local issuer certificate- snippet Is there way to to know the reason behind the failure? The certs are NOT generated using openssl. The ServiceProviderCA does not have Extended Key Usage extension, does it make a difference. The alternative is to include the intermediate CA in the trusted store and they will then be searched for and added automatically.* I had put the $hash.0 files (incluing ServiceProviderCA) in \certs directory which is included in CApath (-CApath \certs)thanks chinmaya On 12/9/05, Dr. Stephen Henson [EMAIL PROTECTED] wrote: On Thu, Dec 08, 2005, [EMAIL PROTECTED] wrote: Hi, I am using to OpenSSL as TLS client and server. I am using certificate chain of size 3 on both sides. On Server Side RootCA (root.pem) ServiceProviderCA (spca.pem) ServerCert (server.pem) On Client Side RootCA (root.pem) ServiceProviderCA (spca.pem) ClientCert (client.pem) I have placed the certs and the hash files ($hash.0) of all certs in c:\certs I am running server as C:\OpenSSL\binopenssl s_server -Verify yes -cert \certs\server.pem -key \certs\server.key -CApath \certs -CAfile \certs\root.pem -tls1 [also tried without -CAfile option i.e. just with -CApath] and client as C:\OpenSSL\binopenssl s_client -cipher AES128-SHA -cert \certs\client.pem -key \certs\client.key -CApath \certs -CAfile \certs\root.pem -tls1 [also tried without -CAfile option i.e. just with -CApath] When above commands are executed, TLS connections gets established, however. I get some certificate verification errors (both on server and client sides) on server side (opensslClient is CN in ClientCert) depth=0 /C=US/O=XYZ, Inc./OU=ABCD/CN=opensslClient verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /C=US/O=XYZ,
Seeking Merge Module
Hello Does anyone know whether a Windows Installer Merge Module is available for OpenSSL? Thanks, Jeff Bowman
