On Fri, Dec 26, 2014 at 10:12 PM, Thiago Macieira <[email protected]> wrote: > On Friday 26 December 2014 16:55:34 Mikkel Krautz wrote: >> We definitely wouldn't keep supporting TLS 1.0 in that case. >> >> But we would like to still be able to accept connections where the >> handshake ends up using TLS 1.0. Then we can handle the rejection at >> the application protocol level, and show an appropriate message to the >> user and potentially disconnect them immediately. This would be >> handled through an update to the server software. Clients could be >> updated with a similar mechanism, too. >> >> If we do it this way, it allows us to display an appropriate message, >> via the server, even for clients that are not TLS 1.1 or TLS >> 1.2-aware. (Which is pretty much the whole user base.) >> >> However, if there really is no interest in allowing a finer-grained >> protocol selection in Qt itself, I suppose we could live with using >> QSsl::SecureProtocols. That'll at least allow us to add a generic >> error if a modern client attempts to connect to a server that only >> allows TLS 1.0. But older clients would, unfortunately, be stuck with >> a generic handshake error. >> >> But in my opinion, that would not be ideal for our users. > > 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. > > That means old clients will use newer and more secure protocol versions as > soon as OpenSSL and Qt are upgraded, with no change to the application.
I really like this approach. I've taken a stab at implementing this for Mumble's Qt 5 tree - and it works great. (I'll open a code review soon, for further discussion) However, while doing that I stumbled upon the qsslsocket_winrt.cpp file, and by extension I spotted the way WinRT implements this leveled approach: http://msdn.microsoft.com/en-US/library/windows/apps/windows.networking.sockets.socketprotectionlevel.aspx Setting TLS 1.2 gives you TLS 1.2 and below (no SSL 3) And so on... However, your suggested approach of having QSsl::Tlsv1_0 mean "TLS 1.0 or greater" is obviously still achievable if we limit ourselves to only doing it for QSsl::TlsV1_0, QSsl::TlsV1_1 and QSsl::TlsV1_2. (On WinRT, all of these would simply be set to "Tls12".). But I think that's fine. > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
