Re: kEECDH handshake failure with invalid ecpointformatlist?
Hi,
This is a known issue for which I have sent a patch (under ticket #2240)
on April 25th 2010. OpenSSL wrongly returns an error if the ServerHello
is missing the Supported Point Format extension whereas it should
interpret it as only uncompressed format is supported.
Can you check that this solves the failures you are seeing?
Here is the link on RT with the description of the issue and the patch :
http://rt.openssl.org/Ticket/Display.html?id=2240&user=guest&pass=guest
Cheers,
--
Mounir IDRASSI
IDRIX
http://www.idrix.fr
On 11/24/2010 11:37 PM, Victor Duchovni wrote:
I see intermitten failures to complete an SMTP STARTTLS handshake
with some servers. This happens when on entry into
ssl_check_serverhello_tlsext() the server proposes a kEECDH
cipher, say:
(gdb) p *(s->s3->tmp.new_cipher)
$7 = {valid = 1, name = 0x2a95a0ceea "ECDHE-RSA-DES-CBC3-SHA", id = 50380818,
algorithm_mkey = 128, algorithm_auth = 1, algorithm_enc = 2,
algorithm_mac = 2, algorithm_ssl = 2, algo_strength = 129,
algorithm2 = 12336, strength_bits = 168, alg_bits = 168}
but
(gdb) p s->session->tlsext_ecpointformatlist
$5 = (unsigned char *) 0x0
(gdb) p s->session->tlsext_ecpointformatlist_length
$6 = 0
and so the handshake fails on line 1469 of t1_lib.c:
(gdb) bt
#0 ssl_check_serverhello_tlsext (s=0x5745e0) at t1_lib.c:1469
#1 0x002a959e5ad7 in ssl3_get_server_hello (s=0x5745e0) at s3_clnt.c:940
#2 0x002a959e9220 in ssl3_connect (s=0x5745e0) at s3_clnt.c:279
(gdb) l
1467if ((s->session->tlsext_ecpointformatlist == NULL) ||
(s->session->tlsext_ecpointformatlist_length == 0))
1468{
1469
SSLerr(SSL_F_SSL_CHECK_SERVERHELLO_TLSEXT,SSL_R_TLS_INVALID_ECPOINTFORMAT_LIST);
1470return -1;
1471}
Is the server doing something wrong here? I see the same symptoms with
both 1.0.0a and 1.0.0b. Excluding kEECDH ciphers works yielding
EDH-RSA-DES-CBC3-SHA.
The packet dump (if that's useful is below):
TLS cipher list "aNULL:ALL:+RC4:@STRENGTH:!eNULL"
SSL_connect:before/connect initialization
write to 0054A4D0 [0057C340] (236 bytes => 236 (0xEC))
16 03 01 00 e7 01 00 00|e3 03 01 4c ed 91 59 da ...L..Y.
0010 b2 14 bb 72 d2 f0 65 69|84 18 5b 11 41 50 95 1c ...r..ei ..[.AP..
0020 66 dc bb 5d 45 30 4d 7d|6e 52 00 00 00 76 c0 19 f..]E0M} nR...v..
0030 00 3a 00 89 c0 14 c0 0a|00 39 00 38 00 88 00 87 .:.. .9.8
0040 c0 0f c0 05 00 35 00 84|c0 17 00 1b c0 12 c0 08 .5..
0050 00 16 00 13 c0 0d c0 03|00 0a c0 18 00 34 00 9b .4..
0060 00 46 c0 13 c0 09 00 33|00 32 00 9a 00 99 00 45 .F.3 .2.E
0070 00 44 c0 0e c0 04 00 2f|00 96 00 41 c0 16 00 18 .D./ ...A
0080 c0 11 c0 07 c0 0c c0 02|00 05 00 04 00 1a 00 15
0090 00 12 00 09 00 19 00 14|00 11 00 08 00 06 00 17
00a0 00 03 00 ff 01 00 00 44|00 0b 00 04 03 00 01 02 ...D
00b0 00 0a 00 34 00 32 00 01|00 02 00 03 00 04 00 05 ...4.2..
00c0 00 06 00 07 00 08 00 09|00 0a 00 0b 00 0c 00 0d
00d0 00 0e 00 0f 00 10 00 11|00 12 00 13 00 14 00 15
00e0 00 16 00 17 00 18 00 19|00 23 .#
00ea -
SSL_connect:SSLv2/v3 write client hello A
read from 0054A4D0 [005818A0] (7 bytes => -1 (0x))
read from 0054A4D0 [005818A0] (7 bytes => 7 (0x7))
16 03 01 12 d4 02..
0006 -
read from 0054A4D0 [005818AA] (4818 bytes => -1 (0x))
read from 0054A4D0 [005818AA] (4818 bytes => 2889 (0xB49))
00 46 03 01 4c ed 91 59|67 4a d7 63 37 1e a1 b8 .F..L..Y gJ.c7...
0010 ac 62 3e 04 00 66 86 e1|de bb 04 9d 07 b2 ee b2 .b>..f..
0020 9a 08 94 03 20 4c ed 91|59 49 98 8a 73 e0 bb 2d L.. YI..s..-
0030 ee 4c ee 70 73 a2 ba 56|bb 8f bd 8a 0e 05 2b 63 .L.ps..V ..+c
0040 1c 31 d0 6a c6 c0 12 00|0b 00 11 cd 00 11 ca 00 .1.j
0050 04 f2 30 82 04 ee 30 82|03 d6 a0 03 02 01 02 02 ..0...0.
0060 04 46 45 1a ee 30 0d 06|09 2a 86 48 86 f7 0d 01 .FE..0.. .*.H
0070 01 05 05 00 30 81 ca 31|0b 30 09 06 03 55 04 06 0..1 .0...U..
0080 13 02 55 53 31 10 30 0e|06 03 55 04 08 13 07 41 ..US1.0. ..UA
0090 72 69 7a 6f 6e 61 31 13|30 11 06 03 55 04 07 13 rizona1. 0...U...
00a0 0a 53 63 6f 74 74 73 64|61 6c 65 31 1a 30 18 06 .Scottsd ale1.0..
00b0 03 55 04 0a 13 11 47 6f|44 61 64 64 79 2e 63 6f .UGo Daddy.co
00c0 6d 2c 20 49 6e 63 2e 31|33 30 31 06 03 55 04 0b m, Inc.1 301..U..
00d0 13 2a 68 74 74 70 3a 2f|2f 63 65 72 74 69 66 69 .*http:/ /certifi
00e0 63 61 74 65 73 2e 67 6f|64 61 64 64 79 2e 63 6f cates.go daddy.co
00f0 6d 2f 72 65 70 6f 73 69|74 6f 72 79 31 30 30 2e m/reposi tory100.
0100 06 03 55 04 03 13 27 47|6f 20 44 61 64 64 79 20 ..U...'G o Daddy
0110 53 65 63 75 72 65 20 43|65 72 74 69 66 69 63 61 Secure C ertifica
0120 74 69 6f 6e 20 41
kEECDH handshake failure with invalid ecpointformatlist?
I see intermitten failures to complete an SMTP STARTTLS handshake
with some servers. This happens when on entry into
ssl_check_serverhello_tlsext() the server proposes a kEECDH
cipher, say:
(gdb) p *(s->s3->tmp.new_cipher)
$7 = {valid = 1, name = 0x2a95a0ceea "ECDHE-RSA-DES-CBC3-SHA", id = 50380818,
algorithm_mkey = 128, algorithm_auth = 1, algorithm_enc = 2,
algorithm_mac = 2, algorithm_ssl = 2, algo_strength = 129,
algorithm2 = 12336, strength_bits = 168, alg_bits = 168}
but
(gdb) p s->session->tlsext_ecpointformatlist
$5 = (unsigned char *) 0x0
(gdb) p s->session->tlsext_ecpointformatlist_length
$6 = 0
and so the handshake fails on line 1469 of t1_lib.c:
(gdb) bt
#0 ssl_check_serverhello_tlsext (s=0x5745e0) at t1_lib.c:1469
#1 0x002a959e5ad7 in ssl3_get_server_hello (s=0x5745e0) at s3_clnt.c:940
#2 0x002a959e9220 in ssl3_connect (s=0x5745e0) at s3_clnt.c:279
(gdb) l
1467if ((s->session->tlsext_ecpointformatlist == NULL) ||
(s->session->tlsext_ecpointformatlist_length == 0))
1468{
1469
SSLerr(SSL_F_SSL_CHECK_SERVERHELLO_TLSEXT,SSL_R_TLS_INVALID_ECPOINTFORMAT_LIST);
1470return -1;
1471}
Is the server doing something wrong here? I see the same symptoms with
both 1.0.0a and 1.0.0b. Excluding kEECDH ciphers works yielding
EDH-RSA-DES-CBC3-SHA.
The packet dump (if that's useful is below):
TLS cipher list "aNULL:ALL:+RC4:@STRENGTH:!eNULL"
SSL_connect:before/connect initialization
write to 0054A4D0 [0057C340] (236 bytes => 236 (0xEC))
16 03 01 00 e7 01 00 00|e3 03 01 4c ed 91 59 da ...L..Y.
0010 b2 14 bb 72 d2 f0 65 69|84 18 5b 11 41 50 95 1c ...r..ei ..[.AP..
0020 66 dc bb 5d 45 30 4d 7d|6e 52 00 00 00 76 c0 19 f..]E0M} nR...v..
0030 00 3a 00 89 c0 14 c0 0a|00 39 00 38 00 88 00 87 .:.. .9.8
0040 c0 0f c0 05 00 35 00 84|c0 17 00 1b c0 12 c0 08 .5..
0050 00 16 00 13 c0 0d c0 03|00 0a c0 18 00 34 00 9b .4..
0060 00 46 c0 13 c0 09 00 33|00 32 00 9a 00 99 00 45 .F.3 .2.E
0070 00 44 c0 0e c0 04 00 2f|00 96 00 41 c0 16 00 18 .D./ ...A
0080 c0 11 c0 07 c0 0c c0 02|00 05 00 04 00 1a 00 15
0090 00 12 00 09 00 19 00 14|00 11 00 08 00 06 00 17
00a0 00 03 00 ff 01 00 00 44|00 0b 00 04 03 00 01 02 ...D
00b0 00 0a 00 34 00 32 00 01|00 02 00 03 00 04 00 05 ...4.2..
00c0 00 06 00 07 00 08 00 09|00 0a 00 0b 00 0c 00 0d
00d0 00 0e 00 0f 00 10 00 11|00 12 00 13 00 14 00 15
00e0 00 16 00 17 00 18 00 19|00 23 .#
00ea -
SSL_connect:SSLv2/v3 write client hello A
read from 0054A4D0 [005818A0] (7 bytes => -1 (0x))
read from 0054A4D0 [005818A0] (7 bytes => 7 (0x7))
16 03 01 12 d4 02..
0006 -
read from 0054A4D0 [005818AA] (4818 bytes => -1 (0x))
read from 0054A4D0 [005818AA] (4818 bytes => 2889 (0xB49))
00 46 03 01 4c ed 91 59|67 4a d7 63 37 1e a1 b8 .F..L..Y gJ.c7...
0010 ac 62 3e 04 00 66 86 e1|de bb 04 9d 07 b2 ee b2 .b>..f..
0020 9a 08 94 03 20 4c ed 91|59 49 98 8a 73 e0 bb 2d L.. YI..s..-
0030 ee 4c ee 70 73 a2 ba 56|bb 8f bd 8a 0e 05 2b 63 .L.ps..V ..+c
0040 1c 31 d0 6a c6 c0 12 00|0b 00 11 cd 00 11 ca 00 .1.j
0050 04 f2 30 82 04 ee 30 82|03 d6 a0 03 02 01 02 02 ..0...0.
0060 04 46 45 1a ee 30 0d 06|09 2a 86 48 86 f7 0d 01 .FE..0.. .*.H
0070 01 05 05 00 30 81 ca 31|0b 30 09 06 03 55 04 06 0..1 .0...U..
0080 13 02 55 53 31 10 30 0e|06 03 55 04 08 13 07 41 ..US1.0. ..UA
0090 72 69 7a 6f 6e 61 31 13|30 11 06 03 55 04 07 13 rizona1. 0...U...
00a0 0a 53 63 6f 74 74 73 64|61 6c 65 31 1a 30 18 06 .Scottsd ale1.0..
00b0 03 55 04 0a 13 11 47 6f|44 61 64 64 79 2e 63 6f .UGo Daddy.co
00c0 6d 2c 20 49 6e 63 2e 31|33 30 31 06 03 55 04 0b m, Inc.1 301..U..
00d0 13 2a 68 74 74 70 3a 2f|2f 63 65 72 74 69 66 69 .*http:/ /certifi
00e0 63 61 74 65 73 2e 67 6f|64 61 64 64 79 2e 63 6f cates.go daddy.co
00f0 6d 2f 72 65 70 6f 73 69|74 6f 72 79 31 30 30 2e m/reposi tory100.
0100 06 03 55 04 03 13 27 47|6f 20 44 61 64 64 79 20 ..U...'G o Daddy
0110 53 65 63 75 72 65 20 43|65 72 74 69 66 69 63 61 Secure C ertifica
0120 74 69 6f 6e 20 41 75 74|68 6f 72 69 74 79 31 11 tion Aut hority1.
0130 30 0f 06 03 55 04 05 13|08 30 37 39 36 39 32 38 0...U... .0796928
0140 37 30 1e 17 0d 30 39 30|33 30 35 30 30 32 38 33 70...090 30500283
0150 32 5a 17 0d 31 30 30 34|32 32 30 30 30 32 33 34 2Z..1004 22000234
0160 5a 30 6c 31 0b 30 09 06|03 55 04 06 0c 02 55 53 Z0l1.0.. .UUS
0170 31 13 30 11 06 03 55 04|08 0c 0a 43 61 6c 69 66 1.0...U. ...Calif
0180 6f 72 6e 69 61 31 15 30|13 06 03 55 04 07 0c 0c ornia1.0 ...U
0190 52 6f 68 6e 65 72 74 20|50 61 72 6b 31 17 30 15 Rohnert Park1.0.
01a0 06 03 55 04 0a 0c 0e 52|65 64 20 43 6f 6e
File Upload Issues
Hello all, I am working on a man in the middle proxy and am almost finished with it. The particulars of this proxy are as follows: * Multi threading is enabled, and used * The write, and read operations are Non blocking, neither are the underlying bios * The proxy pays attention to the error codes returned from SSL_read, and SSL_write, and handles each one according to the man pages. This includes but is not limited to SSL_WANT_READ and SSL_WANT_WRITE The issue that I am having is, as you probably guessed from the subject, file uploading. If run as is, the connection is reset by the proxy after about 20K of whatever file was supposed to be transferred. But if I add a usleep(4) (40 ms delay) after each SSL_read/write operation, then the proxy both grabs all of the data presented, and writes all of the data that it is supposed to. I am really confused about how this small delay could mean the difference between a 20K and 20 MB file uploading. Is there some error condition possibly that I am not handling, or some underlying write buffer that needs to be cleared before I continue with operation of the program that the sleep allows for the Kernel to clear on it's own? I am really at a loss for reason why this works. I would prefer to know why, and implement a more elegant solution to this problem than just letting it clean itself up. Any ideas, thoughts, or pointers would be much appreciated. I can provide more details if needed as well. Thank you. -Sam -- Sam Jantz Software Engineer
RE: openssl-1.0.0b - include\openssl empty headers files
Some zip programs do not restore the links properly. Regardless, when you first build, those header files should be recreated from their actual locations (e.g. openssl-1.0.0b/ssl/ssl.h). Erik Tkal Juniper OAC/UAC/Pulse Development -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of EnigmaTrader Sent: Tuesday, November 23, 2010 10:38 PM To: openssl-users@openssl.org Subject: openssl-1.0.0b - include\openssl empty headers files openssl-1.0.0b - include\openssl header All header files in there are zero length. Tried 0.9.8p.tar.gz also... Has to be something I am doing. Never run into this before. Using 7zip. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Logotype encoding
Hi Steve: On 2010-11-23, at 6:20 PM, Dr. Stephen Henson wrote: > > Well you can nest tags like that but that's not the correct encoding for that > module. > > The inner tag uses IMPLICIT tagging so you need IMPLICIT:1 for the second one. > Yes - sorry - my mistake. > > Well if you used SEQUENCE instead of SEQWRAP it would work. It is easier just > to keep your existing syntax and prepend SEQWRAP to the refStructHash value so > you have: > > refStructHash=SEQWRAP, SEQUENCE:HashAlgAndValue Thanks for clearing that up - I wasn't aware that you could chain that way. Best Regards, --- Patrick Patterson Chief PKI Architect Carillon Information Security Inc. http://www.carillon.ca __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
