question about binary compatibility
Hello, I am actually makeing corrections to the SRP/TLS code. One of them removes an unnecessary callback. There is a pointer in a SRP_CTX that is no longer necessary. I wonder what is the current policy concerning a stable branch and the head? It seems that one simply would leave the useless pointer in the stable branch and remove it from the head? /* set SRP client username callback */ char *(*SRP_TLS_ext_missing_srp_client_username_callback)(SSL *, void *); regards __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: question about binary compatibility
On Thu, Dec 08, 2011, Peter Sylvester wrote: Hello, I am actually makeing corrections to the SRP/TLS code. One of them removes an unnecessary callback. There is a pointer in a SRP_CTX that is no longer necessary. I wonder what is the current policy concerning a stable branch and the head? It seems that one simply would leave the useless pointer in the stable branch and remove it from the head? /* set SRP client username callback */ char *(*SRP_TLS_ext_missing_srp_client_username_callback)(SSL *, void *); The function can be deleted from HEAD and 1.0.1 as there haven't been any stable releases from the 1.0.1 branch yet. Once 1.0.1 is released then changes which would make 1.0.1a binary incompatible with 1.0.1 would be prohibited unless there was a compelling reason to do so: e.g. it was essential to fix a security problem. An additional snippet... there is a new experimental feature in 1.0.1 and later which will make all SSL related structures opaque. If an application compiles when OPENSSL_NO_SSL_INTERN is #defined it should be immune to any changes in the SSL internals. It is quite likely that we need some more functions for this to work with some applications: any feedback would be welcomed so we can add them. The long term aim (quite possibly several years away) is to make this setting the default. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: question about binary compatibility
On 12/08/2011 03:34 PM, Dr. Stephen Henson wrote: On Thu, Dec 08, 2011, Peter Sylvester wrote: Hello, I am actually makeing corrections to the SRP/TLS code. One of them removes an unnecessary callback. There is a pointer in a SRP_CTX that is no longer necessary. I wonder what is the current policy concerning a stable branch and the head? It seems that one simply would leave the useless pointer in the stable branch and remove it from the head? /* set SRP client username callback */ char *(*SRP_TLS_ext_missing_srp_client_username_callback)(SSL *, void *); The function can be deleted from HEAD and 1.0.1 as there haven't been any stable releases from the 1.0.1 branch yet. Once 1.0.1 is released then changes which would make 1.0.1a binary incompatible with 1.0.1 would be prohibited unless there was a compelling reason to do so: e.g. it was essential to fix a security problem. Ok. Anyway, regarding the following, there is no problem at all since the structures in question are not used directly by an application. An additional snippet... there is a new experimental feature in 1.0.1 and later which will make all SSL related structures opaque. If an application compiles when OPENSSL_NO_SSL_INTERN is #defined it should be immune to any changes in the SSL internals. It is quite likely that we need some more functions for this to work with some applications: any feedback would be welcomed so we can add them. There are already a lot of special access functions to various data objects, I wonder whether it wouldn't be better not to use functions but rather a CTRL function for setters, and one generic new INFO function for getters. considering types, curl has a nice way to do handle them The long term aim (quite possibly several years away) is to make this setting the default. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2650] major ssl read/ write performance improvement - updated
Hello Michael, I have tested youe patch. It is working stable at least with ccgost engine (and without any engine too, of cource). Thanks for contribution! Could you please describe, what was your test environmnet and test methodology? How did you measure that doubling read/write speed? What tool/profiler do you use? How it depends from SSL record size? What the overall speed improvement if we'll count OS IO? I'm asking because I'm trying to measure performance improvement your changes can give with my crypto-accelerator, and my results not even close to doube read/write speed. But my test resources are limited for the moment, and it is possible it is due to these limitations. In any case, I guess comunity will be grateful if your share your expirience. WBR, Andrey On 5 December 2011 14:33, Deng Michael via RT r...@openssl.org wrote: Hi, I have changed the mac code which gives substantial improvement for both read and write (not handshake) The saving is fairly major, on cpu with cryto acceleration, the change can more than double the overall ssl read /write speed for 1K record excluding OS IO time. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Release of OpenSSL 1.0.1 approaching...
OpenSSL 1.0.1 is expected to be released in the next few weeks. There have been many changes since OpenSSL 1.0.0 including: o PSS signatures in certificates, requests and CRLs. o Support for password based recipient info for CMS. o Support TLS v1.2 and TLS v1.1. o Preliminary FIPS capability for unvalidated 2.0 FIPS module. o SRP support. Users are encouraged to test recent snapshots of OpenSSL 1.0.1 and report any problems via the request tracker (r...@openssl.org). The actual 1.0.1 release date will depend on the number and severity of issues uncovered. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Next Protocol Support and SSL Renegotiation
Yup. I see it is fixed. On Mon, Dec 5, 2011 at 12:31 PM, Ben Laurie b...@links.org wrote: I think we fixed this... On Sat, Nov 19, 2011 at 2:28 PM, Ben Murphy benmmur...@gmail.com wrote: I think there might be a bug with Next Protocol Negotiation and SSL Renegotiation. My interpretation of the spec is that you shouldn't be doing NPN negotiation during ssl renegotiation. Openssl client doesn't appear to send NPN hello extension but it does seem to send NPN handshake message during renegotiation if a next protocol had been selected previously. If I setup an openssl server like: ./apps/openssl s_server -port 8443 -nextprotoneg http/1.1 -key ~/git/espdy2/server.key -cert ~/git/espdy2/server.crt and then connect with a client: ./apps/openssl s_client -msg -host localhost -port 8443 -nextprotoneg spdy/2 and type 'R' in the client to do renegotiation I see this in the debug output during renegotiation which appears to be the next_protocol handshake message: ??? [length 0024] 43 00 00 20 06 73 70 64 79 2f 32 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 73:70:64:79:2f:32 - spdy/2 I have another npn ssl implementation and it bails out when it receives the unexpected message: TLS 1.0 Alert [length 0002], fatal unexpected_message 02 0a 2903868164:error:140943F2:SSL routines:SSL3_READ_BYTES:sslv3 alert unexpected message:s3_pkt.c:1227:SSL alert number 10 2903868164:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:592: __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
FIPS cross-compile for SH4
I'm working on a cross-compile build of openssl-fips-1.2.3. I have set up my cross compile, but failing fingerprint verification at the build level. This is the error: HMAC-SHA1(fips_premain.c)= dab2842517034a42dfdb21a285d4f0f4d7f6f920 ../fips/../fips/fips_premain.c fingerprint mismatch My build steps were: 1. Unpack the openssl-fips-1.2.3 tgz file 2. ./Configure no-hw no-shared no-dso no-asm --openssldir=/home/rdavis/Projects/openssl-fips-1.2.3/compiled/sh_sh4_le linux-elf 3. Set environment: HOSTCC=gcc CROSS_COMPILE=sh_sh4_le PATH=$PATH:~/Projects/linux_tools/bin 4. Modify main Makefile with: FIPSLIBDIR= FIPSCANISTERINTERNAL=y FIPSCANLIB=libcrypto 5. make There is something here that I am missing to build the fips modules correctly; the basic procedure in the user manual does not seem to quite work here. Regards; == Rick Davis __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Release of OpenSSL 1.0.1 approaching...
On Fri, 9 Dec 2011, Dr. Stephen Henson wrote: OpenSSL 1.0.1 is expected to be released in the next few weeks. [snip] Users are encouraged to test recent snapshots of OpenSSL 1.0.1 and report any problems via the request tracker (r...@openssl.org). I assume the snapshots are built from the OpenSSL_1_0_1-stable CVS tag. On UnixWare 7.1.4 (i586-sco-unixware7) configured with ./config --prefix=/opt/mt/openssl-1.0.0 --openssldir=/etc/ssl zlib -Kpentium_pro I'm getting this error making all in crypto... cc -I. -I.. -I../include -DZLIB -DOPENSSL_THREADS -Kthread -DDSO_DLFCN -DHAVE_DLFCN_H -Kpentium_pro -D__i386__ -O -DFILIO_H -Kalloca -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -c -o x86cpuid.o x86cpuid.s UX:as: ERROR: x86cpuid.s:311:unknown instruction: loopl *** Error code 1 (bu21) UX:make: ERROR: fatal error. *** Error code 1 (bu21) UX:make: ERROR: fatal error. -- Tim RiceMultitalents(707) 456-1146 t...@multitalents.net (707) 887-1469 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: Block MD5 certificates
From: owner-openssl-...@openssl.org On Behalf Of Tatiana Evers Sent: Wednesday, 07 December, 2011 08:17 Is there any function in OpenSSL (library) to get signature algorithm from a certificate? I need to block MD5 certificates. No; a good deal of the X509_ interface dates back to early days before there was an effort to hide data structures. Just use x509-sig_alg-algorithm and maybe OBJ_obj2nid . Or, you could use FIPS mode (of a FIPS build, but the last validation is a bit out of date now; a new one is in progress but they usually take several months, sometimes many months). FIPS mode restricts algorithms to those approved by NIST, and MD5 is not among them. :-) :-( :-? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
