error: ASN1_mbstring_copy:string too long:a_mbstr.c:154:maxsize=2 _only_ when using config file and prompt off
Hi all, For some strange reasons, when I disable prompt in the cnf file, I run into the "error: ASN1_mbstring_copy:string too long:a_mbstr.c:154:maxsize=2" error. Digging around on the net showed that my counter code is longer that 2 characters, which is not true. The following is my country name. [ req_distinguished_name ] countryName = Country Name (2 letter code) countryName_default = US countryName_min= 2 countryName_max= 2 However, if I enable prompt, and just hit ENTER for the same default value, everything went fine. any idea what is going wrong here? thanks, alex.
Re: DTLS ClientHello exchange broken by renegotiation patch in 0.9.8l
Hi Steve,
Is there a 0.9.8m with the DTLS and TLS reneg fix planned in the near
future?
I tried the head of branch from OpenSSL_0_9_8-stable as adviced.
First there was compilation issue due to FIPS issue which
I overcame with ./config no-fips
Then, I run into a segfault on s_server :-(
Thanks,
Alex.
$ ./openssl s_server -dtls1 -debug
Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT
read from 0x6cab10 [0x6d0160] (18437 bytes => 99 (0x63))
- 16 fe ff 00 00 00 00 00-00 00 00 00 56 01 00 00 V...
0010 - 4a 00 00 00 00 00 00 00-4a fe ff 4b 03 52 c1 19 J...J..K.R..
0020 - c6 ae 8c 7d aa 05 42 5e-87 a8 55 ec 2a 78 2e 39 ...}..B^..U.*x.9
0030 - d0 cb 89 cb 9b 7b 67 0a-ce 7f 2a 00 00 00 22 00 .{g...*...".
0040 - 39 00 38 00 35 00 16 00-13 00 0a 00 33 00 32 00 9.8.5...3.2.
0050 - 2f 00 07 00 15 00 12 00-09 00 14 00 11 00 08 00 /...
0060 - 06 01 ..
0063 -
write to 0x6cab10 [0x6da350] (48 bytes => 48 (0x30))
- 16 fe ff 00 00 00 00 00-00 00 00 00 23 03 00 00 #...
0010 - 17 00 00 00 00 00 00 00-17 fe ff 14 7e cd 68 70 ~.hp
0020 - c4 25 fc 74 4d 61 cd fd-ec d6 7e 86 82 36 de 88 .%.tMa~..6..
read from 0x6cab10 [0x6d0160] (18437 bytes => 119 (0x77))
- 16 fe ff 00 00 00 00 00-00 00 01 00 6a 01 00 00 j...
0010 - 5e 00 01 00 00 00 00 00-5e fe ff 4b 03 52 c1 19 ^...^..K.R..
0020 - c6 ae 8c 7d aa 05 42 5e-87 a8 55 ec 2a 78 2e 39 ...}..B^..U.*x.9
0030 - d0 cb 89 cb 9b 7b 67 0a-ce 7f 2a 00 14 7e cd 68 .{g...*..~.h
0040 - 70 c4 25 fc 74 4d 61 cd-fd ec d6 7e 86 82 36 de p.%.tMa~..6.
0050 - 88 00 22 00 39 00 38 00-35 00 16 00 13 00 0a 00 ..".9.8.5...
0060 - 33 00 32 00 2f 00 07 00-15 00 12 00 09 00 14 00 3.2./...
0070 - 11 00 08 00 06 01 ..
0077 -
write to 0x6cab10 [0x6da350] (15 bytes => 15 (0xF))
- 15 fe ff 00 00 00 00 00-00 00 01 00 02 02 2f ../
Segmentation fault
On Wed, Nov 11, 2009 at 3:58 PM, Dr. Stephen Henson wrote:
> On Wed, Nov 11, 2009, Alex Lam wrote:
>
> > Hi all,
> >
> > The patch that disable renegotiation has broken DTLS's ClientHello
> exchange
> > in 0.9.8l.
> > Server sends an Alert together with HelloVerifyRequest...
> >
>
> As mentioned in the announcement 0.9.8l is based on 0.9.8k which has a very
> broken DTLS implementation. Please try the 0.9.8-stable snapshots which
> have
> all the DTLS fixes and provisional reneg extension.
>
> 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
> User Support Mailing Listopenssl-users@openssl.org
> Automated List Manager majord...@openssl.org
>
DTLS ClientHello exchange broken by renegotiation patch in 0.9.8l
Hi all, The patch that disable renegotiation has broken DTLS's ClientHello exchange in 0.9.8l. Server sends an Alert together with HelloVerifyRequest... Thanks, Alex. alexl-lnx2:~/openssl-098l/openssl/apps> ./openssl s_server -dtls1 -debug Using default temp DH parameters Using default temp ECDH parameters ACCEPT read from 0x6ca6e0 [0x6cfd10] (18437 bytes => 99 (0x63)) - 16 fe ff 00 00 00 00 00-00 00 00 00 56 01 00 00 V... 0010 - 4a 00 00 00 00 00 00 00-4a fe ff 4a fb 13 fd 30 J...J..J...0 0020 - ba 23 a9 1c 33 79 70 82-63 e1 2f a8 c4 3e 52 49 .#..3yp.c./..>RI 0030 - 09 0f 31 ff e6 08 20 96-31 c3 26 00 00 00 22 00 ..1... .1.&...". 0040 - 39 00 38 00 35 00 16 00-13 00 0a 00 33 00 32 00 9.8.5...3.2. 0050 - 2f 00 07 00 15 00 12 00-09 00 14 00 11 00 08 00 /... 0060 - 06 01 .. 0063 - write to 0x6ca6e0 [0x6d9f00] (28 bytes => 28 (0x1C)) - 16 fe ff 00 00 00 00 00-00 00 00 00 0f 03 00 00 0010 - 03 00 00 00 00 00 00 00-03 fe ff ... 001c - write to 0x6ca6e0 [0x6d9f00] (15 bytes => 15 (0xF)) - 15 fe ff 00 00 00 00 00-00 00 01 00 02 02 28 ..( ERROR 5875:error:1408A044:SSL routines:SSL3_GET_CLIENT_HELLO:internal error:s3_srvr.c: 725: shutting down SSL CONNECTION CLOSED ACCEPT read from 0x6ca6e0 [0x6cfd10] (18437 bytes => 99 (0x63)) - 16 fe ff 00 00 00 00 00-00 00 01 00 56 01 00 00 V... 0010 - 4a 00 01 00 00 00 00 00-4a fe ff 4a fb 13 fd 30 J...J..J...0 0020 - ba 23 a9 1c 33 79 70 82-63 e1 2f a8 c4 3e 52 49 .#..3yp.c./..>RI 0030 - 09 0f 31 ff e6 08 20 96-31 c3 26 00 00 00 22 00 ..1... .1.&...". 0040 - 39 00 38 00 35 00 16 00-13 00 0a 00 33 00 32 00 9.8.5...3.2. 0050 - 2f 00 07 00 15 00 12 00-09 00 14 00 11 00 08 00 /... 0060 - 06 01 .. 0063 - === alexl-lnx2:~/openssl-098l/openssl/apps> ./openssl s_client -dtls1 -debug CONNECTED(0003) write to 0x6ca8a0 [0x6d46e0] (99 bytes => 99 (0x63)) - 16 fe ff 00 00 00 00 00-00 00 00 00 56 01 00 00 V... 0010 - 4a 00 00 00 00 00 00 00-4a fe ff 4a fb 13 fd 30 J...J..J...0 0020 - ba 23 a9 1c 33 79 70 82-63 e1 2f a8 c4 3e 52 49 .#..3yp.c./..>RI 0030 - 09 0f 31 ff e6 08 20 96-31 c3 26 00 00 00 22 00 ..1... .1.&...". 0040 - 39 00 38 00 35 00 16 00-13 00 0a 00 33 00 32 00 9.8.5...3.2. 0050 - 2f 00 07 00 15 00 12 00-09 00 14 00 11 00 08 00 /... 0060 - 06 01 .. 0063 - read from 0x6ca8a0 [0x6cfed0] (18437 bytes => 28 (0x1C)) - 16 fe ff 00 00 00 00 00-00 00 00 00 0f 03 00 00 0010 - 03 00 00 00 00 00 00 00-03 fe ff ... 001c - write to 0x6ca8a0 [0x6da0c0] (99 bytes => 99 (0x63)) - 16 fe ff 00 00 00 00 00-00 00 01 00 56 01 00 00 V... 0010 - 4a 00 01 00 00 00 00 00-4a fe ff 4a fb 13 fd 30 J...J..J...0 0020 - ba 23 a9 1c 33 79 70 82-63 e1 2f a8 c4 3e 52 49 .#..3yp.c./..>RI 0030 - 09 0f 31 ff e6 08 20 96-31 c3 26 00 00 00 22 00 ..1... .1.&...". 0040 - 39 00 38 00 35 00 16 00-13 00 0a 00 33 00 32 00 9.8.5...3.2. 0050 - 2f 00 07 00 15 00 12 00-09 00 14 00 11 00 08 00 /... 0060 - 06 01 .. 0063 - read from 0x6ca8a0 [0x6cfed0] (18437 bytes => 15 (0xF)) - 15 fe ff 00 00 00 00 00-00 00 01 00 02 02 28 ..( 5876:error:14102410:SSL routines:DTLS1_READ_BYTES:sslv3 alert handshake failure:d1_pkt.c:963:SSL alert number 40 5876:error:1410C0E5:SSL routines:DTLS1_WRITE_APP_DATA_BYTES:ssl handshake failure:d1_pkt.c:1153: alexl-lnx2:~/openssl-HOB/openssl-098l/openssl/apps>
OpenSSL 0.9.8l
Hi all, Just wondering if there is any plan to release OpenSSL 0.9.8l ? If so, do we know when? I'd like to stay with the 0.9.8 branch, but I do see some fixes double committed from the 1.0.0 branch. Thanks, Alex.
How do you detect OpenSSL rekey
Hi all, Is there a way in which an application is made aware the SSL / TLS / DTLS connection rekeyed? Thanks, alex
Session resumption with DTLS - does it work?
Hi, When I hit "R" on openssl s_server and s_client, the session is torn down and not resumed. May I assume DTLS session resumption is broken? Or not supported in s_server and s_client? Thanks, alex.
Re: How to reestablish a DTLS connection?
Datagram is stateless, so to be able to detect a broken session, the application will need to support heart-beat. Alex On Wed, Feb 20, 2008 at 5:31 AM, João Pedro Patriarca <[EMAIL PROTECTED]> wrote: > Hi, > > > > After a DTLS connection established a peer fails (e.g. the client). The > other peer (e.g. the server) maintains the connection state ignoring > client's failure. When the client starts up and tries to establish a new > connection, the server ignore the received packets because they aren't > processed with the previous security parameters. How the DTLS protocol can > be used to reestablish a new connection when the clients starts up again? > > > > Thanks in advance, > > João Pedro Patriarca >
Re: SSL Error connecting to cia.gov
Try this.. ./openssl s_client -tls1 -connect www.cia.gov:443 On 10/24/07, Lutz Jaenicke <[EMAIL PROTECTED]> wrote: > > Isolating the problem is more or less simple: > openssl s_client -connect www.cia.gov:443 > shows the intermittent failures as well, so we can rule out all > applications (curl, wget, ...). Has to be some basic thing. > > I tend to observe the failure with s_client not on the first attempt but > on the nth attempt in a row. I would guess(!) that it may be some > DoS protection measure that prevents too many new connections > (from the same site). > Firefox (and other browsers) would use session caching so that the > server could see that it is actually the same client coming in again. > This of course could only be seen after the client hello with a > proposed session to be reused comes in and could not be done at > the firewall level. > Again: this is just a GUESS! > > Best regards, > Lutz > > Alex Lam wrote: > > That's TLSv1, not SSLv2. > > > > : 01 03 01 00 63 00 00 00 10 00 00 39 00 00 38 00 c..9..8. > > 0010: 00 35 00 00 88 00 00 87 00 00 84 00 00 16 00 00 .5.. > > 0020: 13 00 00 0a 07 00 c0 00 00 33 00 00 32 00 00 2f .3..2../ > > 0030: 00 00 45 00 00 44 00 00 41 00 00 07 05 00 80 03 ..E..D..A... > > 0040: 00 80 00 00 05 00 00 04 01 00 80 00 00 15 00 00 > > 0050: 12 00 00 09 06 00 40 00 00 14 00 00 11 00 00 08 [EMAIL PROTECTED] > > 0060: 00 00 06 04 00 80 00 00 03 02 00 80 c9 f7 89 ff > > 0070: 74 f1 92 59 c8 a0 f1 ba ab c0 dd 89 t..Y > > > > On 10/23/07, *Jake Goulding* <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > Hey all: > > > > We use curl to retrieve webpages, and recently started receiving an > > intermittent (40-60% of the time) error when retrieving a page > > from the > > CIA. About two weeks ago, they switched to running https only, > > with the > > http URLs being forwarded to the https equivalents. > > > > The error we receive is: > > > > $ curl 'https://www.cia.gov/about-cia/faqs/' > > curl: (35) Unknown SSL protocol error in connection to > > www.cia.gov:443 <http://www.cia.gov:443> > > > > Using the --trace option, I see this: > > > > == Info: About to connect() to www.cia.gov <http://www.cia.gov> > > port 443 (#0) > > == Info: Trying 198.81.129.100.. . == Info: connected > > == Info: Connected to www.cia.gov <http://www.cia.gov> > > (198.81.129.100 <http://198.81.129.100>) port 443 (#0) > > == Info: successfully set certificate verify locations: > > == Info: CAfile: /etc/ssl/certs/ca- certificates.crt > > CApath: none > > == Info: SSLv2, Client hello (1): > > => Send SSL data, 124 bytes (0x7c) > > : 01 03 01 00 63 00 00 00 10 00 00 39 00 00 38 00 > c..9..8. > > 0010: 00 35 00 00 88 00 00 87 00 00 84 00 00 16 00 00 > > .5.. > > 0020: 13 00 00 0a 07 00 c0 00 00 33 00 00 32 00 00 2f > .3..2../ > > 0030: 00 00 45 00 00 44 00 00 41 00 00 07 05 00 80 03 > ..E..D..A... > > 0040: 00 80 00 00 05 00 00 04 01 00 80 00 00 15 00 00 > > > > 0050: 12 00 00 09 06 00 40 00 00 14 00 00 11 00 00 08 > [EMAIL PROTECTED] > > 0060: 00 00 06 04 00 80 00 00 03 02 00 80 c9 f7 89 ff > > > 0070: 74 f1 92 59 c8 a0 f1 ba ab c0 dd 89 t..Y > > == Info: Unknown SSL protocol error in connection to > > www.cia.gov:443 <http://www.cia.gov:443> > > == Info: Closing connection #0 > > > > Unfortunately, I don't grok SSL hex :-) . > > > > I have tried this and received the same error with the following > > versions: > > curl-7.12.1-8.rhel4 / openssl-0.9.7a-43.14 > > curl-7.12.1-11.el4 / openssl-0.9.7a-43.16 > > curl-7.16.1 / openssl-0.9.8e > > curl-7.17.0 / openssl-0.9.8f > > > > Firefox does not seem to have any issues with this page. > > > > I asked the curl mailing list about this error, and got the > following > > response: > > > > > This is apparently has nothing to do with curl. I got the same > > > intermittent errors with lynx, w3m, wget, you name it. I am using > > > OpenSSL 0.9.8g 19 Oct 2007. > > > > Any help would be greatly appreciated. Please let me know if I can > > provide
Re: SSL Error connecting to cia.gov
That's TLSv1, not SSLv2. : 01 03 01 00 63 00 00 00 10 00 00 39 00 00 38 00 c..9..8. 0010: 00 35 00 00 88 00 00 87 00 00 84 00 00 16 00 00 .5.. 0020: 13 00 00 0a 07 00 c0 00 00 33 00 00 32 00 00 2f .3..2../ 0030: 00 00 45 00 00 44 00 00 41 00 00 07 05 00 80 03 ..E..D..A... 0040: 00 80 00 00 05 00 00 04 01 00 80 00 00 15 00 00 0050: 12 00 00 09 06 00 40 00 00 14 00 00 11 00 00 08 [EMAIL PROTECTED] 0060: 00 00 06 04 00 80 00 00 03 02 00 80 c9 f7 89 ff 0070: 74 f1 92 59 c8 a0 f1 ba ab c0 dd 89 t..Y On 10/23/07, Jake Goulding <[EMAIL PROTECTED]> wrote: > > Hey all: > > We use curl to retrieve webpages, and recently started receiving an > intermittent (40-60% of the time) error when retrieving a page from the > CIA. About two weeks ago, they switched to running https only, with the > http URLs being forwarded to the https equivalents. > > The error we receive is: > > $ curl 'https://www.cia.gov/about-cia/faqs/' > curl: (35) Unknown SSL protocol error in connection to www.cia.gov:443 > > Using the --trace option, I see this: > > == Info: About to connect() to www.cia.gov port 443 (#0) > == Info: Trying 198.81.129.100... == Info: connected > == Info: Connected to www.cia.gov (198.81.129.100) port 443 (#0) > == Info: successfully set certificate verify locations: > == Info: CAfile: /etc/ssl/certs/ca-certificates.crt > CApath: none > == Info: SSLv2, Client hello (1): > => Send SSL data, 124 bytes (0x7c) > : 01 03 01 00 63 00 00 00 10 00 00 39 00 00 38 00 c..9..8. > 0010: 00 35 00 00 88 00 00 87 00 00 84 00 00 16 00 00 .5.. > 0020: 13 00 00 0a 07 00 c0 00 00 33 00 00 32 00 00 2f .3..2../ > 0030: 00 00 45 00 00 44 00 00 41 00 00 07 05 00 80 03 ..E..D..A... > 0040: 00 80 00 00 05 00 00 04 01 00 80 00 00 15 00 00 > 0050: 12 00 00 09 06 00 40 00 00 14 00 00 11 00 00 08 [EMAIL PROTECTED] > 0060: 00 00 06 04 00 80 00 00 03 02 00 80 c9 f7 89 ff > 0070: 74 f1 92 59 c8 a0 f1 ba ab c0 dd 89 t..Y > == Info: Unknown SSL protocol error in connection to www.cia.gov:443 > == Info: Closing connection #0 > > Unfortunately, I don't grok SSL hex :-) . > > I have tried this and received the same error with the following versions: > curl-7.12.1-8.rhel4 / openssl-0.9.7a-43.14 > curl-7.12.1-11.el4 / openssl-0.9.7a-43.16 > curl-7.16.1 / openssl-0.9.8e > curl-7.17.0 / openssl-0.9.8f > > Firefox does not seem to have any issues with this page. > > I asked the curl mailing list about this error, and got the following > response: > > > This is apparently has nothing to do with curl. I got the same > > intermittent errors with lynx, w3m, wget, you name it. I am using > > OpenSSL 0.9.8g 19 Oct 2007. > > Any help would be greatly appreciated. Please let me know if I can > provide more information. > > Thanks! > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] >
Re: SSL handshake problem.
Hi Alessandro, You will need to set up a handful of cipher & certificate related settings before server and client will join. I suggest you take a look at the apps/s_server.c and apps/s_client.c regards, alex On 10/9/07, Alessandro Baggi <[EMAIL PROTECTED]> wrote: > > I'm trying to make a client/server application with ssl connection but > the handshake doesn't work. > > Reading the manual page I've tried to do this to make ssl connection: > > Server layer: > > SSL_CTX *ssl = NULL; > SSL *new = NULL; > socketdescriptor = socketcreation(); > bind(...); > listen(...); > accept(...); > ssl = SSL_CTX_new(SSLv3_server_method()); > new = SSL_new(ssl); > SSL_set_fd(ssl, socketdescriptor); > SSL_accept(new); > > Client layer: > > SSL_CTX *ssl = NULL; > SSL *new = NULL; > socketdescriptor = socketcreation(...); > connect(..); > ssl = SSL_CTX_new(SSLv3_client_method()); > new = SSL_new(ssl); > SSL_set_fd(ssl, socketdescriptor); > SSL_connect(new); > > When I try to get SSL connection Server give me an error on SSL_accept, > that return -1 with message: Operation not permitted and Client give me > on SSL_connect 0 with the same message. > What is the right way to make an ssl connection? > > Thanks in advice. > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] >
Re: DTLS non-compliant list (based on snapshot 20070801)
Hi Andy, 4347, section 4.2.6 "However, in order to remove sensitivity to fragmentation, the Finished MAC MUST be computed as if each handshake message had been send as a single fragment." My interpretation is that you re-assemble all fragments and fix the handshake header as if it is a single fragment before MAC calculation. (ie. with frag_len = len, frag_offset = 0) Thanks, Alex. On 9/26/07, Andy Polyakov <[EMAIL PROTECTED]> wrote: > > > 4) Handshake "headers" are omitted in the signature computation in > > both CertificateVerify and Finished messages. > > (RFC 4347 does not clearly state what is to be included. However, > > according to the TLS v1.1 (RFC 4346), it shall be the complete handshake > > message, starting from Handshake.msg_type. However, OpenSSL starts at > > Handshake.body) > > 4347 specifies that signature computation must be insensitive to > fragmentation. Handshake header is not same as in TLS and payload is > therefore natural choice for such invariant. Would you suggest to hash > fictitious header with message type and length? Have you asked for > comment on this elsewhere? A. > __ > OpenSSL Project http://www.openssl.org > Development Mailing List [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] >
DTLS non-compliant list (based on snapshot 20070801)
Hi all, There had been a number of email threads on both the user and dev mailing lists regarding DTLS non-RFC-compliance. So, I think it is better to group them together to raise awareness and ensure interoperability with other DTLS stacks. I have verified these on snapshot-2007 08 01 1) Incorrect version number, 0x0100 is used instead of 0xFEFF. 2) When ClientHello is sent in response to HelloVerifyRequest, the random field is different from that sent in the first ClientHello (ref. Sec 4.2.1) 3) Initial ClientHello and HelloVerifyRequest are included in the signature computation for both CertificateVerify and Finished messages. (While Sec 4.2.1 states that the initial ClientHello and HelloVerifyRequest is to be excluded in the signature for Finished, it doesn't mention excluding them in the CertificateVerify. My interpretation is that they should also be excluded because a server should not keep state of the client until a ClientHello with valid cookie is received.) 4) Handshake "headers" are omitted in the signature computation in bothCertificateVerify and Finished messages. (RFC 4347 does not clearly state what is to be included. However, according to the TLS v1.1 (RFC 4346), it shall be the complete handshake message, starting from Handshake.msg_type. However, OpenSSL starts at Handshake.body) 5) ChangeCipherSpec is 2 octets longer than expected. According to the email threads, most of these problems have patches, but they were not submitted. Feel free to comment/add/delete this list. Regards, Alex
