[Development] QSsl: finer-grained protocol selection

Mikkel Krautz mikkel at krautz.dk
Sat Dec 27 12:44:07 CET 2014


On Sat, Dec 27, 2014 at 11:52 AM, Richard Moore <rich at kde.org> wrote:
>
>
> On 26 December 2014 at 21:12, Thiago Macieira <thiago.macieira at intel.com>
> wrote:
>>
>>
>> I don't think we need fine-grained detection, but we do need something
>> better
>> than what we have right now.
>>
>> My suggestion is to set a level. For example, if you set to TlsV10, then
>> you
>> get TLS v1.0 and anything newer, existing today or not, and disable
>> anything
>> older. The client will negotiate the highest version at connection time.
>> The
>> only reason to disable newer versions is when the server is buggy, but the
>> application should not have to care about that. That's OpenSSL's job.
>>
>
> Hmm, if you set TLS 1.0 you really need to only negotiate TLS 1.0. If not
> then if you're connecting to old servers the TLS extensions will lead the
> connection to hang.

Hi Rich,

Thanks for the clarification.

I assume this means that QSsl::SecureProtocols (the default) is also broken
when connecting to buggy servers? Or does Qt's HTTP logic do TLS-specific
retries if something fails?

How about a QSsl::SslOption for triggering the behavior Thiago suggested?
(Making it opt-in would also avoid a change in behavior for existing programs
using TlsV1_0 an friends).

Our use case in Mumble is a little special, since our main use of TLS isn't
HTTP-related, so hopefully the amount of buggy TLS implementations is
limited. I believe we "only" have implementations using OpenSSL,
PolarSSL and Go's crypto/tls in the wild, and I haven't seen problems with
Thiago's approach yet (but I'll admit that I haven't extensively tested it yet).

> Perhaps what we want is a minimum and maximum version
> (though this doesn't map very well to the underlying openssl API).

Well at least it seems to fit OpenSSL's API better than it fits the API that the
WinRT backend is using. I'm guessing that's a problem?

If an explicit QSsl::SslOption is required to trigger the behavior, the docs
for the option could at least explain that it might not work with all backends.

> Cheers
>
> Rich.
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>



More information about the Development mailing list