Ticket 1019 was opened for this issue in 2005.
If desired, I can produce a bash script to reproduce this problem.
Please let me know.
Thanks,
Carl
p.s. Some info from gdb:
Breakpoint 1, ssl3_read_bytes (s=0xb38ffec8, type=22, buf=0xb36efaa8
"\1", len=4, peek=0)
at s3_pkt.c:1209
1209 al=SSL_AD_UNEXPECTED_MESSAGE;
(gdb) p rr->type
$1 = 23
(gdb) p *rr
$2 = {type = 23, length = 175, off = 0,
data = 0xb37007fd
"klmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz\nR\n\346q\304\24!\335T&\22≷\277\313mU\371\277-\366\f\f\f\f\f"...,
input = 0xb37007fd
"klmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz\nR\n\346q\304\24!\335T&\22≷\277\313mU\371\277-\366\f\f\f\f\f"...,
comp = 0x0, epoch = 0,
seq_num = 0}
(gdb) p s->s3->in_read_app_data
$3 = 0
(gdb) bt
#0 ssl3_read_bytes (s=0xb38ffec8, type=22, buf=0xb36efaa8 "\1", len=4,
peek=0) at s3_pkt.c:1209
#1 0x00b97d53 in ssl3_get_message (s=0xb38ffec8, st1=4384, stn=4385,
mt=-1, max=20000,
ok=0xbf911558) at s3_both.c:394
#2 0x00b8e91e in ssl3_get_server_hello (s=0xb38ffec8) at s3_clnt.c:702
#3 0x00b8dd41 in ssl3_connect (s=0xb38ffec8) at s3_clnt.c:266
#4 0x00b95dbc in ssl3_write_bytes (s=0xb38ffec8, type=23,
buf_=0xb478a0af, len=0)
at s3_pkt.c:526
#5 0x00b93ca7 in ssl3_write (s=0xb38ffec8, buf=0xb478a0af, len=0) at
s3_lib.c:2544
#6 0x00ba79c4 in SSL_write (s=0xb38ffec8, buf=0xb478a0af, num=0) at
ssl_lib.c:931
#7 0x0807a6c2 in s_client_main (argc=0, argv=0xbf911ec4) at
s_client.c:1162
#8 0x08055163 in do_cmd (prog=0xb4952fa0, argc=7, argv=0xbf911ea8) at
openssl.c:396
#9 0x08054e5e in main (Argc=7, Argv=0xbf911ea8) at openssl.c:315
(gdb)
If this is true, this is a bug in the implementation. The TLS RFCs
state that application data can come in at any time, including during
renegotiation handshakes (with one exception, and that is that
'ChangeCipherSpec' and 'Finished' must be back-to-back). Please send
this report to [email protected].
-Kyle H
On Mon, Jan 18, 2010 at 2:06 PM, Carl <[email protected]> wrote:
> Please note this question is not about the TLS vulnerability reported in
> Nov 2009.
>
> When an openssl client requests a renegotiation while the server is
> sending data the client generates a fatal alert of "unexpected message".
>
> This behavior doesn't seem very robust because the client may not know
> when the server is about to send application data. Are there any
> workarounds to handle this scenario?
>
> This issue has been raised on this email list over the years but I can't
> find any responses. Here are a couple of the latest related posts:
> >From 2007: http://marc.info/?l=openssl-users&m=118897608028360&w=2
> >From 2005: http://marc.info/?l=openssl-users&m=110858071920301&w=2
>
> The system I'm using has openssl 0.9.8k.
>
> Thanks,
>
> Carl
>
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List [email protected]
> Automated List Manager [email protected]
>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [email protected]
Automated List Manager [email protected]
