Thor Lancelot Simon wrote:
I have an application which reads data into fixed-size buffers which it
maintains per session. It uses non-blocking IO and select() when a read
returns SSL_ERROR_WANT_{READ,WRITE}.
To conserve memory I reduced the buffer size from 16384 to 8192 and saw
sessions
Lutz Jaenicke wrote:
Thor Lancelot Simon wrote:
On Fri, Aug 01, 2008 at 03:49:01PM +0200, Lutz Jaenicke wrote:
This leads to another problem, actually:
A malicious peer which sends data as fast as it can can get _more_ data
into the socket buffer while the application is trying to read to
Thor Lancelot Simon wrote:
I think I've discovered another problem with the current non-blocking API.
I have an application which reads data into fixed-size buffers which it
maintains per session. It uses non-blocking IO and select() when a read
returns SSL_ERROR_WANT_{READ,WRITE}.
To
On Fri, Aug 01, 2008 at 03:49:01PM +0200, Lutz Jaenicke wrote:
Thor Lancelot Simon wrote:
The record size of the SSL record is predetermined by the sender with
16k being the maximum size specified by the protocol.
32K for SSLv2, no?
In order to return the (decrytped and authenticated) data
Thor Lancelot Simon wrote:
On Fri, Aug 01, 2008 at 03:49:01PM +0200, Lutz Jaenicke wrote:
Thor Lancelot Simon wrote:
The record size of the SSL record is predetermined by the sender with
16k being the maximum size specified by the protocol.
32K for SSLv2, no?
I stopped caring
Care to explain why you can't discuss how the API might or might not work
without throwing around gratuitous insults?
They are warnings, not insults. I'm sorry you see them that way.
This last message to which
I'm responding is merely condescending; the previous was downright
insulting and
I think I've discovered another problem with the current non-blocking API.
I have an application which reads data into fixed-size buffers which it
maintains per session. It uses non-blocking IO and select() when a read
returns SSL_ERROR_WANT_{READ,WRITE}.
To conserve memory I reduced the buffer
3) We call SSL_read with our 8k buffer. The received data does not fit,
so OpenSSL buffers it internally and returns 8K with
SSL_ERROR_WANT_READ.
How it can both succeed (returning 8K) and fail (returning
SSL_ERROR_WANT_READ)?
DS
On Thu, Jul 31, 2008 at 11:49:05AM -0700, David Schwartz wrote:
3) We call SSL_read with our 8k buffer. The received data does not fit,
so OpenSSL buffers it internally and returns 8K with
SSL_ERROR_WANT_READ.
How it can both succeed (returning 8K) and fail (returning
Let me trace through the application. Looking at the source code, it
appears that the application may have a bug (checking the SSL error stack
via SSL_get_error() when SSL_read() returned 0) but that what
is actually
happening here is:
1) SSL_read() is returning 0, SSL_get_error() is
On Thu, Jul 31, 2008 at 01:02:16PM -0700, David Schwartz wrote:
Let me trace through the application. Looking at the source code, it
appears that the application may have a bug (checking the SSL error stack
via SSL_get_error() when SSL_read() returned 0) but that what
is actually
If this is really what's happening, it's a bug in OpenSSL. The
application
should be able to pass a 1-byte buffer the OpenSSL and get 1 byte of
decrypted data.
Consider that when running with the current non-blocking API, once OpenSSL
takes the data out of the socket buffer, both
Let me just state this one more time one other way to help people wrap their
brain around it. The OpenSSL library is a black box. You are not supposed to
look inside the black box.
If you want to get decrypted plaintext from the black box, the black box may
or may not need to read data from the
On Thu, Jul 31, 2008 at 05:14:09PM -0700, David Schwartz wrote:
Let me just state this one more time one other way to help people wrap their
brain around it. The OpenSSL library is a black box. You are not supposed to
look inside the black box.
If you want to get decrypted plaintext from
14 matches
Mail list logo
