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>
This patch introduces a private 'API' to enable server-side OCSP responses
and implements a simple OCSP responder, tests OCSP status on a client
side (the test is pretty basic, but for now should suffice).
Change-Id: I4c6cacd4a1b949dd0ef5e6b59322fb0967d02120
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This is necessary to provide details for the key too,
when the server is using DHE-RSA-AESxxx-SHAxxx.
Amends 7f77dc84fb.
Change-Id: I8ab15b6987c17c857f54bc368df3c6c1818f428c
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@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>
Test that we don't silently replace an invalid TLS configuration with
the default one (for now, the only thing that is considered to be
non-valid - is having non-DTLS protocol set).
Change-Id: I6f714b009cf1345a085a3f26d638fc31330f1a94
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
A weird behavior of the DTLS server example, when linked with 1.0.2,
exposed that client code, requesting an invalid protocol (for example, SSLv3)
can end-up with connection encrypted with DTLS 1.2 (which is not that bad,
but totally surprising). When we check the protocol version early in
setDtlsConfiguration() and find a wrong version, we leave our previous
configuration intact and we will use it later during the handshake.
This is wrong. So now we let our user set whatever wrong configuration they
have and later fail in TLS initialization, saying -
'Unsupported protocol, DTLS was expected'.
Auto-test was reduced - the follow-up patch will introduce a new
'invalidConfiguration' auto-test.
Change-Id: I9be054c6112eea11b7801a1595aaf1d34329e1d2
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
with a case when we fail to ignore/pre-set one of possible
verification errors.
Change-Id: I23b06243b61acef1ef3576c51529f3ef6601ba7d
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
That's actually how ignoreVerificationErrors (and QSslSocket::ignoreSslErrors)
are used to set the expected/known verification errors before handshake.
Auto-test updated too.
Change-Id: I9c700302d81ddb383a4a750fafd594373fb38ace
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
More Qt-style and more natural, also, shorter names.
Change-Id: I97bd68a8614126d518a3853027661435dc4e080d
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This patch renames rather awkward 'remote' into more conventional
'peer' (similar to what we have in QAbstractSocket).
Change-Id: Ifc45e538b8adf9cc076bd7aee693277829fd94dc
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@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>
According to RFC 6347 a DTLS server also must retransmit buffered message(s)
if timeouts happen during the handshake phase (so it's not a client only as
I initially understood it).
Conveniently so an auto-test is already in place and needs just a tiny
adjustment - handshakeWithRetransmission covers both sides.
Change-Id: If914ec3052e28ef5bf12a40e5eede45bbc53e8e0
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
It was observed on OpenSUSE VM in CI - apparently, even after succesfull
read from UDP socket error was not UnknownSocketError. While it's under
investigation, the DTLS auto-test should limit itself by DTLS things and
barely test IO success (socket-wise) when needed.
Change-Id: I0773a02c591432b0d6c894f4131f70e41dc7ed72
Reviewed-by: Mårten Nordheim <marten.nordheim@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>
The test is somewhat similar to tst_QSslSocket but is smaller (in scope, will
grow in future), it has no QTcpSocket/QAbstractSocket-specific things and
has more DTLS-specific code. At the moment it does not use our network
test server, all work is done in the same process with two QUdpSockets
and two QDtls objects. We test (both on client/server ends):
- parameters validation (for all functions that do this) and
the correctness of error codes/handshake states
- handshake procedure (with/out certificates and with pre-shared keys)
- timeouts and re-transmissions during (D)TLS handshake
- peer verification (and related verification errors)
- aborted/resumed handshake
- encrypted I/O
- DTLS shutdown
For now, this test is OpenSSL-only.
Task-number: QTBUG-67597
Change-Id: I27006bfe3d6c02b89596889e8482a782c630402a
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This part of DTLS is relatively easy to test: we never do a complete
handshake. Certificates, verification, ciphers, etc. - do not matter
at this stage (to be tested in tst_QDtls). Errors are mostly insignificant
and can be ignored or handled trivially.
The test is OpenSSL-only: SecureTransport failed to correctly implement/
support server-side DTLS, the problem reported quite some time ago and
no fixes from Apple so far.
Task-number: QTBUG-67597
Change-Id: I21ad4907de444ef95d5d83b50083ffe211a184f8
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@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>
The formatting of the output from QSslCertificate::toText has
changed slightly from before, so it no longer matches the test's
data.
From what I can tell we just do a manual sanity check and create
a new file with the new output and then augment the test.
Task-number: QTBUG-67463
Change-Id: I751e5a3f9a28015f97c895cea47384704fd68e38
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Added a few functions to derive keys from passwords. Currently it
supports PBKDF1 and PBKDF2 as defined in
RFC 8018 ( https://tools.ietf.org/html/rfc8018 ).
[ChangeLog][QtNetwork][QPasswordDigestor] Added QPasswordDigestor
Task-number: QTBUG-30550
Change-Id: I2166b518bd8b54e3486514166e76fd9ba2f219c8
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This patch adds the ability to decode keys which are encoded with PKCS#8
using the generic back-end (used in winrt and secure transport).
It works on both WinRT and macOS; however QSslKey seems unused in the
WinRT backend and it seems only RSA keys can be used for certificates
on macOS. Meaning that DSA and Ec, which in theory* should represent
their unencrypted versions, can't currently be tested properly.
* Can also be confirmed by loading the key using the ST or WinRT
backend, calling toPem(), writing the output to a file and then loading
the unencrypted key using openssl.
[ChangeLog][QtNetwork][QSslKey] Added support for PKCS#8-encoded keys
in the generic SSL back-end (used for SecureTransport on macOS and for
WinRT). Note that it does not support keys encrypted with a PKCS#12
algorithm.
Task-number: QTBUG-59068
Change-Id: Ib27338edc7dbcb5c5e4b02addfdb4b62ac93a4c3
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
When we load DER-encoded keys in the openssl-backend we always turn it
into PEM-encoded keys (essentially we prepend and append a header and
footer and use 'toBase64' on the DER data).
The problem comes from the header and footer which is simply chosen
based on which key algorithm was chosen by the user. Which would be
wrong when the key is a PKCS#8 key. This caused OpenSSL to fail when
trying to read it. Surprisingly it still loads correctly for unencrypted
keys with the wrong header, but not for encrypted keys.
This patch adds a small function which checks if a key is an encrypted
PKCS#8 key and then uses this function to figure out if a PKCS#8 header
and footer should be used (note that I only do this for encrypted PKCS#8
keys since, as previously mentioned, unencrypted keys are read correctly
by openssl).
The passphrase is now also passed to the QSslKeyPrivate::decodeDer
function so DER-encoded files can actually be decrypted.
[ChangeLog][QtNetwork][QSslKey] The openssl backend can now load
encrypted PKCS#8 DER-encoded keys.
Task-number: QTBUG-17718
Change-Id: I52eedf19bde297c9aa7fb050e835b3fc0db724e2
Reviewed-by: Edward Welbourne <edward.welbourne@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>
Except RHEL-6.6 and 7.4
It was blacklisted in f3939d943e, along
with a lot of other entries. No specifics are known about why it was
blacklisted originally, but now it only fails on RHEL because they
use OpenSSL 1.0.1.
Change-Id: I6d1d1b7b7bf5386b2115b8780163550cf03bbad7
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The test creates client and server sockets with mismatching protocol versions,
trying different combinations, for example: 1) server (TLS 1.0) vs
client (TLS 1.2) or 2) server (TLS 1.2) vs client (TLS 1.1), etc.
Since TLS v < 1.2 does not support signature algorithms, they are ignored
and handshake is always successful. But our new OpenSSL 1.1 backend uses
generic TLS_client_method and TLS_server_method when creating SSL_CTX.
This means, both server and client will support TLS v. 1.2, they
will have no shared signature algorithms, thus handshake will fail
with an error string similar to this:
"tls1_set_server_sigalgs:no shared signature algorithms".
For OpenSSL 1.1 this test makes no sense.
Task-number: QTBUG-67456
Change-Id: Ibb2a12eea5e5c0ebaeee7d0719cc721ecf4763e6
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>
With this change it is possible to use all supported
configurations in different backends without any new interfaces.
Change-Id: Ib233539a970681d30ae3907258730e491f8d3531
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Apparently this (undocumented) TESTDATA feature creates resource files,
but lets you use wildcards as well, which is very handy.
The reason I didn't know/realize this when adapting the tests to use a
".qrc"-file* was because some of the test-cases were using relative
paths instead of the 'testDataDir' variable.
This commit fixes the remaining uses of relative paths, removes a
usage of QDir::setCurrent, and adapts QSslSocket to use TESTDATA.
* in now-reverted commit e1600c1a73
Change-Id: Iee6d88f1e0810eeaadac90e7d44bc6db84bfeabf
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Jesus Fernandez <Jesus.Fernandez@qt.io>
Then we don't need to add a leading slash. (minor clean-up)
Change-Id: I86af224841009fda838e7cb89d47d324963328c9
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
