Thanks for the report. Unfortunately, servers are known to close connections or do strange things when they get unsupported extensions.
For reference, could you try with '--comp DEFLATE'? GnuTLS supports a non-standard compression mechanism LZO. However, the DEFLATE mechanism is standardized. /Simon "kyle cronan" <[EMAIL PROTECTED]> writes: > It works with --comp NULL. I hadn't tried that one by itself, since I > didn't think the server would punish me just for offering. Hopefully > someone will find this helpful some day! > > Kyle > > On 2/21/07, kyle cronan <[EMAIL PROTECTED]> wrote: >> Hello, >> >> My question is about how to debug the situation where the TLS server >> closes the connection right after the client hello message is sent >> (gnutls 1.4.5). I didn't have much luck searching the list archives >> for hello! >> >> Looking at what's in an SSL/TLS hello, perhaps cipher_suites, >> compression_methods and client_version are candidates for causing >> trouble? I believe I tried all the different client versions using >> --protocols, and I see from gnutls_handshake.c that the extensions are >> only sent if we're using a TLS version, not SSL3. So it shouldn't be >> a protocol extension that's causing the problem either. That just >> leaves ciphers and compression methods. But wouldn't I get an error >> like "could not negotiate a supported cipher suite"? Have servers >> been known to just close the connection without giving a handshake >> failure? >> >> Unfortunately the server software is some unknown black box type >> stuff. It does work with openssl s_client though (0.9.7a), even when >> I select various single ciphers with the -cipher option. >> >> Thanks, >> Kyle Cronan >> <[EMAIL PROTECTED]> >> _______________________________________________ Help-gnutls mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnutls
