mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Darryl L. Miles (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DIRMINA-1017) SSLEngine BUFFER_OVERFLOW (unwrap)
Date Tue, 11 Aug 2015 05:42:45 GMT

    [ https://issues.apache.org/jira/browse/DIRMINA-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14681280#comment-14681280
] 

Darryl L. Miles commented on DIRMINA-1017:
------------------------------------------

On what basis do you think something is broken in the Android SSL/TLS implementation ?

Maybe you are not aware but SSL/TLS allows upto 64kb frame, a frame is an encapsulation of
application plain text what has been encrypted and possibly padded and then had HMAC applied
and then some SSL/TLS protocol bytes added to describe it.

What appears to happen here is that Java SSLEngine implementation during decryption will not
break plain text part into smaller chunks for you, it will only give you an entire frame decoded.

If anything this is a failing in the java SSLEngine API, by silently truncating the data on
the 2nd attempt is has effectively introduced a potential security attack vector that could
have been better mitigated by making the error return stick.  Nothing good can result from
their current choice, it errs on the side of causing a security problem no preventing one
for a security conscious feature.  This point is moot.

Note this is a feature of all SSL/TLS implementations (frame sizes upto 64kb), it just so
happens that Android is capable of generating larger frames than you are seeing from your
other SSL client.  This is actually good for mobile because a frame has additional overhead
so the larger the frames (more application plain text per frame) the lower the % of overhead
from the SSL/TLS protocol adds to it.  The cheaper your mobile data usage bill.

But most application uses smaller application buffers to feed their SSL encryption stream,
usually <= 4k.


> 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)

Mime
View raw message