SSL_CTX_set_mode(3)
SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER
Make it possible to retry SSL_write() with changed buffer
location (the buffer contents must stay the same). This is not the
default to avoid the mis-
conception that non-blocking SSL_write() behaves like
non
Darryl Miles wrote:
SSL_CTX_set_mode(3)
SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER
Make it possible to retry SSL_write() with changed buffer
location (the buffer contents must stay the same). This is not the
default to avoid the mis-
conception that non-blocking SSL_write
SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER is likely for those OSes (*glares
at Windows in particular*) which require locking allocated memory in
place, performing an operation on it, and then unlocking it (to allow
the OS to manage the placement of the memory block in physical
memory).
It's no
> SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER is likely for those OSes (*glares
> at Windows in particular*) which require locking allocated memory in
> place, performing an operation on it, and then unlocking it (to allow
> the OS to manage the placement of the memory block in physical
>
Mark wrote:
SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER is likely for those OSes (*glares
at Windows in particular*) which require locking allocated memory in
place, performing an operation on it, and then unlocking it (to allow
the OS to manage the placement of the memory block in physical
memory
On Thu, Jun 22, 2006 at 10:41:14PM +0100, Darryl Miles wrote:
> SSL_CTX_set_mode(3)
>
> SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER
> Make it possible to retry SSL_write() with changed buffer
> location (the buffer contents must stay the same). This is not the
> defaul
Bodo Moeller wrote:
On Thu, Jun 22, 2006 at 10:41:14PM +0100, Darryl Miles wrote:
SSL_CTX_set_mode(3)
SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER
Make it possible to retry SSL_write() with changed buffer
location (the buffer contents must stay the same). This is not the
default to avoid
t; next is made right at the moment it knows it can call write().
>
>
> >But sometimes, you might want to change the buffer location for some
> >reason, e.g. since the SSL_write() data buffer is just a window in a
> >larger buffer handled by the application. To tell O
On 6/26/06, Darryl Miles <[EMAIL PROTECTED]> wrote:
Bodo Moeller wrote:
> On Thu, Jun 22, 2006 at 10:41:14PM +0100, Darryl Miles wrote:
>
>> SSL_CTX_set_mode(3)
>>
>> SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER
>> Make it possible to retry SSL_write()
Bodo Moeller wrote:
On Mon, Jun 26, 2006 at 12:35:57PM +0100, Darryl Miles wrote:
Yes. During the first call to SSL_write(), OpenSSL may take as many
bytes as fit into one TLS record, and encrypt this for transport.
Then SSL_write() may fail with WANT_WRITE or WANT_READ both before and
after thi
On Mon, Jun 26, 2006 at 02:04:47PM +0100, Darryl Miles wrote:
> Bodo Moeller wrote:
>> On Mon, Jun 26, 2006 at 12:35:57PM +0100, Darryl Miles wrote:
>> Yes. During the first call to SSL_write(), OpenSSL may take as many
>> bytes as fit into one TLS record, and encrypt this for transport.
>> Then
Kyle Hamilton wrote:
On 6/26/06, Darryl Miles <[EMAIL PROTECTED]> wrote:
I still have not gotten to the bottom of the entire scope of
situation(s) can cause an SSL_write() to return -1 WANT_READ. If its
only renegotiation that can; then this is always instigated by a
SSL_renegotiate() (from my
Bodo Moeller wrote:
On Mon, Jun 26, 2006 at 02:04:47PM +0100, Darryl Miles wrote:
Bodo Moeller wrote:
On Mon, Jun 26, 2006 at 12:35:57PM +0100, Darryl Miles wrote:
Yes. During the first call to SSL_write(), OpenSSL may take as many
bytes as fit into one TLS record, and encrypt this for transpo
Hello,
> >> * TLS header/protocol overhead
> >> * Cipher blocks and chaining modes (picking the most commonly used)
> >> * Blocking mode padding overhead
> >> * Ethernet 1500 MTUs
> >>
> >> I presume the minimum is 1 byte, to be send and flushed at the receiver.
> >>
> >> But maximum block size
Hello,
> For example if you have 8 data bytes to send:
> 8(data) + 20(MAC) + 8(padding) = 36
> and 5 bytes for SSL3/TLS record header = 41.
Sorry, mistake, should be:
For example if you have 12 data bytes to send:
(12(data) + 20(MAC)) + 8(padding) = 40
and 5 bytes for SSL3/TLS reco
On Mon, 26 Jun 2006, Darryl Miles wrote:
Bodo Moeller wrote:
When using SSL_write() over a non-blocking transport channel, you may
have to call SSL_write() multiple times until all your data has been
transferred. In this case, the data buffer needs to stay constant
between calls until SSL_
> There is no need for the data buffer to stay constant between calls to
> SSL_write.
>
> Arne
Did you see my post proving that this must be false? Here's the scenario
again:
1) You try to write 16 bytes on a non-blocking SSL connection.
2) This results in a 24 byte record after encryption.
3)
r layer you are
using), it may take multiple library calls until the library has
looked at all of the bytes. The application won't know which bytes
already have been processed and which haven't, thus generally the
application is expected not to change the buffer. If the application
wants t
routines:SSL3_WRITE_PENDING:bad write retrySep 3 08:52:19 linux01 popper[4409]: Error writing to client
In the forum I read that I have to make a change in ssl.h with the parameter SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER . But I don't know what I have to do exactly. Please help.
Ciao,
HolgerGesendet von
19 matches
Mail list logo
