This is an automated email from the ASF dual-hosted git repository.
asf-gitbox-commits pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/mina-site.git
The following commit(s) were added to refs/heads/asf-site by this push:
new dbc2c8f8e Updated site from master
(273732fc795b4a2050dcb51174ca26735a02114a)
dbc2c8f8e is described below
commit dbc2c8f8e3bab2a5e286c24d5fef5a43f0cb3f07
Author: jenkins <[email protected]>
AuthorDate: Tue Sep 15 07:55:01 2026 +0000
Updated site from master (273732fc795b4a2050dcb51174ca26735a02114a)
---
content/mina-project/index.html | 7 +-
.../technical-documentation/ssl-tls-internal.html | 159 ++++++++++++++++++++-
content/sitemap.xml | 6 +-
3 files changed, 166 insertions(+), 6 deletions(-)
diff --git a/content/mina-project/index.html b/content/mina-project/index.html
index d27dd9e96..cdfe44142 100644
--- a/content/mina-project/index.html
+++ b/content/mina-project/index.html
@@ -132,7 +132,12 @@
<li>a networking · socket library.</li>
</ul>
<p>However, it’s much more than that. Please take a look around the
list of the <em><a href="features.html">features</a></em> that enable rapid
network application development, and <em><a href="testimonials.html">what
people says about MINA</a></em>.</p>
-<p>Please grab yourself a <em><a href="downloads_2_0.html">2.0.x
download</a></em> or a <em><a href="downloads_2_1.html">2.1.x
download</a></em>, try our <em><a href="quick-start-guide.html">Quick Start
Guide</a></em>, surf our <em><a href="faq.html">FAQ</a></em> or start join us
on <em><a href="../contact.html">our community</a></em></p>
+<p>Please grab yourself a <em><a href="downloads_2_2.html">2.1.x
download</a></em>, a <em><a href="downloads_2_1.html">2.1.x download</a></em>
or a <em><a href="downloads_2_0.html">2.0.x download</a></em>, try our <em><a
href="quick-start-guide.html">Quick Start Guide</a></em>, surf our <em><a
href="faq.html">FAQ</a></em> or start join us on <em><a
href="../contact.html">our community</a></em></p>
+<h2 id="warning">WARNING</h2>
+<p>The fix for <strong>CVE-2026-47065</strong> changed the form
<strong>MINA</strong> writes for serialized objects exchanged through
<em>IoBuffer.putObject</em> / <em>getObject</em> and
<em>ObjectSerializationCodecFactory</em>: after the class name, the full
standard <strong>Java</strong> serialization class descriptor is now
written.</p>
+<p>Streams produced by <strong>2.2.7</strong>, <strong>2.1.12</strong> or
<strong>2.0.28</strong> and earlier cannot be read by <strong>2.2.8</strong>,
<strong>2.1.13</strong> or <strong>2.0.29</strong> and later, and streams
produced by the newer releases cannot be read by the older ones.</p>
+<p>Arrays, primitives and non-Serializable classes are unaffected.</p>
+<p>Upgrades across this boundary fail with a <em>BufferDataException</em>
wrapping an <em>EOFException</em> or a <em>StreamCorruptedException</em>, and
payloads persisted before the upgrade become unreadable after it.</p>
<div class="news">
<h1 id="news">News</h1>
diff --git a/content/mina-project/technical-documentation/ssl-tls-internal.html
b/content/mina-project/technical-documentation/ssl-tls-internal.html
index 769d27d6c..9b0ca5da2 100644
--- a/content/mina-project/technical-documentation/ssl-tls-internal.html
+++ b/content/mina-project/technical-documentation/ssl-tls-internal.html
@@ -202,7 +202,7 @@
</ul>
<p>Most of the time, records will be smaller (and the packet size is stored in
the TLS header).</p>
<p>Now, considering the very nature of <strong>TCP</strong>, we may receive a
TLS record in small chunks, or more than one TLS record in a packet of data. We
have to deal with both cases.</p>
-<p>We will use an internal pending buffer that will contain the incoming data
until they can be fully processed. The important point is that the
<em>SslEngine</em> class is using <em>ByteBuffer</em> to get things done,
though a set of methods:</p>
+<p>We will use an internal pending buffer that will contain the incoming data
until they can be fully processed. The important point is that the
<em>SslEngine</em> class is using <em>ByteBuffer</em> to get things done,
through a set of methods:</p>
<ul>
<li><em>wrap(ByteBuffer src, [int offset, int length,] ByteBuffer dst)</em>:
Encrypt the data from the source buffer into the destination buffer</li>
<li><em>unwrap(ByteBuffer src, [int offset, int length,] ByteBuffer dst)</em>:
Decrypt the data from the source buffer into the destination buffer</li>
@@ -219,7 +219,162 @@
|
+----------------+
+--> |
uncrypted data | --> Application
+----------------+
-</code></pre><h4 id="receiving-small-chunks">Receiving small chunks</h4>
+</code></pre><p>Also note that we receive data by chunks (starting with a 1024
buffer), which may not be decodable. And this is problematic froma performance
piont of vue: Imagine we are going to receive a block of 55Kb of data, it
won’t fit on a single TLS packet. We will need 4 TLS packets to contain
all the data. And we start by reading a 1024 bytes buffer…</p>
+<p>Here is how MINA will proceed:</p>
+<ul>
+<li>Read 1024 bytes in the incoming buffer</li>
+<li>Allocate a buffer capable of storing the size defined in the TLS
packet</li>
+<li>Try to decode it (it will fail)</li>
+<li>So free the destination buffer</li>
+<li>Resize the incoming buffer, increasing its size to hold 2048 more
bytes</li>
+<li>Try to read 2048 bytes (we now have 3072 bytes in the buffer)</li>
+<li>Allocate a buffer capable of storing the size defined in the TLS
packet</li>
+<li>Try to decode it (it will fail again…)</li>
+<li>So free the destination buffer</li>
+<li>Resize the incoming buffer, adding 4096 bytes into it</li>
+<li>Repeat reading 4096 bytes stored in the 3072 + 4096 sized buffer (7168
bytes)</li>
+<li>Allocate a buffer capable of storing the size defined in the TLS
packet</li>
+<li>Try to decode it (it will still fail…): The TLS packet contains
16384 - padding bytes of data.</li>
+<li>So free the destination buffer</li>
+<li>Resize again the incoming buffer, adding 8192 bytes</li>
+<li>Read 8192 bytes leading to a incoming buffer containing 15360 bytes</li>
+<li>Allocate a buffer capable of storing the size defined in the TLS
packet</li>
+<li>Which won’t be decoded either</li>
+<li>So free the destination buffer</li>
+<li>Resize the incoming buffer, adding 16384 bytes, leading to a 31744 bytes
buffer</li>
+<li>Read 16384 bytes of data</li>
+<li>Allocate a buffer capable of storing the size defined in the TLS
packet</li>
+<li>And now the decoding could work!</li>
+<li>Copy the decoded buffer into a buffer that will be send to the
IoHandler</li>
+<li>Free the decoing buffer</li>
+<li>and as we have some remaining data in the incoming buffer,</li>
+<li>Allocate a buffer capable of storing the size defined in the TLS
packet</li>
+<li>Try to decode it (and it will fail…)</li>
+<li>Free the buffer</li>
+<li>etc etc until we have read and processed all the data.</li>
+</ul>
+<p>Here is how it translates in method calls:</p>
+<pre><code>AbstractPollingIoProcessor.read
+ IoBuffer.allocate(1024)
+ ...
+ SslFilter.messageReceived
+ SslHandler.receive
+ receive_start
+ resume_decode_buffer
+ mDecodedBuffer <- message
+ receive_loop
+ dest <- allocate(ZERO)
+ SslEngine.unwrap() -> BUFFER_OVERFLOW
+ dest free
+ suspend_decode_buffer
+ throw_pending_error
+ forward_writes
+ forward_received
+ forward_events
+ IoBuffer.allocate(2048)
+ ...
+ SslFilter.messageReceived
+ SslHandler.receive
+ receive_start
+ resume_decode_buffer
+ mDecodedBuffer.expand -> 3072
+ source free
+ receive_loop
+ dest <- allocate(ZERO)
+ SslEngine.unwrap() -> BUFFER_OVERFLOW
+ dest free
+ suspend_decode_buffer
+ throw_pending_error
+ forward_writes
+ forward_received
+ forward_events
+ IoBuffer.allocate(4096)
+ ...
+ SslFilter.messageReceived
+ SslHandler.receive
+ receive_start
+ resume_decode_buffer
+ mDecodedBuffer.expand -> 7168
+ source free
+ receive_loop
+ dest <- allocate(ZERO)
+ SslEngine.unwrap() -> BUFFER_OVERFLOW
+ dest free
+ suspend_decode_buffer
+ throw_pending_error
+ forward_writes
+ forward_received
+ forward_events
+ IoBuffer.allocate(8192)
+ ...
+ SslFilter.messageReceived
+ SslHandler.receive
+ receive_start
+ resume_decode_buffer
+ mDecodedBuffer.expand -> 15360
+ source free
+ receive_loop
+ dest <- allocate(ZERO)
+ SslEngine.unwrap() -> BUFFER_OVERFLOW
+ dest free
+ suspend_decode_buffer
+ throw_pending_error
+ forward_writes
+ forward_received
+ forward_events
+ IoBuffer.allocate(16384)
+ ...
+ SslFilter.messageReceived
+ SslHandler.receive
+ receive_start
+ resume_decode_buffer
+ mDecodedBuffer.expand -> 31744
+ source free
+ receive_loop
+ dest <- allocate(16400)
+ SslEngine.unwrap() -> OK
+ mReceiveQueue <- dest (16367 useful data, 33 padding removed)
+ receive_loop
+ dest <- allocate(ZERO)
+ SslEngine.unwrap() -> BUFFER_OVERFLOW
+ dest free
+ suspend_decode_buffer
+ throw_pending_error
+ forward_writes
+ forward_received
+ next.messageReceived -> We are propagating the first chunk of
data to the IoHandler
+ forward_events
+</code></pre><p>As we can see, the mDecodedBuffer has been expended 4 times,
so is the session receiving buffer, and we have allocated 5 destination buffer
(although four have been allocated with a 0 size).</p>
+<p>To schematize, here are the allocated (or resized) buffers:</p>
+<pre><code>input mDecodedBuffer
++----+ +----+
+|1024| -> |1024|
++----+ +----+
+
++--------+ +----+--------+
+| 2048 | -> |1024| 2048 | 3072
++--------+ +----+--------+
+
++------------+ +----+--------+------------+
+| 4096 | -> |1024| 2048 | 4096 | 7168
++------------+ +----+--------+------------+
+
++----------------+ +----+--------+------------+----------------+
+| 8192 | -> |1024| 2048 | 4096 | 8192 | 15360
++----------------+ +----+--------+------------+----------------+
+
++--------------------+
+----+--------+------------+----------------+--------------------+
+| 16384 | -> |1024| 2048 | 4096 | 8192 |
16384 | 31744
++--------------------+
+----+--------+------------+----------------+--------------------+
+ ^ ^
^
+ | |
|
+ +----- First chunk of data, 16367 bytes ------+--
some more --+
+</code></pre><p>As we can see it’s a VERY costly process, where we
allocate <em>many</em> buffers that get discardd immediately. There is a lot of
room for improvement!</p>
+<p>We can decide to use a bigger input buffer. By default, it’s sized to
1Kb in order to avoid using a lot of memory, and it’s fine when we only
receive small chunk of data. For big data exchanges, it would be valuable to
define a bigger size.
+The key here is that there is an adaptative mechanism where we double the size
of the input buffer if the read data fulfilled it (uo to a limit), and divide
it by two if we read less than what the buffer could contain. This adaptative
mechanism is fine when we don’t know the size of the receivd data, ad if
it can vary a lot. When the incoming data are stable, we will oscillate between
two sizes (doubling the buffer size, then divide it by two) which is a huge
penalty to pay.</p>
+<p>Regarding the mDecoderBuffer, it’s the same thing: until we can
successfully decode it its size will increase. As a TLS record is always maxing
to 16384 bytes, it would be a better idea to allocate a buffer this size and
use it, when we know we will be able to decode it (ie when the input bufffer is
bigger than the TLS data size, plus some margin, because of the padding
bytes).</p>
+<p>All in all, when in TLS mode, the proper strategy would be to use a 16Kb +
padding input buffer, and same thing for the mDecodedBuffer, when we have
received enough data.</p>
+<h4 id="receiving-small-chunks">Receiving small chunks</h4>
<p>In the case we receive a <strong>TLS</strong> record split in several
packets, we won’t be able to uncrypt them until we have received a full
<strong>TLS</strong> record.</p>
<p>We need to collect at least a full TLS record before calling the
<em>SslEngine.unwrap()</em> method, otherwise it will return a
<strong>BUFFER_UNDERFLOW</strong> error.</p>
<p>NOTE: the check is also done inside <em>SSLEngine</em>, but it’s a
good idea to do it outside, to avoid a good chunk of useless work to be
done.</p>
diff --git a/content/sitemap.xml b/content/sitemap.xml
index 725753a13..1fa78466c 100644
--- a/content/sitemap.xml
+++ b/content/sitemap.xml
@@ -944,7 +944,7 @@
<url>
<loc>https://mina.apache.org/mina-project/</loc>
- <lastmod>2023-07-03T15:48:21+02:00</lastmod>
+ <lastmod>2026-09-15T09:46:59+02:00</lastmod>
</url>
<url>
@@ -959,7 +959,7 @@
<url>
<loc>https://mina.apache.org/mina-project.html</loc>
- <lastmod>2026-07-31T17:55:46+02:00</lastmod>
+ <lastmod>2026-09-15T09:46:59+02:00</lastmod>
</url>
<url>
@@ -1069,7 +1069,7 @@
<url>
<loc>https://mina.apache.org/mina-project/technical-documentation/ssl-tls-internal.html</loc>
- <lastmod>2026-07-31T17:55:46+02:00</lastmod>
+ <lastmod>2026-09-15T09:46:59+02:00</lastmod>
</url>
<url>
