[
https://issues.apache.org/jira/browse/DIRMINA-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14681280#comment-14681280
]
Darryl L. Miles edited comment on DIRMINA-1017 at 8/11/15 5:45 AM:
-------------------------------------------------------------------
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 (because the HMAC and frame type-id are a constant extra
bytes added per frame, while the padding is usually upto 15 bytes but varies
with padding and cipher choice). Less data sent means a cheaper mobile data
usage bill.
But most application uses smaller application buffers to feed their SSL
encryption stream, usually <= 4k.
was (Author: dlmiles):
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)
