We were being inconsistent in how we handled this, some tests skipping
while others using QVERIFY. It makes more sense to skip the tests, since
the problem is a missing pre-condition of the test, not the test itself
being bad or exposing real failures in the implementation.
Change-Id: I20eacfe12dbce0b0d926e48cbe2d2772819fa4a5
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
To disambiguate &QSslSocket::sslErrors() expression. Add a new
getter - sslHandshakeErrors().
[ChangeLog][Deprecation Notice] QSslSocket::sslErrors() (the getter) was deprecated and superseded by sslHandshakeErrors()
Task-number: QTBUG-80369
Change-Id: I9dcca3c8499800c122db230753dc19b07654f8a2
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The one that is a getter for the last error found. This is to disambiguate
the expression '&QAbstractSocket::error'. Introduce a new member-function
socketError as a replacement.
[ChangeLog][Deprecation Notice] QAbstractSocket::error() (the getter) is deprecated; superseded by socketError().
Task-number: QTBUG-80369
Change-Id: Ia2e3d108657aaa7929ab0810babe2ede309740ba
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
OpenSSL 1.0.2 will stop receiving all support at the end
of 2019. Qt 5.15 is our next LTS thus makes sense remove
OpenSSL 1.0.2 support there. This also allows us quite
a significant cleanup of an old heavily if-defed code
and all 'pre11' suffixed source files.
[ChangeLog][QtNetwork][SSL] Removed OpenSSL 1.0.x support, now 1.1.x is required
Change-Id: I70c70c56cbd8aeff793afe793335696d1b1b7408
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
And add a test for it so it can no longer happen in any current or
future implementation.
Change-Id: I3214aa90595e291b1e1c66befe185cfe1ea7bc6b
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Following the deprecation of add[Default]CaCertificate[s] let's update
the uses of it. While we're doing this, let's also use QSslConfiguration
more in some places where it makes sense.
Change-Id: I2c9e7c73fee8a405492410378f2babe67d3a3f25
Reviewed-by: Jesus Fernandez <jsfdez@gmail.com>
This patch was generated with tooling from patchset 31 of
https://codereview.qt-project.org/c/qt/qtqa/+/267034 in interactive
mode. General platform names were chosen if greater than 60% of the
currently active platforms of a given type in COIN recently failed.
Change-Id: Ia4bde7f0ec422bbb727dc9d7151295159094f146
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Deprecated APIs of network lib are used only in tests. This change
makes sure, that the tests build and pass with those deprecated APIs
removed or disabled, by:
- Making the parts of the tests testing the deprecated APIs to be
compiled conditionally, only when the corresponding methods are
enabled.
- If the test-case tests only the deprecated API, but not the
corresponding replacement, added tests for the replacement.
Task-number: QTBUG-76541
Change-Id: I78c4913155007fd1d0df2c38e1b9a8b80066adeb
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Conflicts:
configure.pri
Also required s/solid\.color/solidColor/ in a couple of places in:
src/gui/painting/qpaintengine_raster.cpp
Change-Id: I29937f63e9779deb6dac7ae77e2948d06ebc0319
These tests have not failed on the removed platforms for at least 60 days
Task-number: QTBUG-76608
Change-Id: If7a9f4db907124e3cd54e3f4b0ad3e20717d1912
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This reverts commit 9a25d27b9d58316dee5d2305135d2d74ad5d51e7.
The QSKIP is no longer needed as the imap server's certificate
was updated
Task-number: QTBUG-76610
Change-Id: I1007ce50d6f7f6258fdeb8894c66678a660b03ca
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
In this threaded setup the server can sometimes have the data before it
calls "waitForReadyRead", what happens then is that we fail the wait and
as a result the test fails overall.
Let's check if we actually got some data after all and then continue if
we did. Since both the client and the server currently wait the same
amount of time (2s) the max timeout for the client was increased by
0.5s so it has some time to notice that the server got the message.
Change-Id: Ib5915958853413047aa5a7574712585bcae28f79
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
(cherry picked from commit e79b1dcdf5)
Reviewed-by: Simo Fält <simo.falt@qt.io>
(cherry picked from commit d53b8b77bc)
Change-Id: I2f6ffb8e0a9b4d591edb6925e48baffcefc14511
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
If this callback is not set then OpenSSL will call the callback
used for <= TLS 1.2 unconditionally when connecting. If using PSK it
will call it again later once the preshared key is needed.
We don't currently handle the TLSv1.3 PSK, but we definitely should.
But for now we can work around it - when psk_use_session_callback is
called we simply change the PSK callback to a dummy function whose only
purpose is to restore the old callback.
This is mostly done to keep behavior the same as it is now for users
(and to keep our tests running).
Later we can add a new signal and handle this new feature properly.
Reviewed-by: Simo Fält <simo.falt@qt.io>
(cherry picked from commit d8efc8d718)
Task-number: QTBUG-67463
Change-Id: I4aca4ae73ec4be7c4f82a85e8864de103f35a834
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
If this callback is not set then OpenSSL will call the callback
used for <= TLS 1.2 unconditionally when connecting. If using PSK it
will call it again later once the preshared key is needed.
We don't currently handle the TLSv1.3 PSK, but we definitely should.
But for now we can work around it - when psk_use_session_callback is
called we simply change the PSK callback to a dummy function whose only
purpose is to restore the old callback.
This is mostly done to keep behavior the same as it is now for users
(and to keep our tests running).
Later we can add a new signal and handle this new feature properly.
Task-number: QTBUG-67463
Change-Id: I4aca4ae73ec4be7c4f82a85e8864de103f35a834
Reviewed-by: Simo Fält <simo.falt@qt.io>
In this threaded setup the server can sometimes have the data before it
calls "waitForReadyRead", what happens then is that we fail the wait and
as a result the test fails overall.
Let's check if we actually got some data after all and then continue if
we did. Since both the client and the server currently wait the same
amount of time (2s) the max timeout for the client was increased by
0.5s so it has some time to notice that the server got the message.
Change-Id: Ib5915958853413047aa5a7574712585bcae28f79
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
(cherry picked from commit e79b1dcdf5)
Reviewed-by: Simo Fält <simo.falt@qt.io>
[ChangeLog][QtNetwork][SSL] The Schannel backend now supports ALPN and
thus HTTP/2.
Change-Id: I1819a936ec3c9e0118b9dad12681f791262d4db2
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
For some reason behavior of SecureTransport has changed from 10.12 to 10.13
and then to 10.14. On 10.13 SecureTransport fails upon receiving the server's
certificate with 'Unrecoverable error', before we can do a manual verification
and accept the certificate as trusted. Analysis of available source code
shows that they, apparently, do not like MD5 hash which our server is using.
Until certificate is updated on the server or we switch completely to
the Docker-based solution we have to BLACKLIST tests that connect to our
current network test-server. Oddly enough, on 10.14 SecureTransport is
less mean.
Task-number: QTBUG-69873
Change-Id: I7da1883e0970a2f6ddd8385f193b76116d6983e0
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Currently only available for the OpenSSL backend to use but doesn't
actually rely on anything OpenSSL specific.
Move it so it can be used by the Schannel backend in an upcoming patch
Change-Id: Ia29b153bf3f29cff0d62a41ec5dd7d4671a18095
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
While it's not common it still occurs, perhaps especially with 127.0.0.1
Can be tested by attempting to connect to https://1.1.1.1/ using Qt.
Change-Id: Idad56476597ab570b8347236ff700fa66ab5b1f4
Fixes: QTBUG-71828
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Adds support for Schannel, an SSL backend for Windows, as an
alternative to OpenSSL.
[ChangeLog][QtNetwork][Ssl] Added support for Schannel on Desktop
Windows. To build Qt with Schannel support use '-schannel' during
configure.
Task-number: QTBUG-62637
Change-Id: Ic4fb8ed3657dab994f9f4a4ac5cbddc7001a0a46
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
... as we normally do in other tests, using localhost.
Change-Id: I7969d7bfd50b545adae7e23476d17b6224e9a8fc
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
since we'll refuse to continue with a handshake, failing in initSslContext()
on a disabled protocol versions. Then, functions like waitForEncrypted,
connectToHostEncrypted, startServerEncryption and startClientEncryption
should either bail out early (who needs a TCP connection which we'll
abort anyway?) or bail out whenever we can, as soon as a disabled protocol
was found in a configuration. This change also makes the behavior
of different back-ends consistent, since it's a general code-path
that reports the same SslInvalidUserData error. Update auto-test to
... actually test what it claims it tests.
Task-number: QTBUG-72196
Task-number: QTBUG-72179
Change-Id: I548468993410f10c07ce5773b78f38132be8e3e0
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
As per RFC 6176 (2011) and RFC 7568 (2015).
Code-wise, we're left with the decision of what to do with a few
enumerators in QSsl::Protocol; I've made TlsV1SslV3 act as TlsV1,
and adjusted the description of AnyProtocol.
A new test was introduced - deprecatedProtocol() - to test that
we, indeed, do not allow use of SSL v2 and v3. protocol() and
protocolServerSide() were reduced to exclude the (now) no-op
and meaningless tests - neither client nor server side can
start a handshake now, since we bail out early in initSslContext().
[ChangeLog][QtNetwork][SSL] Support for SSLv2 and SSLv3
sockets has been dropped, as per RFC 6176 (2011)
and RFC 7568 (2015).
Change-Id: I2fe4e8c3e82adf7aa10d4bdc9e3f7b8c299f77b6
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
By accident, when we erroneously tried testing TlsV1_3 on macOS with
SecureTransport (which does not support TLS 1.3) we hit this quite
subtle problem: it can happen that a server-side socket is never
created but a client (after TCP connection was established) fails
in TLS initialization and ... stops the loop preventing
SslServer::incomingConnection() from creating its socket. Then we
dereference nullptr.
Task-number: QTBUG-71638
Change-Id: I8dc5a4c53022a25aafe2c80a6931087517a48441
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
1. Remove the conditional inclusion of DTLS versions, they made difficult
and unnecessary ugly adding new protocols (something like TlsV1_2OrLater + 4).
2. OpenSSL 1.1.1 first introduced TLS 1.3 support. OpenSSL 1.1 back-end is
compatible with OpenSSL 1.1.1, but would fail to extract/report protocol
versions and set versions like 'TLS 1.3 only' or 'TLS 1.3 or better' on a
new context. Given 1.1.1 is deployed/adapted fast by different distros,
and 5.12 is LTS, we fix this issue by introducing QSsl::Tls1_3 and
QSsl::Tls1_3OrLater.
SecureTransport, WinRT and OpenSSL below 1.1.1 will report an error in case
the application requests this protocol (SecureTransport in future will
probably enable TLS 1.3).
Saying all that, TLS 1.3 support is experimental in QSslSocket.
Done-by: Albert Astals Cid <albert.astals.cid@kdab.com>
Done-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Change-Id: I4a97cc789b62763763cf41c44157ef0a9fd6cbec
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Some of the enums were cast to int on comparison. That just makes it
harder to know what the values were.
And verifyClientCertificate had 4 cases which were named the same as 4
others.
Change-Id: I09e8e346a6f416236a92073cf9a8f349938d37ef
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The logic seems to be simple - if client code on error signal
tries to close TLS socket and this socket has buffered data,
it calls 'flush' and 'transmit' or even 'startHandshake' as
a result, which in turn will set and emit error again. To auto-
test this, we initiate a handshake with pre-shared key hint
on a server side and both client/server sockets incorrectly
configured (missing PSK signals). We also do early write
into the client socket to make sure it has some data
buffered by the moment we call 'close'.
Task-number: QTBUG-68089
Task-number: QTBUG-56476
Change-Id: I6ba6435bd572ad85d9209c4c81774a397081b34f
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
It all started from the compiler's warnings about 'this' captured but
not used in lambdas. While fixing this it was noticed that 'client' socket
has a lifetime longer than the test case itself (the socket has a parent,
which is tst_QSslSocket object). The 'server' socket was simply leaked.
So there is no guarantee that some of them (or both) later, after the
test failed in one of QVERIFY, for example, does not emit 'encrypted'
upon receiving more data; this will result: in reading/writing from/to
invalid memory location (captured local 'encryptedCount') and/or probably
exiting event loop when it's not expected to do so.
Change-Id: I51de0493d989a5ba36de2cef58d35526c0e26cda
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Previously the test worked because the client was the last party to know
when encryption was established. However, due to changes in the TLSv1.3
handshake the server is now the last one.
In either case, relying on both to be encrypted when one of them is
finished is not great, so now we only quit the event loop when both
client and server have emitted 'encrypted'.
Change-Id: Ic1fc75671206d866f7ea983805fd58a99657aac6
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Replace with QSignalSpy or QTRY_COMPARE when possible.
Task-number: QTBUG-63992
Change-Id: I18dc8837301424855487a12ee62451a5aeb21bf0
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Properly handle single protocol TLS configurations. Previously,
due to the use of generic (non version-specific) client/server method
they worked as ranges of protocols instead. This also fixes a couple
of previously broken tests.
Task-number: QTBUG-67584
Change-Id: Ied23113a4fab6b407a34c953e3bd33eab153bb67
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Commit f55c73ede2 added various backendConfig methods;
API review for 5.11 pointed out that Config should not be abbreviated.
Change-Id: I3b294b44a030b2a6e4cdd034fa27583c228dfe42
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
