Re: [7.7.1] SSLRecordError: Unexpected end of stream

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [7.7.1] SSLRecordError: Unexpected end of stream

mkobetic
I'm not convinced that this is a correct fix. I'd worry that simple break in communication could be interpreted as a valid end of the stream, i.e. I'd expect that you could get less content than you should have without any indication that it happened. I don't know off the top of my head if gzip has any content truncation protection, so if you're not getting errors from that layer, maybe you're fine. But I believe that endTest should only answer true if the entire content was successfully delivered.

"Thushar G R"<[hidden email]> wrote:

> Hi Boris and all,
>
> We had the same problem here today. "proceed"ing on *ParsingSimpleBodyError
> *will solve the problem when its not a gzip stream. But if it is, then
> for us it dint do any good. whereas when we change the method
>
> *FragmentStream >> endTest*
> * *
> * ^[self checkAndHandleAtEnd.*
> * false]*
> * on: EndOfStreamNotification*
> * do: [:ex | ex return: true]*
>
> with
>
> *FragmentStream >> endTest*
> * *
> * ^[self checkAndHandleAtEnd.*
> * false]*
> * on: SSLRecordError*
> * do: [:ex | ex return: true]*
>
> we get good result even without proceeding on *ParsingSimpleBodyError* code.
> And it makes sense too since the *SSLConnection>>nextDataRecordFor:*  catches
> an *EndOfStreamNotification *and throws a *SSLRecordError*, and so in the
> method *endTest *this *EndOfStreamNotification  *is never detected.
>
> But this is just our change...and we still need to confirm on this as of how
> to implement this without other troubles. So as experts if u guys can tell
> if its the problem with our approach or that if this is a legitimate bug?
>
>
> Thanks in Advance,
>
> G R Thushar
> Tur Technologies India.
>
>
>
>
> We had the same problem here
>
> On Tue, Feb 15, 2011 at 9:45 PM, Boris Popov, DeepCove Labs <
> [hidden email]> wrote:
>
> > I ran into the subject exception today when receiving a response over SSL
> > without content-length as per response headers below,
> >
> >
> >
> > HTTP/1.0 200
> >
> > content-type: application/json
> >
> > cache-control: Private
> >
> > cache-control: no-cache
> >
> > expires: -1
> >
> > pragma: no-cache
> >
> > date: Tue, 15 Feb 2011 15:58:07 GMT
> >
> > server: 8599.8006
> >
> > mime-version: 1.0
> >
> > Vary: Accept-Encoding, User-Agent
> >
> >
> >
> > It is worth noting that the response was received in full by the time the
> > exception was raised, which makes sense, as it appears that the HTTP client
> > is simply unable to treat this ‘no more data’ condition in the absence of
> > content-length as valid. By contrast, curl seems to get the response without
> > any indication of abnormalities in its verbose output. In the meantime,
> > #proceed’ing ParsingSimpleBodyError seems to get me a full response.
> >
> >
> >
> > Unhandled exception: SSLRecordError: Unexpected end of stream !
> >
> > Net.HttpBuildHandler(Net.MimeParserHandler)>>handleStartBody:exception:
> >
> > Net.HttpBuildHandler>>handleStartBody:exception:
> >
> > optimized [] in Net.MimeParserHandler>>safelyRead:from:into:
> >
> > BlockClosure>>cull:
> >
> > Security.SSLRecordError(GenericException)>>performHandler:
> >
> > Security.SSLRecordError(GenericException)>>propagatePrivateFrom:
> >
> > Security.SSLRecordError(GenericException)>>propagateFrom:
> >
> > Security.SSLRecordError(GenericException)>>propagate
> >
> > Security.SSLRecordError(GenericException)>>raiseSignal
> >
> > Security.SSLRecordError class(GenericException class)>>raiseSignal:
> >
> > optimized [] in Security.SSLConnection>>nextDataRecordFor:
> >
> > BlockClosure>>cull:
> >
> > EndOfStreamNotification(GenericException)>>performHandler:
> >
> > EndOfStreamNotification(GenericException)>>propagatePrivateFrom:
> >
> > EndOfStreamNotification(GenericException)>>propagateFrom:
> >
> > EndOfStreamNotification(GenericException)>>propagate
> >
> > EndOfStreamNotification(GenericException)>>raiseSignal
> >
> > EndOfStreamNotification class(GenericException class)>>raiseRequestFrom:
> >
> > ExternalReadAppendStream(BufferedExternalStream)>>pastEnd
> >
> > ExternalReadAppendStream(ExternalReadStream)>>next
> >
> > Security.SSLRecord>>readFrom:in:
> >
> > Security.SSLConnection>>nextRecordFor:
> >
> > optimized [] in [] in Security.SSLConnection>>nextDataRecordFor:
> >
> > BlockClosure>>on:do:
> >
> > optimized [] in Security.SSLConnection>>nextDataRecordFor:
> >
> > BlockClosure>>on:do:
> >
> > Security.SSLConnection>>nextDataRecordFor:
> >
> > Security.FragmentStream>>checkAndHandleAtEnd
> >
> > optimized [] in Security.FragmentStream>>endTest
> >
> > BlockClosure>>on:do:
> >
> > Security.FragmentStream>>endTest
> >
> > Security.FragmentStream>>atEnd
> >
> > Security.InputOutputStream>>atEnd
> >
> > EncodedStream>>atEnd
> >
> > Net.BodyStream>>atEnd
> >
> > optimized [] in Net.MimeParserHandler>>safelyRead:from:into:
> >
> >
> >
> > -Boris
> >
> > _______________________________________________
> > vwnc mailing list
> > [hidden email]
> > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
> >
> >
>
>
> --
> thuchu
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [7.7.1] SSLRecordError: Unexpected end of stream

mkobetic
[hidden email] wrote:
> Sorry, I didn't get around to looking at this yet. Is there a publicly accessible URL that we could use to look at the details ?

Just to update people on the list, we looked at this problem and concluded that in this particular case the SSL layer correctly detects a missing SSL close_notify alert, which is a required protection against truncation attacks. The HTTP layer responds to this condition with the ParsingSimpleBodyError. It would not be correct to suppress this exception in the framework, it is up to the application to accept the possibly incomplete body (and resume the exception) or abort and do whatever error handling is necessary.

I wouldn't mind getting more details about the related issue with the gzipped content and why resuming the exception in that case doesn't work. However I'm fairly confident that the proposed fix that suppresses the SSLRecordError at the framework level is not acceptable general solution. That of course doesn't mean that it's not acceptable in particular instance.

HTH,

Martin

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc