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() behaves like
non-blocking write().
$ grep SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER *
s2_pkt.c: !(s->mode & SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER)))
s3_pkt.c: !(s->mode &
SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER))
ssl.h:#define SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER 0x00000002L
--------- s3_pkt.c -----------
/* if s->s3->wbuf.left != 0, we need to call this */
int ssl3_write_pending(SSL *s, int type, const unsigned char *buf,
unsigned int len)
{
int i;
/* XXXX */
if ((s->s3->wpend_tot > (int)len)
|| ((s->s3->wpend_buf != buf) &&
!(s->mode & SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER))
|| (s->s3->wpend_type != type))
{
SSLerr(SSL_F_SSL3_WRITE_PENDING,SSL_R_BAD_WRITE_RETRY);
return(-1);
}
---------------------------------
This seems to be some sanity check for its own sake. i.e. if I use:
SSL_set_mode(ssl, SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER);
this sanity check can never return an error. There appears to be no
other impact on the code other than disabling this check. Duh ?
There must be some history behind this feature. Can I safely ignore the
notion of worrying about the exact buffer location is reuse for the next
SSL_write() ?
When looking at the impact on SSL_MODE_ENABLE_PARTIAL_WRITE (another
confusing option) I see a vague security/efficiency warning in the comment:
---------- s3_pkt.c -----------------
if ((i == (int)n) ||
(type == SSL3_RT_APPLICATION_DATA &&
(s->mode & SSL_MODE_ENABLE_PARTIAL_WRITE)))
{
/* next chunk of data should get another
prepended empty fragment
* in ciphersuites with known-IV weakness: */
s->s3->empty_fragment_done = 0;
return tot+i;
}
------------------------------------
When might someone want to use SSL_MODE_ENABLE_PARTIAL_WRITE ? What are
its implications, does it cause an extra few bytes to be emitted in the
TLS protocol for the "prepended empty fragment" ? So if I want
efficiency I am better not using it ?
My application is 100% happy to represent the data to SSL_write(). If
SSL_write() returns -1 WANT_WRITE, it will represent all the data again
next time, if SSL_Write() return 42 (out of 4096 I presented) my next
call will have cut off the first 42 bytes and present the next 4096
bytes. Since I copy to stack buffer to give to SSL_write().
Now that copy to stack buffer might change the memory offset I am using
for the next write (getting back to understanding the
SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER option, as byte 42 is not at
position &buffer[0] not &buffer[42]);
Would general advise be not to use this feature ?
I presume the TLS protocol paketizes the data, how does the SSL_write()
length affect that packetization, and what would sort of ranges would be
an optimal length ?
Is it due to that packetization the SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER
was thought about at sometime in the past ?
How does this affect my future writes after SSL_write -1 WANT_WRITE ?
Would it be true that the receive end of the SSL stream would be able to
pull off chunks of data which have boundaries set by the sending ends
SSL_write() lengths ?
This would be to ensure correct flushing of data occurred at the receive
side ?
What sized writes result in the least amount of block padding ?
Sorry so many questions. Trying to lift the mist.
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
