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 "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..
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿó©zt’,úèç-
†ÛiÿÿðÃè¥éì²_è®,z´®¦š+´Æ¢–)à.+-¢—
§²ÉÿºÇ«³ú)z{,—ú+€ ¢fyÒâ²Ó¨ ®f£¢
·hšè¥éì²_è
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
