On 27 December 2014 at 11:44, Mikkel Krautz <[email protected]> wrote:
> On Sat, Dec 27, 2014 at 11:52 AM, Richard Moore <[email protected]> wrote: > > On 26 December 2014 at 21:12, Thiago Macieira <[email protected] > > > > 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.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
