Further clarification - I don't think you have to send ALL the data requested, you just have to send full chunks. If you call Encrypt(), asking it to encrypt 32k bytes, but it only encrypts the first 4k, you need to fully send that 4k.
Mark -----Original Message----- From: Salisbury, Mark Sent: Monday, April 23, 2012 2:26 PM To: libcurl development Subject: RE: SSL/TLS support using Windows SSPI Schannel API I think I didn't explain my concern very well - let me try again with fewer words :) If you are asked to send 100 bytes, which is translated into 125 encrypted bytes, but only 30 bytes (encrypted) are actually sent, how do you know how many unencrypted bytes were sent? (how do you know what to return to the caller for bytes written?) I don’t think the caller cares how many encrypted bytes were sent. If you tell the caller 30 bytes were sent, it will call you back at an offset 30 bytes into its buffer. Mark -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Marc Hoersken Sent: Monday, April 23, 2012 2:18 PM To: libcurl development Subject: Re: SSL/TLS support using Windows SSPI Schannel API 2012/4/23 Salisbury, Mark <[email protected]>: > Thinking about this a little bit more, I wonder if the SSL write function > really needs to write ALL the bytes the client passes in before it returns. > Here's why. Suppose the client passes in 100 bytes of data to write (a small > HTTP GET request). When we use SSL, we may encrypt that 100 bytes into a > different number of bytes; it depends on the encryption algorithm that was > negotiated (without extra work we're not going to even know which one was > used). Suppose the plain bytes are converted into 125 bytes. If we write > only the first 30 bytes, and we return that to the client, they will call the > write function again and start us off at position 30. Since the previous > message was not written fully, it probably wasn't coherent to the receiver > when it was decrypted. Writing 30 bytes (of encrypted data) may not mean > that 30 bytes of the unencrypted data was decrypted by the client. > > What do you guys think? Do you agree? When ssl write methods are passed a > buffer to write do they need to write it all or return an error if they are > unable to, respecting configured timeouts? > > Any encryption experts want to weigh in? I am not an encryption expert, but as the Schannel decryption routines themselves are perfectly fine with handling incomplete encrypted data by asking for more data, I think it should be find to write partial data to the socket. This is the only way to handle big data transfer over a slow connection by buffering inside the client. Remember: packets my be split up anyway, so you can never be sure that a packet completely arrives at the target endpoint in the same timeframe and can be read at once. TCP connections are not message oriented, but stream oriented and this means that the receiving endpoint should never care about the original send size and just figure out how much more data is required. Best regards, Marc ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
