Re: Strange problem with SSL_write
On 27 Sep 2006, at 22:28, David Schwartz wrote: 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 quot;greetingquot;, 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. How is the client supposed to know where the document ends? EPP PDU starts with four bytes telling the length of the document this after one call of SSL_write. As you see, SSL is transmitting two separate application data packets. Who cares whether it sends one or a thousand? It's none of the application's business how SSL sends the data so long as it all gets to the other end in the right order. If EPP server get two login attempts during very short period, it can reject the request. Thousand login attempts would definitely be a denial of service attack, by everybody's count. The problem is having two application data packets, when i call SSL_write only once. Why do you care how many application data packets SSL uses to send the data from one end to the other? That's a protocol detail the application should not care about. Most of protocols do care about DoS. And, say, doing a database update unknown number of times is not good idea either. 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. How would that be an error? As I said before, the relevant rfc has quite strong wording about DoS attacks. EPP would be used, for instance, provisioning ENUM DNS records, which explains the sensitivity. As for 0x00, this one is the cwise end-of-the- string. Some application have separate function call for handling date containing it.. Why do you care what bytes are in the encrypted data? You're not handling that data, OpenSSL is. You see to be very confused about how layering works in an SSL application and what interface SSL provides to the application. SSL, like TCP, is a byte-stream protocol that does not preserve message boundaries. This was just because some applications have different ways to handle octet sequence containing 0x00, which is c's end-of-the-string. I use SSL_write to send exactly one packet to the SSL socket, so expectation of of one ssl application layer packet is reasonable. Aarno __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Strange problem with SSL_write
On 27 Sep 2006, at 22:54, Kyle Hamilton wrote: 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. Receiving SSL socket is not sensitive to number and content of application layer packets, of course. Application sitting on the top of SSL is. Too many login packets would be denial of service attack, or something worse. 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). Actually EPP server is sitting on the top OpenSSL. I did not know that OpenSSL is sending (and removing) an empty packet. So I have disabled it, and will restore it, when EPP accepts the login 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. I disabled the empty packets, and now i see only one application layer packet 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). Yes, having two packets is not an error, if receiving socket removes the empty one. I was afraid (i did not decrypt) that there was two actual application layer packets. I did know about CBC timing attack, thanks to you guys explaining it to me. 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. I disabled tcp checksum checking for tshark. Otherwise, there would be endless complains about checksum errors. (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()?) As I said, I was afraid that there were two actual application layer packets (two logins), which would be regarded, at best, as a DoS attack by the application layer server. Aarno 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 quot;greetingquot;, 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,
Strange problem with SSL_write
Hi List, I am implementing EPP over SSL. It requires me send send hex data (the length of the xml document). In addition, making EPP request twice is an error. So it differs http with both these counts. Then the problem: when i am doing SSL_write, it does return full length of the packet i send, but ethereal shows *two* application level packets. The packet indedd contains 0x00s. Can this be a problem ? Aarno __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Strange problem with SSL_write
Aarno Syvänen wrote: Hi List, I am implementing EPP over SSL. It requires me send send hex data (the length of the xml document). In addition, making EPP request twice is an error. So it differs http with both these counts. Then the problem: when i am doing SSL_write, it does return full length of the packet i send, but ethereal shows *two* application level packets. The packet indedd contains 0x00s. Can this be a problem ? I'm afraid I do not really understand your request. Are you experiencing any problems, that is the server does not receive the data as the client sends them? Or are you afraid of a potential security or performance problem? The number of packets sent on the wire while using SSL protocol is only loosely related to the number of SSL_write calls you are making or even the number of bytes you are sending, especially if sending only some bytes at a time... Hope this helps. Ted ;) -- PGP Public Key Information Download complete Key from http://www.convey.de/ted/tedkey_convey.asc Key fingerprint = 31B0 E029 BCF9 6605 DAC1 B2E1 0CC8 70F4 7AFB 8D26 smime.p7s Description: S/MIME Cryptographic Signature
RE: Strange problem with SSL_write
Hi List, I am implementing EPP over SSL. It requires me send send hex data (the length of the xml document). In addition, making EPP request twice is an error. So it differs http with both these counts. Okay. 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. 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. 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? DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Strange problem with SSL_write
Hello, Then the problem: when i am doing SSL_write, it does return full length of the packet i send, but ethereal shows *two* application level packets. The packet indedd contains 0x00s. Can this be a problem ? No, sending first empty SSL packet and next real (with data) is CBC timing attack workaround. Try setting SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS with SSL_CTX_set_options() to check if this behavior will change. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Strange problem with SSL_write
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 quot;greetingquot;, 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.. Aarno __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Strange problem with SSL_write
- Original Message From: Aarno Syvänen [EMAIL PROTECTED] To: openssl-users@openssl.org Sent: Wednesday, September 27, 2006 11:27:41 AM Subject: Re: Strange problem with SSL_write but ethereal shows *two* application level packets. To inspect ssl protocol sessions I suggest ssldump http://www.rtfm.com/ssldump/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Strange problem with SSL_write
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 quot;greetingquot;, 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. How is the client supposed to know where the document ends? this after one call of SSL_write. As you see, SSL is transmitting two separate application data packets. Who cares whether it sends one or a thousand? It's none of the application's business how SSL sends the data so long as it all gets to the other end in the right order. The problem is having two application data packets, when i call SSL_write only once. Why do you care how many application data packets SSL uses to send the data from one end to the other? That's a protocol detail the application should not care about. 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. How would that be an error? As for 0x00, this one is the cwise end-of-the- string. Some application have separate function call for handling date containing it.. Why do you care what bytes are in the encrypted data? You're not handling that data, OpenSSL is. You see to be very confused about how layering works in an SSL application and what interface SSL provides to the application. SSL, like TCP, is a byte-stream protocol that does not preserve message boundaries. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Strange problem with SSL_write
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 quot;greetingquot;, 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
