http://cvs.openssl.org/chngview?cn=22334 is interim solution,
proper solution will be provided at later point (if found appropriate).
Thanks, this circumvents the DTLS issue.
The TLS empty fragments issue remains, but this patch hints at
the cause. I think the problem is here, (s3_pkt.c, circa
Please try setting the OPENSSL_ia32cap environment variable to 0 and see
if you still get the problem.
That worked.
I added code to the test harness to show the capability flags:
OPENSSL_ia32cap=[ffeb:1fbae3ff]
I then added a command-line switch to change the flags on-the-fly.
Turning
Andy has made some recent fixes to the AES code too which may be
relevant. Please check the next snapshot to see if you still have problems.
I get the same results with openssl-1.0.1-stable-SNAP-20120403.tar.gz
To narrow down the problem, I built the no-asm version, (which works),
saved off
Hi,
I'm trying to run a simple DTLS client/server test using OpenSSL 1.0.1, but
with the same Cipher Suites that OpenSSL 1.0.0 uses, (to compare the two
handshakes). This works fine with a 32 bit, (i686), build, but fails on 64 bit,
(x86_64) with the following error:
d1_pkt.c(444): OpenSSL
Never mind... found a 64 bit memory alignment error in the test harness. I'm
not entirely clear how/why the alignment problem was impacting OpenSSL, but
with that bug fixed, the DTLS problem goes away.
Apologies for the false alarm,
John Fitzgibbon
From:
Geez, not my best day... this *is* still a problem. I forgot to reset my test
cases to use the 1.0.0 list of Cipher Suites. The alignment bug had nothing
whatsoever to do with this particular OpenSSL failure, and it still fails even
with my now-squeaky-clean test harness.
Don't know if this is related or not, but I'm also running a very similar test
that uses TLS instead of DTLS, (same scenario, OpenSSL 1.0.1 with 1.0.0 Cipher
Suites selected). That works fine, except that the 64 bit version of the test
looks like it doesn't include the Empty Fragments security
the 64 bit version of the test looks like it doesn't include
the Empty Fragments security countermeasure
If you're using TLS v1.1 or 1.2 then you shouldn't encounter empty
fragments on any version as they are not required any more as CBC mode
includes an explicit IV.
The TLS tests are 1.0.
Some interesting observations:
1) Changed the cipher lists to much simpler values:
ciphers = AES256-SHA256 = works
ciphers = AES256-SHA = fails
2) On a hunch, I tried adding no-asm to the config line: 2.1) TLS test now
works and yields a perfect match with the 32 bit test
2.2) DTLS test
DTLS test works, but the random bytes field differs in the server hello.
There should be
no difference because the test harness is supplying a non-random PRNG.
This is happening because of the following, (which looks like a bug), in
ssl/d1_srvr.c, line 923:
Time=(unsigned
Not 100% sure that this fix is valid, but here goes anyway...
I was trying to write unit tests for the EC test vectors in RFC 4753. To do
this, I need to specify the private key before proceeding with the key
exchange, so I tried preceding EC_KEY_generate_key(key) with a call to
Attached patch removes the second definition of SSL_get_selected_srtp_profile()
in srtp.h which causes -Werror builds to fail.
John Fitzgibbon
Attached patch removes the second definition of SSL_get_selected_srtp_profile() in srtp.h which causes -Werror builds to fail.John Fitzgibbon
In the attached pcap, the first five packets represent a complete DTLS
handshake, (the client-side app is using OpenSSL 1.0.0d against a Cisco ASA
server). However, packets 6 and 7 appear to be retranmissions, (from the
client-side), of the Change Cipher Spec and Handshake records contained in
In OpenSSL 1.0.0-beta4, SMIME_crlf_copy() and SMIME_text() are declared in two
places: asn1.h and pkcs7.h.
The declarations in pkcs7.h appear to be redundant, (and can cause
warnings/errors depending on compiler config), because that header file already
includes asn1.h.
Regards,
John
14 matches
Mail list logo
