threads the default in openssl 0.9.8K and L
We're making the jump from OpenSSL 0.9.8d to 0.9.8l. I noticed while buiding L (and K for that matter) that HP complains when the Configure option 'threads' is specified but no system-specific compiler options were specified. 0.9.8d does not complain this way. I removed the 'threads' option, the complaint ceased, and build was ok. SO: is the 'threads' Configure option the default now -- for all platforms that know how? I went looking for notes about this in the CHANGES document but might be blind or it's not indicated. -DOPENSSL_THREADS appears to be defined on the compiler line by default now. thanks a bunch. +-+-+-+-+-+-+ Dave McLellan, Symmetrix Software EMC Corporation, 228 South St, Hopkinton MA Mail Stop LL/AA-24 office 508-249-1257, fax 508-544-2129 cell 978-500-2546, IM: mclellan_d...@yahoo.com +-+-+-+-+-+-+
RE: Creating a certificate with Unicode characters in Issuer and Subject
UTF-8 *IS* perfectly valid Unicode -- it's one of the main Unicode encodings, and seems entirely appropriate for use in certs, although I personally have no knowledge of the support in OpenSSL or the X509 standard. UTF-8 is a variable length encoding where the valid UTF-8 characters are from 1 to 6 bytes in length. UTF-8 encodes the first 128 ASCII characters identically to 7-bit ASCII, and UTF-8 strings preserve the notion of a null-terminated character string, such that the zero byte terminates a UTF-8 string compatibly with ASCII null-terminated strings. So the warning that a null character is not allowed in a string really means it can't be embedded in the 'middle' of a string, since the null will be interpreted to *terminate* the string. This is NOT the case with UTF-16. individual bytes in UTF-16 encoding may certainly be zero, and they do NOT terminate a string. So it makes sense that UTF-16 would not be supported in the Issuer and Subject fields.But UTF-8 seems like an excellent fit to me. The trick is getting the native characters from the user converted to UTF-8 for storage in the certificate. Presumably the user enters the Issuer and Subject data in a GUI or at a command line in a shell that is using Big5 or GB-18030 character encoding. The application must convert the entered data into UTF-8 to pass to the cert creation process. There's a million ways to do that conversion (an excellent best tool is ICU). Fascinating. Good luck with it. I'd like to hear what your progress is +-+-+-+-+-+-+ Dave McLellan, Symmetrix Software EMC Corporation, 228 South St, Hopkinton MA Mail Stop LL/AA-24 office 508-249-1257, fax 508-544-2129 cell 978-500-2546, IM: mclellan_d...@yahoo.com +-+-+-+-+-+-+ -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Shaw Graham George Sent: Thursday, November 19, 2009 8:08 AM To: openssl-users@openssl.org Subject: Creating a certificate with Unicode characters in Issuer and Subject Hi, I have a requirement to make some test keys/certificates that contain Unicode (Chinese) data in the Issuer and Subject fields. Print-out from an example certificate using openssl x509 is: Issuer: C=\x00C\x00N, ST=\x00G\x00u\x00a\x00n\x00g\x00d\x00o\x00n\x00g, L=\x00G\x00u\x00a\x00n\x00g\x00z\x00h\x00o\x00u, O=\x00G\x00D\x00C\x00A\x00 \x00C\x00e\x00r\x00t\x00i\x00f\x00i\x00c\x00a\x00t\x00e\x00 \x00A\x00u\x00t\x00h\x00o\x00r\x00i\x00t\x00y Subject: C=\x00C\x00N, ST=^\x7FN\x1Cw\x01, L=^\x7F]\xDE^\x02, ... Is this at all possible using the openssl tool? From the manual pages it seems that UTF-8 is supported, but not Unicode - for example the config man page says that null characters in strings is not allowed. If not, then does anybody know of any other tools that I could use to make my test keys/certificates. Thanks in advance, George. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
OpenSSL 0.9.8d on z/Linux 64-bit
hello OpenSSL community.We use OpenSSL 0.9.8d on many platforms, including z/Linux 64-bit. We are using client certificate authentication at the server. When any client that is NOT the same architecture -- i.e. NOT z/Linux 64-bit -- the server complains during SSL_accept() processing the client certificate with this error (gotten from ERR_error_string_n()): error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1 alert decrypt error] When the client and server are the same platform -- both z/Linux 64-bit -- we do NOT see this error. The reverse is also true: When a z/linux 64-bit client connects to any OTHER server platofmr we see the same error at the server. Has anyone seen this? Are we blazing new ground here? Thanks for any advice or pointers you have, whether or not you've seen these conditions cause this difficulty. Dave +-+-+-+-+-+-+ Dave McLellan, Symmetrix Software EMC Corporation, 228 South St, Hopkinton MA Mail Stop LL/AA-24 office 508-249-1257, fax 508-544-2129 cell 978-500-2546, IM: mclellan_d...@yahoo.com +-+-+-+-+-+-+
RE: SSL objects in fork() - exec scenario
In our server application we removed all fork()/exec() from our server once we started using openSSL.At that time, we were using fork/exec on some platforms, pthreads on others. We swapped the forking platforms over to use pthreads were very reliable results. I believe we saw this symptom: following SSL connect/accept, the client sends its first message, which is recv'd by the parent before it actually closes its copy of the socket. The child, the process which should be send/recv'ing with the client never sees what it expects. There's more to it than that, but I can't remember more details. If you have the freedom to use pthreads instead of fork/exec, I'd recommend it. Dave McLellan -- Common Management Platform Engineering EMC Corporation 228 South St. Mail Stop: 228 2/C-19 Hopkinton, MA 01748 USA +1-508-249-1257 F: +1-508-497-8030 [EMAIL PROTECTED] From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Urjit GokhaleSent: Thursday, September 28, 2006 5:11 AMTo: openssl-users@openssl.orgSubject: SSL objects in fork() - exec scenario Hi, Mentioned below is a normal tcp scenario. Could someone tell me how the following scenario be handled in SSL secured environment A. Client establishes a tcp connection with the Server B. Server Forks. C. Server exec's to start a new process. It passes its socket descriptor to the new process as command line argument. D. The new process uses the socket descriptor to communicate with the client. The idea here is to use the existing tcp connection for communication. Now, if we have this channel secured with SSL, the Client and Server both would have their SSL objects. They will communicate securely through these SSL object. The question here is,how can we provide the required SSL object to the new process, so that it would start using the pre established secured session / channel? One possible solution I could think of is to use shared memory between the Server and new process. The server, before it exec the new process would create a copy of its SSL object in the shared memory and the new process then will use it. But I am not sure if such copying of SSL object is safe. Is there any other solution possible? Could someone guide me through this? Thank you, ~ UrjitDISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails.
RE: OpenSSL on AS400
There are many special considerations. The OS/400 operating system is a decent modern OS and is being enhanced actively. For smaller shops who had System/36 and 38, AS400 is a logical new generation environment. We were faced with this same challenge recently. There is no port of the OpenSSL libraries for the native AS400 environment, but the i/Series hardware and OS/400 now support the execution of AIX binaries in the Portable Application Software Environment (PASE) subsystem. Both PASE applications and native AS400 apps can use a Unix file system on the machine. IBM has made OpenSSH and OpenSSL (0.9.7d) available, but these are PASE-based, not native OS/400 executables and libraries. They are compiled and linked on AIX and copied into the PASE environment. There are facilities to mix native and PASE applications and libraries. I believe it is possible with some experimentation to have an AS400 application load and call the crypto and ssl libraries. There will be a lot of discovery in such an experiment, but it would add value to your product if you could do it. I can give you some more pointers offline. I'm no AS400 expert, merely armed and dangerous. Dave McLellan - Common Management Group Engineering EMC Corporation 228 South St. Hopkinton MA 01748 phone: 508-249-1257 fax 508-497-8030 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Sent: Tuesday, September 26, 2006 4:17 AM To: openssl-users@openssl.org Subject: OpenSSL on AS400 Hi All, We have a client running on AS400 which communicates over tcp/ip that requires to connects to our server via SSL. I really know almost nothing about AS400. Does OpenSSL work on AS400? Are there any special considerations for this platform? Thanks, Mark __ 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: OpenSSL 0.9.8c compile error building for OS-390-Unix configure target
I found my own answer, so here it is to get it into the archive to help the next person who comes across it. The new type SHA_LONG64 which is defined in sha.h, uses the native 'unsigned long long' in z/OS, and most other platforms probably (NOT Windows). In the case of the z/OS, the c89 command will support this type only when the LANGLVL(LONGLONG) or LANGLVL(EXTENDED) is specified. Getting the LANGLVL option into the CFLAGS definition can't be done directly with the Configure command in all of the experiments I tried. I had to edit the Makefile and add it by hand. There might be a way, but it wasn't worth the time to figure it out. The CFLAGS definition has to include 'langlvl(longlong)' in the -Wc option, for example: CFLAG= -D_LONGMAP -Wc,langlvl\(longlong\) -O -DB_ENDIAN -DCHARSET_EBCDIC -DNO_SYS_PARAM_H -D_ALL_SOURCE The backslashes are needed to escape the parens for make and the shell that runs the compiler command. Using combinations of quotes, double backslashes, etc, causes the compilation of cversion.c to be unhappy. The syntax above made all parties satisfied. For What It's Worth! Dave McLellan --Consulting Software Engineer - SPEA Engineering EMC Corporation 228 South St. Mail Stop: 228 LL/AA-24 Hopkinton, MA 01748 USA +1-508-249-1257 F: +1-508-497-8030 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, September 07, 2006 7:45 AM To: openssl-users@openssl.org Subject: OpenSSL 0.9.8c compile error building for OS-390-Unix configure target Hi all:0.9.8c is only a few days old.I'm trying to build it for the configure target OS390-Unix, and I'm getting the following compile error for sha_dgst.c c89.sh -I.. -I../.. -I../../include -D_LONGMAP -Wc,dll,expo -O -DB_ENDIAN -DCHARSET_EBCDIC -DNO_SYS_PARAM_H -D_ALL_SOURCE -c -o sha_dgst.o sha_dgst.c ERROR CCN3115 /u/DAM/openssl/openssl-0.9.8c/crypto/sha/sha.h:173 Duplicate type specifier long ignored. ERROR CCN3115 /u/DAM/openssl/openssl-0.9.8c/crypto/sha/sha.h:174 Duplicate type specifier long ignored. ERROR CCN3115 /u/DAM/openssl/openssl-0.9.8c/crypto/sha/sha.h:176 Duplicate type specifier long ignored. CCN0793(I) Compilation failed for file ./sha_dgst.c. Object file not created. Has anyone built the OS390-Unix version with 0.9.8c yet? Thanks. Dave McLellan --Consulting Software Engineer - SPEA Engineering EMC Corporation 228 South St. Mail Stop: 228 LL/AA-24 Hopkinton, MA 01748 USA +1-508-249-1257 F: +1-508-497-8030 [EMAIL PROTECTED] __ 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]
OpenSSL 0.9.8c compile error building for OS-390-Unix configure target
Hi all:0.9.8c is only a few days old.I'm trying to build it for the configure target OS390-Unix, and I'm getting the following compile error for sha_dgst.c c89.sh -I.. -I../.. -I../../include -D_LONGMAP -Wc,dll,expo -O -DB_ENDIAN -DCHARSET_EBCDIC -DNO_SYS_PARAM_H -D_ALL_SOURCE -c -o sha_dgst.o sha_dgst.c ERROR CCN3115 /u/DAM/openssl/openssl-0.9.8c/crypto/sha/sha.h:173 Duplicate type specifier long ignored. ERROR CCN3115 /u/DAM/openssl/openssl-0.9.8c/crypto/sha/sha.h:174 Duplicate type specifier long ignored. ERROR CCN3115 /u/DAM/openssl/openssl-0.9.8c/crypto/sha/sha.h:176 Duplicate type specifier long ignored. CCN0793(I) Compilation failed for file ./sha_dgst.c. Object file not created. Has anyone built the OS390-Unix version with 0.9.8c yet? Thanks. Dave McLellan --Consulting Software Engineer - SPEA Engineering EMC Corporation 228 South St. Mail Stop: 228 LL/AA-24 Hopkinton, MA 01748 USA +1-508-249-1257 F: +1-508-497-8030 [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Openssl on Suse 10 x86-64
I'm not sure about 0.9.8 yet, but 0.9.7d works well on the x86_64 platforms.we use no_asm no_idea no_rc5 threads shared. what exactly is the failure? Dave McLellan --Consulting Software Engineer - SPEA Engineering EMC Corporation 228 South St. Mail Stop: 228 LL/AA-24 Hopkinton, MA 01748 USA +1-508-249-1257 F: +1-508-497-8030 [EMAIL PROTECTED] From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of T CSent: Monday, July 24, 2006 4:55 PMTo: openssl-users@openssl.orgSubject: Openssl on Suse 10 x86-64 Hi, I am running openssl 0.9.8. I have code to verify signature The code works fine on about every major Unix platform. However, they are all 32-bit platforms. When I tried to run it on Suse Linux x86-64 machines it failed. I haveset my target to linux-x86_64 and turned offassembly with "no_asm" option and also changed options for this target to "-O0"from "-O3". Still couldn't get it to work. Does anyone know how well this code works on 64-bit platforms, and if there are any patches needed Thanks,Terry
RE: OpenSSL and NAGLE (TCP_NODELAY)
Our experience is successful using TCP_NODELAY with OpenSSL in our client/server application. Dave McLellan - Consulting Software Engineer Storage Platforms, Enablers, and Applications EMC Corporation 228 South St. Hopkinton MA 01748 phone: 508-249-1257 fax 508-497-8030 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leandro Gustavo Biss Becker Sent: Thursday, July 06, 2006 10:48 AM To: openssl-users@openssl.org Subject: OpenSSL and NAGLE (TCP_NODELAY) Hello Can I disable Nagle algorithm using OpenSSL? My application always send entire buffers to openssl, so I think disable Nagle but I'm wondering if openssl need coalescing data when sending SSL payloads. Thanks and sorry my english ... Leandro Gustavo Biss Becker __ 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: openssl and ipv6
You can you OpenSSL with IPv6 freely. We are driving OpenSSL sessions across IPv6 networks with no trouble, AS LONG AS you do not use BIOs for looking up host names and IP addresses.Based onmy own experience, you should do your own lookups and make the connections, then call SSL_set_fd() to associate the connected socket with an SSL session context. As fas as 0.9.7d, it doesn't know how to use getaddrinfo(). It looks like 0.9.8a doesn't either. I don't know about later 0.9.8's. I hope I haven't misrepresented anything here. Dave McLellan - Consulting Software Engineer Storage Platforms, Enablers, and Applications EMC Corporation 228 South St. Hopkinton MA 01748 phone: 508-249-1257 fax 508-497-8030 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anand ThakurSent: Thursday, June 01, 2006 5:25 AMTo: openssl-users@openssl.orgSubject: openssl and ipv6 Hi, Does anyone have an idea about how much IPv6 compliant is OpenSSL? I plan to use both 0.9.7b and 0.9.8. Thanks Anand
Any hint of a port for IBM iSeries OS/400
Hi: we're looking at our options for using OpenSSL in the IBM iSeries (AKA AS400) environment. We already run on a bunch of *nix, Win, and z/OS hosts, and we are being asked about support for some of our second tier OS's. Is there anyone who knows of any work being done porting OpenSSL to the native OS/400 OS environment? We know that OpenSSH and OpenSSL are used in the AIX-embedded subsystem (called 'PASE') of the iSeries platform (supports native RS6000 binaries AFAIK). But our application runs in the native OS/400 environment, and we do not want to cross over into the AIX-embedded subsystem. We're looking at doing the OS/400 port ourselves, or some other technical solution. This is cross-posted on a number of midrange computing lists. Thanks a bunch for any answers, and for your tolerance of this mail if you're not interested. Dave McLellan - Consulting Software Engineer Storage Platforms, Enablers, and Applications EMC Corporation 228 South St. Hopkinton MA 01748 phone: 508-249-1257 fax 508-497-8030 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: OPENSSL for z/OS 1.4 ???
You should take the OpenSSL tar file for the version you want. All the materials you need are there. once you un-tar, you should use the command./Confgure OS390-Unix, and then make. I would recommend Perl 5.6.1, and you need GNU make. Dave McLellan --Consulting Software Engineer - SPEA Engineering EMC Corporation 228 South St. Mail Stop: 228 LL/AA-24 Hopkinton, MA 01748 USA +1-508-249-1257 F: +1-508-497-8030 [EMAIL PROTECTED] From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MarianSent: Tuesday, January 31, 2006 12:52 PMTo: openssl-users@openssl.orgSubject: OPENSSL for z/OS 1.4 ??? Hello ... where can I find OPENSSL for z/OS 1.4 ?? The IBM site directs me to the OPENSSL site but I do not see an OPENSSLversion specifically listed for z/OS ??? thanks so much for any info you can supply !!! marian
RE: OS/390
Title: OS/390
We are using OpenSSL 0.9.7d in our product on
z/OS.when I last built and ran the tests, I believe tests ran
successfully, but I might not be remembering properly. z/OS was a
last platformforOpenSSL exploitation, so we had a decent test
program in our server application.
Shall we goofflist for details? (I saw your
post on MVS-OE also).
Dave McLellan --Consulting Software Engineer - SPEA
Engineering EMC
Corporation 228 South
St. Mail Stop: 228 LL/AA-24 Hopkinton, MA 01748 USA +1-508-249-1257 F: +1-508-497-8030
[EMAIL PROTECTED]
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Pierre
BurlinSent: Friday, January 27, 2006 8:30 AMTo:
openssl-users@openssl.orgSubject: OS/390
Hi All,I am trying to build openssl on OS/390
V1R5 but I am having problem with "make test". I have tested 0.9.7e and 0.9.7i without any success, are there anyone
with experience on OS/390 that could help me please?
The example below shows how I
built openssl in open-mvs environment:* Gunzip the openssl-0.9.7e.tar.gz
file* Ftp the file to target machine in binary mode.* Convert the
files into EBCDIC (pax -rf openssl-0.9.7e.tar -o
to=IBM-1047,from=ISO8859-1).* Export important
paths: "export
_C89_CCMODE=1" "export
PATH=ÅPATH:/usr/local/bin/perl/bin"
"export TMPDIR=/proteg" '"export
PERLLIB=/usr/local/bin/perl/lib/perl5/5-6.1* Run "Configure
OS390-Unix"* Edit the Makefile "CC=
/proteg/secpro/openssl-0.9.7e/tools/c89.sh"* Run "make" and evertyhing is
built successfully.* Run "make test" I get the errors (see
below). cfb64
idea ok ../util/shlib_wrap.sh ./shatest CEE3204S The system detected a
protection exception (System Completion Code=0C4) . From entry point
_openssl_ebcdic2ascii at compile unit offset +0078
at entry offset
+0078 at address
1300A790. FSUM8226 make: Error code 139 FSUM8226 make: Error code
255
But when I implemented the patch
described in http://www.openldap.org/faq/data/cache/745.html I get:
error calculating
MD4 on 'a' got 9d16e62335fbfc2946dd98546d5ca3e6 instead of
bde52cb31de33e46245e05fbdbd6fb24 error calculating MD4 on
'abc' got 6c4e5574c289fe63e55f9b6e0c4df7b7 instead of
a448017aaf21d8525fc10ae87aa6729d error calculating MD4 on 'message
digest' got d35339c99cdb1a7066142b77718905f8 instead of
d9130a8164549fe818874806e1c7014b error calculating MD4 on
'abcdefghijklmnopqrstuvwxyz' got 337b8432160246114f1194ee77d8d0b3 instead
of d79e1c308aa5bbcdeea8ed63df412da9 error calculating MD4 on
'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz01
23456789' got cec19c9121bb833f8cf6759a1f56862c instead of
043f8582f241db351ce627e153e7f0e4 error calculating MD4 on
'123456789012345678901234567890123456789012345678901234
56789012345678901234567890' got
c6cc0b153597adcfa5a7b0790475b463 instead of
e33b4ddc9c38f2199c3e7b164fcc0536 FSUM8226 make: Error code 6
FSUM8226 make:
Error code 255
When looking at the
source in .\crypto\md4\md4test.cstatic char *test[]={"","a","abc","message
digest","abcdefghijklmnopqrstuvwxyz","ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789","12345678901234567890123456789012345678901234567890123456789012345678901234567890",NULL,};Shouldn't it be in hex instead? When look at md4test.c EVP_Digest() for the
test.int EVP_Digest(void *data, unsigned
int count, unsigned char *md, unsigned int *size, const EVP_MD *type, ENGINE
*impl){EVP_MD_CTX ctx;int
ret;EVP_MD_CTX_init(ctx);EVP_MD_CTX_set_flags(ctx,EVP_MD_CTX_FLAG_ONESHOT);ret=EVP_DigestInit_ex(ctx,
type, impl) EVP_DigestUpdate(ctx, data, count)
EVP_DigestFinal_ex(ctx, md,
size);EVP_MD_CTX_cleanup(ctx);return
ret;}The question is where is
ebcdic2ascii() called? Should it not be around EVP_DigestUpdate() as in
md4_one.c?If one looks at SHA1 and RIPEMD, ebcdic2ascii() is included in
the test source (example: sha1test.c.). On the other hand they are missing in
sha1_one.c, everything appearance to be a bit inconsistent?
Please help me!
Kind regards, Pierre
