[Development] QSsl: finer-grained protocol selection

[Richard Moore]

On 27 December 2014 at 11:44, Mikkel Krautz <mikkel at krautz.dk> wrote:

> 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:
> >
> > 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?
>
>
It's not broken, but yes it could fail to connect. If an app needs to
support such broken servers it can then specify the older version using the
TLSv1_0 constant. That's why changing the meaning of the constant would be
a problem.



> 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).
>
>
I actually think it probably makes more sense to either allow you to
specifically set the versions, or to have an API for the min and max
versions you want. If I was coding this from a clean slate I suspect I'd
make the protocol version a Q_FLAGS so you can just turn on and off the
ones you want. It might be possible to do this actually and make the
current API still work.


> 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).
>
>
The buggy implementations are mainly SSL accelerators so I suspect you
won't have a problem.


> > 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.
>
>
Yeah, there are a number of differences in behaviour in the winrt (and
securetransport) backends. These are mainly due to missing features in
their APIs and I suspect will remain unavoidable. It shouldn't prevent us
providing the API we want, though obviously where possible I'd like to keep
things compatible.

Cheers

Rich.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20141227/464beae6/attachment.html>