[openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

[Hubert Kario via RT]

On Monday 12 October 2015 16:19:43 Matt Caswell via RT wrote:
> On 12/10/15 16:39, Matt Caswell via RT wrote:
> > On 12/10/15 16:03, Alessandro Ghedini via RT wrote:
> >> On Mon, Oct 12, 2015 at 01:45:20PM +0000, Hubert Kario via RT 
wrote:
> >>> On Friday 09 October 2015 18:05:19 Matt Caswell via RT wrote:
> >>>> On 09/10/15 19:02, Hubert Kario via RT wrote:
> >>>>> And for good measure, I also created a test script that
> >>>>> combines fragmentation with interleaving.
> >>>> 
> >>>> Did you try my patch with it? And if so what happened?
> >>> 
> >>> I'm using interleave-data-102.patch attached to this ticket.
> >>> 
> >>> So, for state-machine-rewrite branch it doesn't apply, there's no
> >>> ssl/s3_pkt.c file.
> >>> 
> >>> For current 1.0.1 branch, the patch applies, test case results are
> >>> as
> >>> 
> >>> follows:
> >>>  * test-openssl-3712.py - pass
> >>>  * test-interleaved-application-data-in-renegotiation.py - pass
> >>>  * test-interleaved-application-data-and-fragmented-handshakes-in-
> >>> 
> >>> renegotiation.py - pass
> >>> 
> >>> For current 1.0.2 branch, the patch applies, tests case results
> >>> are as>>> 
> >>> follows:
> >>>  * test-openssl-3712.py - pass
> >>>  * test-interleaved-application-data-in-renegotiation.py - pass
> >>>  * test-interleaved-application-data-and-fragmented-handshakes-in-
> >>> 
> >>> renegotiation.py - pass
> >>> 
> >>> for current master the patch doesn't apply, just like with state-
> >>> machine-rewrite there's no ssl/s3_pkt.c file
> >>> 
> >>> Note: the two latter test cases need the s_server run in -www
> >>> mode, the first test case ignores server response so will work
> >>> regardless, that may be why Alessandro testing doesn't show the
> >>> issue as fixed>> 
> >> Ah, yep, with -www it works for me too. Note that on master the
> >> file to change should be ssl/record/ssl3_record.c. However, while
> >> the patch applies cleanly to this file, all the tests fail (even
> >> with -www). It seems that the field in_read_app_data is never
> >> true, so the UNEXPECTED_MESSAGE alert is sent.> 
> > The value of "in_read_app_data" not being true when it is supposed
> > to
> > appears to be running into a slightly different bug. It's also
> > present in 1.0.2 but you have to switch off version negotiation. So
> > running s_server like this in 1.0.2 and rerunning Hubert's test
> > will hit it:
> > 
> > openssl s_server -www -tls1_2
> > 
> > The 1.0.2 version negotiation is hiding the issue. In master version
> > neg has been completely rewritten and simplified - but in doing so
> > no longer hides the problem. :-(
> 
> Having done some more digging it seems the problem only occurs if you
> get the initial handshake, following by a second reneg handshake *and*
> interleaved app data all within the scope of a *single* SSL_read
> call. AFAICT if SSL_read returns between the first handshake and the
> second, you don't get the problem.

It's completely valid and not at all unlikely to have two record layer 
records inside single TCP packet...

-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20151013/c2d18d21/attachment.sig>