When using cipher algorithms with forward secrecy an ephemeral key is
used to generate the symmetric session key. Beside the SSL certificate's
key, this ephemeral key is of cryptographic interest.
The ephemeral key is chosen by the server side - currently statically in
the Qt implementation - so it is only of interest on the client side to
check it. Therefore the ephemeral key is the null key if the connection
is set up in server mode or a cipher without forward secrecy is used.
Change-Id: If241247dbb8490a91233ae47f2b38952c6591bf4
Reviewed-by: Markus Goetz (Woboq GmbH) <markus@woboq.com>
TEST_HELPER_INSTALLS cannot be used on platforms with no
QProcess support.
Change-Id: I2a6a283d94ca4487fc628449c53fc37140dd291d
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
Move some code (like registrations of meta types) from init() to
initTestCase() in the process.
Change-Id: I57db5156647cfadab554fbed853b2e68b2815f3b
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@theqtcompany.com>
- Replace Q[TRY]_VERIFY(pointer == 0) by Q[TRY]_VERIFY(!pointer).
- Replace Q[TRY]_VERIFY(smartPointer == 0) by
Q[TRY]_VERIFY(smartPointer.isNull()).
- Replace Q[TRY]_VERIFY(a == b) by Q[TRY]_COMPARE(a, b) and
add casts where necessary. The values will then be logged
should a test fail.
Change-Id: Icaa1edafcc6e2779fbd6dbc2c058544d6e07f1e9
Reviewed-by: Richard J. Moore <rich@kde.org>
The comment about non-OpenSSL backends not reproting a specific error
for self-signed certificates contained a typo, this fixes it.
Change-Id: I3010981d5d87d68ebf5e984c003b8bbbfb019b96
Reviewed-by: Timur Pocheptsov <Timur.Pocheptsov@digia.com>
They didn't show up in the "old" CI runs because they usually pass the second
time they are executed - which the testrunner does. The new CI doesn't do that
anymore, instead we now mark those tests explicitly and will track their record
of passing and failing in the new metrics database.
Change-Id: Id34dd6f792f38995b07b6fec88f833df64de2f8b
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Include class name, object name and file name when available.
For the bug in question:
QIODevice::read: device not open
becomes
QIODevice::read (QTcpSocket, "QFtpDTP Passive state socket"): device not open
Adding a static function also makes it easier to set a breakpoint
and find the culprit.
Task-number: QTBUG-46112
Change-Id: Ic181d8ab292912d1acbcc3cb84d9679fe4842ca0
Reviewed-by: Laszlo Papp <lpapp@kde.org>
Reviewed-by: Alex Trotsenko <alex1973tr@gmail.com>
Reviewed-by: Kai Koehne <kai.koehne@theqtcompany.com>
Currently the cipher preferred by the client will always be used for SSL
connections. This change makes it so that by default the ciphers
specified by the server will be used (like the Apache SSLHonorCipherOrder
option). This behavior can be disabled using a new SslOption.
[ChangeLog][QtNetwork][QSslSocket] QSslSocket will now default to using
the cipher preferences of the server socket when used as an SSL server.
This can be disabled using the QSslConfiguration.
Change-Id: I2d16d10145cf88a7412f30ef960d87024777de1c
Reviewed-by: Peter Hartmann <peter-qt@hartmann.tk>
This system is no longer in the CI rotation and we haven't had reports
of the same issues happening on later versions. Either the issues have
since been fixed or they were never an issue in Qt in the first place.
This commit has the additional benefit of getting rid of the following
shell error when qmake was run:
sh: line 0: [: =: unary operator expected
as /etc/lsb-release hasn't contained DISTRIB_CODENAME for some time and
proper quoting was never implemented (not even qtcpsocket.pro).
Change-Id: Ia0aac2f09e9245339951ffff13c829e910ee64e9
Reviewed-by: Albert Astals Cid <albert.astals@canonical.com>
Reviewed-by: Tony Sarajärvi <tony.sarajarvi@digia.com>
Reviewed-by: Richard J. Moore <rich@kde.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Secure Transport relies on keychains, both client/server are constantly
updating default keychain and as a result tests are failing: when
verification is expected to fail, it succeeds; when the number of certificates
is expected to be 1 - it's 2 (Secure Transport can find certificates in a keychain).
This makes verifyClientCertificate test quite useless at the moment - QSKIP it.
Change-Id: I578398b4912a86dc60f585ac5a1bdd0098914005
Reviewed-by: Richard J. Moore <rich@kde.org>
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.
Outdated header.LGPL removed (use header.LGPL21 instead)
Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing
combination. New header.LGPL-COMM taken in the use file which were
using old header.LGPL3 (src/plugins/platforms/android/extract.cpp)
Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license
combination
Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe
Reviewed-by: Matti Paaso <matti.paaso@theqtcompany.com>
This adds tests to check the behavior of a QSslSocket-based server when
presented with various client certificates.
Change-Id: I431157e46cfb00880ae8b7a33015cce50e56b6bb
Reviewed-by: Daniel Molkentin <daniel@molkentin.de>
Add support for SSL on iOS/OS X by adding a SecureTransport based
backend.
[ChangeLog][QtNetwork][QSslSocket] A new SSL backend for iOS and OS X,
implemented with Apple's Secure Transport (Security Framework).
Change-Id: I7466db471be2a8a2170f9af9d6ad4c7b6425738b
Reviewed-by: Richard J. Moore <rich@kde.org>
Mainly because of a change in certificates which is causing failing
tests.
Change-Id: I8304e5ac4107428a250b71be5df7b5399a811017
Reviewed-by: Tony Sarajärvi <tony.sarajarvi@digia.com>
[ChangeLog][QtNetwork][QSslSocket] It is now possible to use TLS PSK
ciphersuites in client sockets.
Task-number: QTBUG-39077
Change-Id: I5523a2be33d46230c6f4106c322fab8a5afa37b4
Reviewed-by: Richard J. Moore <rich@kde.org>
The setEmptyDefaultConfiguration test creates a socket and connects its
sslErrors signal to tst_QSslSocket's ignoreErrorSlot slot. This slot
expects the socket to have been stored in tst_QsslSocket's "socket"
member, which was not being done. This patch fixes this problem.
It does beg the question of whether having a "socket" member in the
tst_QSslSocket class is a good idea as it is error prone.
Change-Id: Ic59d1789c5f1ed240c3f0c37981f6ecc35572f0d
Reviewed-by: Richard J. Moore <rich@kde.org>
The sslErrors and peerVerifyError test the same situation: connect to a
server which is using the fluke certificate, using the incorrect host name.
They connect respectively to qt-test-server:993 and the.server.ip.address:443.
The sslErrors is prone to backend-dependent failures concerning the order
in which SSL errors are received, just like the peerVerifyError test was
until recently.
This change merges these two tests into one, which is run against the same
two servers as previously. It also adds a check to ensure that sslErrors
and peerVerifyError emit the same SSL errors (regardless of order).
This also fixes the included headers for non-OpenSSL backends.
Change-Id: Ibd5f60d24f1682989378e87729389e4b8f9efac5
Reviewed-by: Richard J. Moore <rich@kde.org>
After the poodle vulnerability SSLv3 should like SSLv2 no longer be
considered safe, so when a user request a safe protocol we should
only allow TLS versions.
[ChangeLog][QtNetwork][QSsl] QSsl::SecureProtocols now also excludes SSLv3
Change-Id: If825f6beb599294b028d706903b39db6b20be519
Reviewed-by: Richard J. Moore <rich@kde.org>
Currently the peerVerifyError test for QSslSocket makes an assumption
about the order in which SSL errors are emitted by peerVerifyError. This
assumption does not necessarily hold for non-OpenSSL backends.
This change fixes this assumption, and also checks that HostNameMismatch
was found both in the errors emitted by peerVerifyError and by sslErrors.
Change-Id: I856d1ea43b36332db0f178d35fc14a4bb18ad673
Reviewed-by: Richard J. Moore <rich@kde.org>
Some of the QSslSocket tests use OpenSSL-specific symbols. This
change fixes this issue.
Change-Id: Ib67efa42a15facaf0ad34fc0466341a37d945d1e
Reviewed-by: Andrew Knight <andrew.knight@digia.com>
This changes tests which use QSslCertificate::handle() to determine
if a certificate is null to use QSslCertificate::isNull() instead.
This is required for non-OpenSSL backends which do not actually
expose a private handle.
Change-Id: I9523ba0dd00d47ba337b543ad34840125db99bfb
Reviewed-by: Andrew Knight <andrew.knight@digia.com>
This moves the socket backend's host name matching functions up to
QSslSocketPrivate so that they can be shared between backends. This
works, as there is no OpenSSL-specific code here.
Change-Id: I73c2081fdc2e60a44c90e90800d1e1877391a626
Reviewed-by: Richard J. Moore <rich@kde.org>
Discussed with Peter and agreed that it's a slightly better fit there.
Change-Id: If8db777336e2273670a23d75d8542b30c07e0d7b
Reviewed-by: Daniel Molkentin <daniel@molkentin.de>
Reviewed-by: Peter Hartmann <phartmann@blackberry.com>
Add support for loading certificates and keys from PKCS#12 bundles
(also known as pfx files).
Task-number: QTBUG-1565
[ChangeLog][QtNetwork][QSslSocket] Support for loading PKCS#12
bundles was added. These are often used to transport keys and
certificates conveniently, particularly when making use of
client certificates.
Change-Id: Idaeb2cb4dac4b19881a5c99c7c0a7eea00c2b207
Reviewed-by: Daniel Molkentin <daniel@molkentin.de>
Change-Id: I2912dcca77270582f6e989b8b3fb72b82f6f70d6
Reviewed-by: Peter Hartmann <phartmann@blackberry.com>
Reviewed-by: Richard J. Moore <rich@kde.org>
Despite supporting DH and ECDH key exchange as a client, Qt did not provide
any default parameters which prevented them being used as a server. A
future change should allow the user to control the parameters used, but
these defaults should be okay for most users.
[ChangeLog][Important Behavior Changes] Support for DH and ECDH key exchange
cipher suites when acting as an SSL server has been made possible. This
change means the you can now implement servers that offer forward-secrecy
using Qt.
Task-number: QTBUG-20666
Change-Id: I469163900e4313da9d2d0c3e1e5e47ef46320b17
Reviewed-by: Daniel Molkentin <daniel@molkentin.de>
Reviewed-by: Peter Hartmann <phartmann@blackberry.com>
Output the SSL library version, output socket error string on connection
failure consistently, silence numerous warnings about QIODevice not
being open in tst_QSslSocket::constructing.
Change-Id: Ia23d42de5b2daca55b2f6f50af025d61e99c52a0
Reviewed-by: Peter Hartmann <phartmann@blackberry.com>
Any cipher that is < 128 bits is excluded from the default SSL
configuration. These ciphers are still included in the list
of availableCiphers() and can be used by applications if required.
Calling QSslSocket::setDefaultCiphers(QSslSocket::availableCiphers())
will restore the old behavior.
Note that in doing so I spotted that calling defaultCiphers() before
doing other actions with SSL had an existing bug that I've addressed
as part of the change.
[ChangeLog][Important Behavior Changes] The default set of
ciphers used by QSslSocket has been changed to exclude ciphers that are
using key lengths smaller than 128 bits. These ciphers are still available
and can be enabled by applications if required.
Change-Id: If2241dda67b624e5febf788efa1369f38c6b1dba
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Qt since approximately 4.4 has set the verify callback on both the SSL
store and the SSL context. Only the latter is actually needed. This is
normally not a problem, but openssl prior to 1.0.2 uses the verify
code to find the intermediate certificates for any local certificate
that has been set which can lead to verification errors for the local
certificate to be emitted.
Task-number: QTBUG-33228
Task-number: QTBUG-7200
Task-number: QTBUG-24234
Change-Id: Ie4115e7f7faa1267ea9b807c01b1ed6604c4a16c
Reviewed-by: Peter Hartmann <phartmann@blackberry.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... but rather throw an error, so the HTTP layer can recover from a SSL
shutdown gracefully. In case the other side sent us a shutdown, we should
not send one as well, as it results in an error.
Change-Id: Ie7a56cf3008b6ead912aade18dbec67846e2a87e
Reviewed-by: Richard J. Moore <rich@kde.org>
The connection to qt-project.org seems to be the one that causes this
particular test case to fail.
Task-number: QTBUG-29941
Change-Id: Ie5e430646997e86e3acb04132cd90a1773a091da
Reviewed-by: Richard J. Moore <rich@kde.org>
Reviewed-by: Peter Hartmann <phartmann@blackberry.com>
It is flakey and often blocks integration.
Task-number: QTBUG-29730
Change-Id: I8acfc243ec6a6782b7f7d78fc27827f3fdc1ce52
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
