SSL compatibility mode

[Tomasz Wasilczyk]

I have just double-checked it, and it seems, that this problem is only
related to gnutls. Mozilla NSS seems not to be that picky and just
returns EOF in that case.

Anyway, I'm convinced, that we shouldn't just ignore that error when
using gnutls, so suggested configuration for ssl is still appropriate,
even if it doesn't do anything with NSS (because it seems to be
already in "compatibility mode").

Should I change anything in proposed patch [1]?

Tomek

[1] http://pastebin.com/qFYTSWS5

2012/10/16 Tomasz Wasilczyk <tomkiewicz.groups at gmail.com>:
> I didn't checked it yet, but I'm almost sure it's also related to NSS.
>
> This error should be mapped to EOF for protocols like HTTP (just like I did
> it in the patch).
>
> 15-10-2012 23:18, "Eion Robb" <eion at robbmob.com> napisał(a):
>
>> Is that just a GnuTLS'ism or is there an equivalent thing happening with
>> NSS?
>> Should GNUTLS_E_PREMATURE_TERMINATION be mapped to EOF for protocols to
>> handle?
>>
>> On 16 October 2012 09:40, Tomasz Wasilczyk <tomkiewicz.groups at gmail.com>
>> wrote:
>> > It would be OK, if this code was used only with HTTP. But for some
>> > (most) protocols with TLS support it's not correct behavior. Ignoring
>> > GNUTLS_E_PREMATURE_TERMINATION may lead to serious problems, if
>> > protocol relies on EOF.
>> >
>> > 2012/10/15 Eion Robb <eion at robbmob.com>:
>> >> Wouldn't it be simpler to check for both EOF and
>> >> GNUTLS_E_PREMATURE_TERMINATION rather than adding compatibility flags?
>> >>
>> >> On Oct 16, 2012 9:19 AM, "Tomasz Wasilczyk"
>> >> <tomkiewicz.groups at gmail.com>
>> >> wrote:
>> >>>
>> >>> I have this problem when connection: close is set. With proper
>> >>> (server) implementation, gnutls_record_recv should return 0 on EOF.
>> >>> With google, it doesn't.
>> >>>
>> >>> According to [1], not all TLS implementations terminates properly TLS
>> >>> connections. Some of them, for performance reasons, closes underlying
>> >>> TCP connection.
>> >>>
>> >>> Is there a need for TCP capture for proof? HTTP request for
>> >>> https://www.google.pl (in other countries, it may be redirected
>> >>> somewhere else) returns proper response - the only issue is getting
>> >>> GNUTLS_E_PREMATURE_TERMINATION instead of EOF.
>> >>>
>> >>> Current purple's HTTP implementation have the same issue.
>> >>>
>> >>> [1]
>> >>>
>> >>> https://www.gnu.org/software/gnutls/manual/gnutls.html#index-gnutls_005fbye
>> >>>
>> >>> 2012/10/15 Eion Robb <eion at robbmob.com>:
>> >>> > You say "For example, google doesn't close its connections
>> >>> > gracefully".  What do you mean by that?  Do you have a capture of
>> >>> > sent/received HTTP request/responses?  Is that when sending the
>> >>> > 'Conneciton: close' header, or if it's left out?
>> >>> >
>> >>> > Cheers,
>> >>> > Eion
>> >>> >
>> >>> > On 16 October 2012 08:13, Tomasz Wasilczyk
>> >>> > <tomkiewicz.groups at gmail.com>
>> >>> > wrote:
>> >>> >> Hi,
>> >>> >>
>> >>> >> I wish, you are not so tired with all my suggestions ;).
>> >>> >>
>> >>> >> I was implementing new HTTP support and I came into a problem: some
>> >>> >> servers are not 100% compatible with TLS standard. For example,
>> >>> >> google
>> >>> >> doesn't close its connections gracefully. In such cases, it would
>> >>> >> be
>> >>> >> good to provide "compatibility mode".
>> >>> >>
>> >>> >> I have implemented it [1], but I have one problem: compatibility
>> >>> >> mode
>> >>> >> can be set after getting PurpleSslConnection pointer. It's OK for
>> >>> >> purple_ssl_connect, because after exitting from it, no SSL
>> >>> >> operations
>> >>> >> are performed yet (standard TCP connection is made first, so we
>> >>> >> have
>> >>> >> to wait for connection). But within
>> >>> >> purple_ssl_connect_with_host_fd,
>> >>> >> connectfunc is called before exitting it, so we are not able to set
>> >>> >> compatibility level just after initializing TLS session. I have
>> >>> >> some
>> >>> >> ideas:
>> >>> >>
>> >>> >> - we may not implement support for
>> >>> >> gnutls_session_enable_compatibility_mode (see [1]), leaving just
>> >>> >> PURPLE_SSL_COMPATIBILITY_SECURE mode (and fixing google issue)
>> >>> >>
>> >>> >> - we may ignore purple_ssl_connect_with_host_fd in that case (bad
>> >>> >> idea,
>> >>> >> I think)
>> >>> >>
>> >>> >> - we may call connectfunc from purple_ssl_connect_with_host_fd in
>> >>> >> *next* main loop iteration, with purple_timeout_add(0, ...),
>> >>> >> allowing
>> >>> >> to set compatibility mode before calling connectfunc (I like this
>> >>> >> the
>> >>> >> most)
>> >>> >>
>> >>> >> Please, look though my patch and post any suggestions.
>> >>> >>
>> >>> >> By the way: new HTTP implementation base functionality is now
>> >>> >> almost
>> >>> >> ready.
>> >>> >>
>> >>> >> Waiting for comments,
>> >>> >> Tomek
>> >>> >>
>> >>> >> [1] http://pastebin.com/qFYTSWS5
>> >>> >>
>> >>> >> _______________________________________________
>> >>> >> Devel mailing list
>> >>> >> Devel at pidgin.im
>> >>> >> http://pidgin.im/cgi-bin/mailman/listinfo/devel