On 10/22/2009 10:37 PM, Dr Stephen Henson wrote:
Kamesh Jayachandran wrote:
On 10/22/2009 05:24 PM, Dr Stephen Henson wrote:
That's due to the function pointer issues which gcc 4.2 and later
doesn't like:
this was fixed in newer versions of OpenSSL.
Is there any switch we can pass to gcc 4.2 to compile and make it work
properly.
No. If you really want to use 0.9.8b it needs an older version of gcc or you can
backport the fixes.
They are rather extensive but mainly contained in:
http://cvs.openssl.org/chngview?cn=16526
and
http://cvs.openssl.org/chngview?cn=16528
OpenSSL 0.9.8b doesn't use TLS extensions at all.
Do you need TLS extensions on the client/server? If not try compiling
OpenSSL
with no-tlsext.
May not be possible as *client* builds are not in our control.
I believe no-tlsext does *not* disable TLS functionality itself.
The no-tlsext option disables TLS extension functionality. If that works on the
server side then an alternative workaround could be found.
Yes, building 'openssl-0.9.8k' on the server side with no-tlsext works
around this issue irrespective of the client openssl.
Did you say what version of OpenSSL the failing client was using on
Windows?
It happens with openssl-0.9.8j on client openssl-0.9.8k on server
Hmm... could be 0.9.8j sending bad data with invalid extension syntax under rare
circumstances.
A packet sniffer or logging the errant extensions received by OpenSSL could help
trace this further.
Will post tcpdump once I set it up on win32.
Thanks.
With regards
Kamesh Jayachandran
