[openssl.org #1192] OPENSSL S_CLIENT STARTTLS SMTP PATCH
Here is a patch for openssl s_client ! I have trouble using the STARTTLS command on many servers. As they reject any request before greeting HELO I have made up this patch hope that it is useful for me. I do request that you make it available to others. Regards Vijay Sarvepalli *** apps/s_client.c 2005-08-24 16:02:00.846839850 -0400 --- apps/s_client.c~2005-05-30 18:37:41.0 -0400 *** *** 722,729 if (starttls_proto == 1) { BIO_read(sbio,mbuf,BUFSIZZ); - BIO_printf(sbio,HELO WWW.OPENSSL.ORG\r\n); - BIO_read(sbio,mbuf,BUFSIZZ); BIO_printf(sbio,STARTTLS\r\n); BIO_read(sbio,sbuf,BUFSIZZ); } --- 722,727 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] Pre-Shared Key Ciphersuites for OpenSSL
Greetings! On Tue, 23 Aug 2005, [EMAIL PROTECTED] wrote: We have implemented a part of a new Intenet Draft called Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) [1], and we would like to contribute it to the OpenSSL project. Your patch uses 2 more bits from bitmask defined in ssl_locl.h It seems to us this mask almost restricts adding new cipher suites using algorythms or authentication schemes unsupported now. Your patch is very interesting to us because right now we try to make adding of new cipher suites more simple. We are interested in cooperation in this sphere. We have some preliminary tested concepts regarding easy adding of extra cipher suites and we'll be happy to discuss this ideas. Thank you. -- SY, Dmitry Belyavsky (ICQ UIN 6575) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [PATCH] Pre-Shared Key Ciphersuites for OpenSSL
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Dmitry Belyavsky Sent: 25. elokuuta 2005 13:27 To: openssl-dev@openssl.org Subject: Re: [PATCH] Pre-Shared Key Ciphersuites for OpenSSL Greetings! On Tue, 23 Aug 2005, [EMAIL PROTECTED] wrote: We have implemented a part of a new Intenet Draft called Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) [1], and we would like to contribute it to the OpenSSL project. Your patch uses 2 more bits from bitmask defined in ssl_locl.h It seems to us this mask almost restricts adding new cipher suites using algorythms or authentication schemes unsupported now. Yes, we also encountered the same restricting issue while developing. Now there seems to be only a few remaining bits to be used. It is definatively not a good thing for future developers who are planning to use their own cipher suites. Your patch is very interesting to us because right now we try to make adding of new cipher suites more simple. We are interested in cooperation in this sphere. Sounds nice. Some other extensible way than the current (one integer containing the bitmask) is needed sooner or later. We have some preliminary tested concepts regarding easy adding of extra cipher suites and we'll be happy to discuss this ideas. Maybe it would be better to discuss the ideas in this mailing list, so everyone can comment the ideas. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [PATCH] Pre-Shared Key Ciphersuites for OpenSSL
Greetings! On Thu, 25 Aug 2005, [EMAIL PROTECTED] wrote: Yes, we also encountered the same restricting issue while developing. Now there seems to be only a few remaining bits to be used. It is definatively not a good thing for future developers who are planning to use their own cipher suites. Your patch is very interesting to us because right now we try to make adding of new cipher suites more simple. We are interested in cooperation in this sphere. Sounds nice. Some other extensible way than the current (one integer containing the bitmask) is needed sooner or later. We have some preliminary tested concepts regarding easy adding of extra cipher suites and we'll be happy to discuss this ideas. Maybe it would be better to discuss the ideas in this mailing list, so everyone can comment the ideas. I agree. The main idea of the work our company currently undertakes in libssl is that the SSL_CIPHER.algorithms field contains too much independent information. It seems to us this field should be divided into some fields containing particular information about key exchange, authentication, encryption and MAC specified by the cipher suite. These fields should contain pointers to the structures containing callbacks implementing required behaviour for key exchange and authentication. The structures required for extra encryption or MAC are much more simple. We have their preliminary implementations and we've implemented the cipher suite using Russian national cryptoalgorythms for encryption and MAC. So this idea at least seems to be good enough for experiments. We hope this short description is clear and will be interesting for a discussion. Thank you. -- SY, Dmitry Belyavsky (ICQ UIN 6575) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1193] gcc depracated -mcpu= option
I downloaded 0.9.8 and ran ./config;make on an FC3 box. References to gcc all had a warning, as below, about a depracated -mcpu= option. gcc -I../crypto -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -mcpu=pentium -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -c -o s3_srvr.o s3_srvr.c `-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead. -- ++ Jonathan Hayward, [EMAIL PROTECTED] ** To see an award-winning website with stories, essays, artwork, ** games, and a four-dimensional maze, why not visit my home page? ** All of this is waiting for you at http://JonathansCorner.com ** If you'd like a Google Mail (gmail.com http://gmail.com) account, please tell me! __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
OPENSSL_gmtime() is not ported for pSOS
Hi ALL, OPENSSL_gmtime() defines in O_time.c internally calls struct tm* through gmtime() but in pSOS gmtime() always retuen NULL. So can we say OPENSSL_gmtime() will always fails fro pSOS ? Can anyone suugest proper porting ! __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Error During HandShake,SIP/TLS no information back from the TLS Server UNIXWARE 7.1
Title: Error During HandShake,SIP/TLS no information back from the TLS Server UNIXWARE 7.1 Hi, I have a SIP/TLS implementation using the openssl libraries, and I am runing into a few issues that I don't know how to debug or what is going wrong. I have 3 machines running my application, one in unixware using openssl 9.7d the other 2 on Linux using openssl 9.7e, I have the same server/client certificates in them all and CA. I can get a successful connection between the Linux machines, but it doesn't work when I try from the unixware to the linux or viceversa. Here is the ssldump output from the linux machine, and the tcpdump output on the unixware machine, note I haven't been able to compile ssldump in unixware 7.1.1. Is there any known problem with the openssl libraries in Unixware, because it seems that it never respondes to requests. What would be the best way to figure out what is going wrong? I cannot interpret anything wrong on those 2 outputs. Thanks for your help, Ignacio Miranda [EMAIL PROTECTED] certs]# /home/nacmir/sslTools/ssldump New TCP connection #6: bwdevel01.usae.avaya.com(38531) - ipcpuw.usae.avaya.com(5061) 6 1 0.0016 (0.0016) CS Handshake ClientHello Version 3.1 cipher suites Unknown value 0x39 Unknown value 0x38 Unknown value 0x35 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA Unknown value 0x33 Unknown value 0x32 Unknown value 0x2f TLS_DHE_DSS_WITH_RC4_128_SHA TLS_RSA_WITH_IDEA_CBC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 compression methods NULL 6 28.0884 (28.0867) SC TCP FIN 6 28.0889 (0.0004) CS TCP FIN New TCP connection #7: ipcpuw.usae.avaya.com(35656) - bwdevel01.usae.avaya.com(5061)