[
https://issues.apache.org/jira/browse/DIRMINA-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14644138#comment-14644138
]
Emmanuel Lecharny commented on DIRMINA-1017:
--------------------------------------------
I just committed the patch in 2.0.
We should check if it applies in 3.0.
> SSLEngine BUFFER_OVERFLOW (unwrap)
> ----------------------------------
>
> Key: DIRMINA-1017
> URL: https://issues.apache.org/jira/browse/DIRMINA-1017
> Project: MINA
> Issue Type: Bug
> Components: SSL
> Affects Versions: 2.0.9
> Environment: Android
> Reporter: Terence Marks
> Fix For: 2.0.10
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> I've discovered an issue with the SslHandler class when the unwrap method is
> called on the local SSLEngine member (SslHandler.sslEngine).
> If the returned status is SSLEngineResult.Status.BUFFER_OVERFLOW, the
> capacity of the output buffer (SslHandler.appBuffer) can be increased to a
> size which still may is not large enough for the result.
> I have reproduced this issue consistently by sending a 4k frame over TLS1.2
> to an android device. The frame gets heavily fragmented, sometimes into 6
> frames, and the SSLEngine does not unwrap the frame until all the bytes have
> been received (since the hash is based on the entire frame).
> Since the frame gets heavily fragmented, the last segment of the frame can be
> lower than 2048 bytes. Hence by increasing the capacity by << 1, the output
> buffer will still be under the required size. (Have a look through SslHandler
> source for "appBuffer.capacity(appBuffer.capacity() << 1);")
> Anyway, the fix is really easy. Change the line:
> appBuffer.capacity(appBuffer.capacity() << 1);
> to:
> appBuffer.capacity(sslEngine.getSession().getApplicationBufferSize());
> This is actually in the java docs
> (http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/SSLEngine.html) for
> the overflow buffer case.
> Hope this helps,
> Terence
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
