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 =20=

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 =20
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 =20
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=C3=83=C2=A4nen 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 =20=


>> 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=3D2996013302 Ack=3D106323215 Win=3D65535 Len=3D0 TSV=3D1368546303
>> TSER=3D2583245094
>> 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=3D2996013492 Ack=3D106323221 Win=3D65535 Len=3D0 TSV=3D1368546305
>> TSER=3D2583245740
>> 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=3D2996013492 Ack=3D106323266 Win=3D65535 Len=3D0 TSV=3D1368546305
>> TSER=3D2583245742
>> 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 =20

>> 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-=20
>> the-
>> string. Some application have separate
>> function call for handling date containing it..

> =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C 3=BF=C3=BF=C3=BF=C3=BF=

=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C 3=BF=C3=BF=C3=BF=C3=BF=C3=
=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=B F=C3=BF=C3=BF=20
> =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C 3=BF=C3=BF=C3=BF=C3=BF=

=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=B3=C2=A9zt=E2=80 =99,=C3=BA=C3=A8=C2=8D=C3=
=A7-=20
> =E2=80=A0=C3=9Bi=C3=BF=C3=BF=C3=B0=C3=83=0F=C3=A8= C2=A5=C3=A9=C3=AC=C2=B2=

_=C3=A8=C2=AE=05,z=C2=B4=C2=AE=C2=A6=C5=A1+=C2=B4= C3=86=C2=A2=E2=80=93)=C3=
=A0.+-=C2=A2=E2=80=94=20
> =C2=A7=C2=B2=C3=89=C3=BF=C2=BA=C3=87=C2=AB=C2=B3=C 3=BA)z{,=E2=80=94=C3=BA=

+=E2=82=AC=0B =C2=A2f=C2=ADy=C3=92=C3=A2=C2=B2=C3=93=1A=C2=9D=C2 =A8=1E=C2=AE=
f=C2=A3=C2=A2=20
> =C2=B7h=C5=A1=C2=8F=C3=A8=C2=A5=C3=A9=C3=AC=C2=B2_ =C3=A8


__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majordomo@openssl.org