If your server (that is, the one which accepts the connection) is sensitive to the number and content of the actual packets, the server is in violation of the 'layer' boundary. SSL and TLS can be thought of as another protocol in the AF_INET family, even though it's implemented in user-level code and operates on top of TCP.
The SSL/TLS 'kernel' (even though it's implemented as user-level code) should be invisible to the upper layers (this is why OpenSSL implemented BIO calls, so that the same interface can be used for files, UNIX sockets, TCP sockets, and SSL/TLS-session associated sockets). If it's not, then the implementation that's complaining is in violation of the protocol. It is never an error to send an empty application data packet (unless there's a renegotiation going on). Try disabling the Nagle algorithm on a TCP socket, and then write a bunch of stuff out and watch it in ethereal. Watch an SMTP session. Then try disabling Nagle and sending each character of an SMTP exchange out in its own write() or send() call. Watch how the behavior of the server you're communicating doesn't change regardless of how the packets are sent. As everyone else has stated, SSL/TLS are layered on top of TCP, and present the same guaranteed-byte-order interface to its users. The application protocol gets layered on top of that, with an abstracted byte-ordered connection semantic. Thus, I don't understand why you say that having two packets going out is an error. Nor does anyone else. It's not an error, and is in fact implemented to increase the security of the connection (CBC timing attacks are possible without it). What I want to know is why you're getting so many TCP retransmissions -- that suggests that there's a problem at the network layer and not the SSL or TLS layer. (Note: if you send a single 2600 byte buffer to a standard TCP socket with write() or send(), it will get broken up into multiple packets by the kernel -- yet this is not an error. Why are you stating that it is categorically an error to get two packets out of a single SSL_write(), when it provides the same semantics as the kernel write()?) -Kyle H On 9/27/06, Aarno Syvänen <[EMAIL PROTECTED]> wrote:
Hi, On 27 Sep 2006, at 10:20, David Schwartz wrote: >> > >> Then the problem: when i am doing SSL_write, >> it does return full length of the packet i send, > > You don't send packets to SSL_write, you send bytes. It returns the > number > of bytes sent, and if the other end doesn't receive that number of > bytes > (possibly in multiple call to SSL_read), you have found a problem. Other side would return an error message: ORA-31154: invalid XML document ORA-19202: Error occurred in XML processing LSX-00213: only 0 occurrences of particle "greeting", minimum is 1 It is totally confused, that is: i, as a client would never send greeting. One thing possible is that it got only part of the document. Second thing is two login attempts, which is an error. > >> but >> ethereal shows *two* application level packets. > > It's not completely clear what you mean by "application level > packets". SSL > is a byte-stream protocol. It guarantees only that the other end will > receive the same bytes in the same order. It does not glue bytes > together in > a way the application can use. > > There is no special reason you should care (except perhaps for > performance/efficiency reasons) if you send 100 bytes and SSL sends > them as > a single 100-byte chunk or 100 1-byte chunks tshark dump is following: 72664.019667 130.59.10.95 -> 193.53.0.56 TLSv1 [TCP Retransmission] Server Hello, Certificate, Server Key Exchange, Server Hello Done 72664.035083 193.53.0.56 -> 130.59.10.95 TCP 7700 > 7700 [ACK] Seq=2996013302 Ack=106323215 Win=65535 Len=0 TSV=1368546303 TSER=2583245094 72664.634056 193.53.0.56 -> 130.59.10.95 TLSv1 [TCP Retransmission] Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message 72664.663229 130.59.10.95 -> 193.53.0.56 TLSv1 [TCP Retransmission] Change Cipher Spec 72664.663315 193.53.0.56 -> 130.59.10.95 TCP 7700 > 7700 [ACK] Seq=2996013492 Ack=106323221 Win=65535 Len=0 TSV=1368546305 TSER=2583245740 72664.665924 130.59.10.95 -> 193.53.0.56 TLSv1 [TCP Retransmission] Encrypted Handshake Message 72664.665956 193.53.0.56 -> 130.59.10.95 TCP 7700 > 7700 [ACK] Seq=2996013492 Ack=106323266 Win=65535 Len=0 TSV=1368546305 TSER=2583245742 72664.675862 193.53.0.56 -> 130.59.10.95 TLSv1 [TCP Retransmission] Application Data, Application Data this after one call of SSL_write. As you see, SSL is transmitting two separate application data packets. > . > >> The packet indedd contains 0x00s. Can this be a >> problem ? > > Are you trying to manually decrypt the data? Why do you care what > bytes the > packets contain? You shouldn't be looking at the TCP level except to > diagnose a problem at the SSL level. Do you have a problem? The problem is having two application data packets, when i call SSL_write only once. And yes, i want to decrypt these two packets, to see what they contain. Even if they both are valid packets, this would be an error, as i said. As for 0x00, this one is the cwise end-of-the- string. Some application have separate function call for handling date containing it..
