The coalescing of multiple messages to TCP packets is implicitly allowed by RFC. TLS defines its own record protocol, which must be used atop a reliable, connection-oriented channel such as that provided by TCP, and that channel is allowed to do whatever it wants to optimize its behavior (and SSL/TLS are never defined in any way to touch the operation of the underlying channel).
The underlying channel can break each byte into its own packet, and TLS is not allowed to care. The underlying channel can coalesce sixty megs into a single packet if it wants to, and TLS is not allowed to care. If you are noticing a behavior change in the circumstance where everything message is sent independently versus sent coalesced, that is a bug in the implementation that OpenSSL is talking with, NOT with OpenSSL itself. (Unfortunately, given OpenSSL's history of providing bug workarounds for interoperability with broken implementations, it's undoubtedly going to be worked around Yet Again[tm]. I wish Microsoft would fix its implementation problems, rather than everyone else having to work around them.) -Kyle H On 3/6/07, Christian Marg via RT <[EMAIL PROTECTED]> wrote:
Hello, this is the Digest of a conversation concerning the Bug report filed as #1455 held with Christophe Devine: Christophe Devine wrote: > Christian Marg wrote: >> Christophe Devine wrote: >>> Christian Marg wrote: >>>> Christophe Devine wrote: >>>>> Christian Marg wrote: >>>>>> I now have a console log of "ssldump host >>>>>> windowsserver.fqdn", see below. I hope that this log is useful. >>>>>> >>>>>> See the log on >>>>>> http://home.tu-clausthal.de/~ifcma/ssltest/with-pause.ssldump.txt >>>>>> and >>>>>> http://home.tu-clausthal.de/~ifcma/ssltest/without-pause.ssldump.txt >>>>>> >>>>> Looking at the logs, it appears the server drops the connection >>>>> after the client has sent his Finished message -- decryption >>>>> failed, probably. It may be helpful if you could provide a tcpdump >>>>> trace in both cases (with and without -pause). [Please add "-s 0" >>>>> to the TCP dump commandline] >>>>> >>>> Ok, here you are: >>>> http://home.tu-clausthal.de/~ifcma/ssltest/with-pause.tcpdump.raw >>>> http://home.tu-clausthal.de/~ifcma/ssltest/without-pause.tcpdump.raw >>> >>> [...] >>> >>> After having a look at the files, it appears there was only one minor >>> difference in both of the traces: in the first case (without pause), >>> several handshake messages are coalesced into a single TCP packet >>> whereas in the second case the client certificate message is sent in a >>> single TCP packet. This is according to the standard, so it's more >>> likely to be a problem with the server itself, not openssl. >> >> Is that merging of Messages to TCP Packets mentioned explicitly allowed >> in the standard? I'm asking because I tested and found working not only >> Mozilla SSL but Gnutls too. So maybe Openssl should just do it like all >> the others? >> >>> [Could you please try out programs/ssl_client2.c from >>> http://xyssl.org/code/download/xyssl-0.5.tgz] >> >> Yes: >> ========================================================= >> FreeBSD# ./ssl_client2 >> >> . Loading the CA root certificate ... ok >> . Loading the client cert. and key... ok >> . Connecting to tcp/windowsserver.fqdn/636 ... ok >> . Setting up the RNG and SSL state... ok >> . Performing the SSL/TLS handshake... ok >> [ Cipher is SSL3_RSA_RC4_128_MD5 ] >> . Verifying peer X.509 certificate... failed >> ! self-signed or not signed by a trusted CA >> >> > Write to server: >> >> < Read from server: >> ========================================================= >> Seems like it works ok... > > So it works with GnuTLS, NSS and XySSL, but not OpenSSL. Well to be frank I'm > a bit lost why this error is showing up. You probably need help from an > OpenSSL developper with more experience than me, I'm afraid.
______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
