I've opened a code review for adding TlsV1_0OrLater and friends at:
https://codereview.qt-project.org/#/c/106080/
We obviously haven't reached agreement on the actual API for this, but
as I said, we're pretty happy with the 'OrLater' variant, which the
patchset implements. Hopefully, the patchse
On Sun, Dec 28, 2014 at 2:26 PM, Thiago Macieira
wrote:
> On Sunday 28 December 2014 13:11:13 Richard Moore wrote:
>> At the moment there are still a lot of SSL accelerators out there with
>> these problems. We can probably stop worrying in around a year once all the
>> browsers have got around to
On Monday 29 December 2014 15:30:29 Richard Moore wrote:
> > Alternatively, we can add a
> >
> > /// if major == 0, sets to "Secure Protocols"
> > void setMinimumTlsVersion(int major, int minor);
> > int sessionTlsMajorVersion() const;
> > int sessionTlsMinorVersion(
On 28 December 2014 at 13:26, Thiago Macieira
wrote:
> On Sunday 28 December 2014 13:11:13 Richard Moore wrote:
> > At the moment there are still a lot of SSL accelerators out there with
> > these problems. We can probably stop worrying in around a year once all
> the
> > browsers have got around
On Sunday 28 December 2014 13:11:13 Richard Moore wrote:
> At the moment there are still a lot of SSL accelerators out there with
> these problems. We can probably stop worrying in around a year once all the
> browsers have got around to disabling SSL3 and thereby forcing things to be
> fixed. Curr
On 27 December 2014 at 12:48, Thiago Macieira
wrote:
> On Saturday 27 December 2014 10:52:41 Richard Moore 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. Per
On Saturday 27 December 2014 10:52:41 Richard Moore 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. Perhaps what we want is a minimum and maximum version
> (though th
On 27 December 2014 at 11:44, Mikkel Krautz wrote:
> On Sat, Dec 27, 2014 at 11:52 AM, Richard Moore wrote:
> > On 26 December 2014 at 21:12, Thiago Macieira >
> > 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 serve
On Sat, Dec 27, 2014 at 11:52 AM, Richard Moore wrote:
>
>
> On 26 December 2014 at 21:12, Thiago Macieira
> 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
On 26 December 2014 at 21:12, Thiago Macieira
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 to
On Fri, Dec 26, 2014 at 10:12 PM, Thiago Macieira
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 c
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, an
On Fri, Dec 26, 2014 at 2:47 PM, Thiago Macieira
wrote:
>
> On Friday 26 December 2014 13:12:47 Mikkel Krautz wrote:
> > too!). So, the current QSsl::SecureProtocols in Qt 5.4 is fine for our use.
> > But since QSsl::SecureProtocols is a moving target, we're afraid that if we
> > commit to using i
On Friday 26 December 2014 13:12:47 Mikkel Krautz wrote:
> too!). So, the current QSsl::SecureProtocols in Qt 5.4 is fine for our use.
> But since QSsl::SecureProtocols is a moving target, we're afraid that if we
> commit to using it, a future Qt 5.x version may remove TLS 1.0 support. That
> would
Hi,
For Mumble (http://mumble.info), we'd like the ability to select the
allowed protocols for a QSslSocket in more fine-grained manner.
Very old versions of Mumble, version 1.x, used SSLv3, where as newer
versions,
1.2 and above, use TLSv1.0. We'd like to upgrade to TLSv1.2, and we also
need
bac
15 matches
Mail list logo
