summaryrefslogtreecommitdiffstats
path: root/tests/auto/network/ssl
Commit message (Collapse)AuthorAgeFilesLines
* Remove blacklisting of tst_qsslsocket_onDemandCertificates_memberAllan Sandfeld Jensen2019-03-271-2/+0
| | | | | | | | It is constantly passing according to grafana. Change-Id: I4953cd54e27adde8dad79e9a0f025960802e6c7a Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* Merge remote-tracking branch 'origin/5.12' into 5.13Qt Forward Merge Bot2019-03-111-2/+2
|\ | | | | | | Change-Id: Iecdf00ca61d819bde532daa42f093860ec4a499e
| * Expand blacklisting of tst_qsslkey to cover all versions of RHELsTony Sarajärvi2019-03-101-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Previous blacklisting 5c4e5032b5162341168c1cec09f0247c7f2283e7 only covered RHEL 6.6 and RHEL 7.4. The problem however exists in all 6.x and 7.x distros as they have the same openssl. This however leaves us the problem with future RHEL 8. This will keep blacklisting these tests there as well. We need a way to blacklist versions with a wildcard so that we could say RHEL-7.* Task-number: QTBUG-46203 Change-Id: I2cc52ba2eac949214ecaa02e19d9e623d5befc49 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* | Schannel: Add ALPN supportMårten Nordheim2019-01-281-3/+19
| | | | | | | | | | | | | | | | [ChangeLog][QtNetwork][SSL] The Schannel backend now supports ALPN and thus HTTP/2. Change-Id: I1819a936ec3c9e0118b9dad12681f791262d4db2 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* | Merge "Merge remote-tracking branch 'origin/5.12' into dev" into ↵Liang Qi2019-01-281-0/+6
|\ \ | | | | | | | | | refs/staging/dev
| * | Merge remote-tracking branch 'origin/5.12' into devLiang Qi2019-01-261-0/+6
| |\| | | | | | | | | | | | | | | | | | | | | | Conflicts: src/android/templates/AndroidManifest.xml tests/auto/widgets/styles/qstylesheetstyle/tst_qstylesheetstyle.cpp Change-Id: I4c9679e3a8ebba118fbf4772301ff8fde60455b9
| | * tst_qsslsocket - blacklist several test temporarilyTimur Pocheptsov2019-01-241-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | QSslSocket: Fix isMatchingHostname when the CN is an IP AddressMårten Nordheim2019-01-282-0/+27
|/ / | | | | | | | | | | | | Change-Id: Id083c1434fcb3a64af40e6f8df720719c1029ca7 Fixes: QTBUG-73289 Reviewed-by: Liang Qi <liang.qi@qt.io> Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* | tst_qsslsocket: Make an ALPN test available to other backendsMårten Nordheim2019-01-241-40/+41
| | | | | | | | | | | | | | | | | | | | | | 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>
* | Ssl: Add support for IP-address in alternate subject nameMårten Nordheim2019-01-242-0/+31
| | | | | | | | | | | | | | | | | | | | 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>
* | Schannel supportMårten Nordheim2019-01-223-10/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | disabledProtocol() - use the right address when connectingTimur Pocheptsov2019-01-091-2/+2
| | | | | | | | | | | | | | ... as we normally do in other tests, using localhost. Change-Id: I7969d7bfd50b545adae7e23476d17b6224e9a8fc Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* | QSsl: do not wait for 'connected'/'encrypted' if a protocol is disabledTimur Pocheptsov2018-12-211-44/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | OpenSSL: drop support for SSLv2 and SSLv3Giuseppe D'Angelo2018-12-131-129/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Add tst_QOcsp auto-testTimur Pocheptsov2018-12-0611-0/+1074
| | | | | | | | | | | | | | | | | | 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>
* | Amend 7f77dc84fb to simplify the parameters of createPlainTestRowsLars Schmertmann2018-11-241-3/+3
| | | | | | | | | | Change-Id: I61370a46722f729ea53cb365eab556a97ec5ee7b Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* | Add support for Diffie-Hellman keys to QSslKeyLars Schmertmann2018-11-2314-2/+82
| | | | | | | | | | | | | | | | | | | | | | | | This is necessary to provide details for the key too, when the server is using DHE-RSA-AESxxx-SHAxxx. Amends 7f77dc84fb434f33ffe96f6633792706b80fb0a3. 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>
* | Merge remote-tracking branch 'origin/5.12' into devLiang Qi2018-11-221-3/+57
|\| | | | | | | | | | | | | | | | | | | Conflicts: src/corelib/io/qdir.cpp src/corelib/kernel/qtimer.cpp src/corelib/kernel/qtimer.h Done-With: Edward Welbourne <edward.welbourne@qt.io> Change-Id: I683d897760ec06593136d77955f8bc87fdef3f9f
| * Merge remote-tracking branch 'origin/5.12.0' into 5.12Liang Qi2018-11-161-3/+57
| |\ | | | | | | | | | Change-Id: Ic1dd39044e19f50e1068d4ac70dacaad6440e570
| | * Add missing protocol enumerators, report TLS 1.3 if negotiatedTimur Pocheptsov2018-11-071-3/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Merge remote-tracking branch 'origin/5.12' into devLiang Qi2018-11-101-4/+10
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/corelib/serialization/qcborcommon.h src/corelib/tools/qlocale_data_p.h tests/auto/network/ssl/qsslsocket/tst_qsslsocket.cpp Done-with: Edward Welbourne <edward.welbourne@qt.io> Change-Id: Ibed987f6d77a0294f78f67d78625237616082416
| * | Make tst_qsslsocket::protocolServerSide() less flakyTimur Pocheptsov2018-11-071-4/+10
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* / tst_QSslSocket: deduplicate datatags and don't cast to intMårten Nordheim2018-10-161-8/+8
|/ | | | | | | | | | | | 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>
* Fix builds without DTLSAllan Sandfeld Jensen2018-10-091-1/+1
| | | | | | | Change-Id: Ic7215c7aa0bf6f7b37ae34649d809f2e1e1ee95b Reviewed-by: Jesus Fernandez <Jesus.Fernandez@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* tst_qdtls: add 'invalidConfiguration' testTimur Pocheptsov2018-08-101-0/+15
| | | | | | | | | | 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>
* QDtls: delay protocol version verificationTimur Pocheptsov2018-08-101-6/+0
| | | | | | | | | | | | | | | | | | | 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>
* Extend 'ignoreExpectedErrors' testTimur Pocheptsov2018-08-021-9/+28
| | | | | | | | | 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>
* QDtls: respect pre-set verification errorsTimur Pocheptsov2018-07-311-0/+27
| | | | | | | | | | 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>
* QDtls - use conventional namesTimur Pocheptsov2018-07-271-24/+24
| | | | | | | | 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>
* QDtls - refactorTimur Pocheptsov2018-07-262-31/+31
| | | | | | | | | 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>
* prune cargo-culted and obsolete winsock deps from autotestsOswald Buddenhagen2018-07-1911-11/+0
| | | | | Change-Id: I9666598d34e965d7058aeb2b2e7fb3f59600675c Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* QSslSocketBackendPrivate - avoid recursion while handing errorsTimur Pocheptsov2018-07-121-0/+63
| | | | | | | | | | | | | | | | | 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>
* QDtls - handle server-side timeoutsTimur Pocheptsov2018-07-051-1/+6
| | | | | | | | | | | | | 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>
* DTLS cookie auto-test - do not check the exact UDP socket errorsTimur Pocheptsov2018-06-281-2/+0
| | | | | | | | | | 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>
* tst_QSslSocket::qtbug18498_peek() - fix several problemsTimur Pocheptsov2018-06-281-18/+16
| | | | | | | | | | | | | | | 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>
* Add tst_QDtls auto-testTimur Pocheptsov2018-06-2115-1/+1583
| | | | | | | | | | | | | | | | | | | | | | | 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>
* QDtlsClientVerifier - add auto-testTimur Pocheptsov2018-06-193-2/+502
| | | | | | | | | | | | | | | | 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>
* Merge remote-tracking branch 'origin/5.11' into devLiang Qi2018-05-141-2/+10
|\ | | | | | | | | | | | | | | | | Conflicts: mkspecs/features/qt_module_headers.prf tests/auto/widgets/itemviews/qheaderview/tst_qheaderview.cpp tests/auto/widgets/kernel/qwidget/BLACKLIST Change-Id: I2a08952d28d1d0e3d73f521a3d44700ce79ff16c
| * OpenSSL v1.1.1: fix qtbug18498_peekMårten Nordheim2018-05-111-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge remote-tracking branch 'origin/5.11' into devLiang Qi2018-05-081-16/+5
|\| | | | | | | | | | | | | | | Conflicts: src/plugins/sqldrivers/sqlite/qsql_sqlite.cpp tests/auto/corelib/io/qresourceengine/qresourceengine_test.pro Change-Id: I3169f709cc2a1b75007cb23c02c4c79b74feeb04
| * tests/auto/network: Avoid unconditional qWait()sKari Oikarinen2018-05-081-16/+5
| | | | | | | | | | | | | | | | | | 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>
* | Merge remote-tracking branch 'origin/5.11' into devQt Forward Merge Bot2018-05-052-1/+48
|\| | | | | | | Change-Id: Ib58433da04bffb5dfab5486b80f17f39cc4145fa
| * OpenSSL 1.1.1: Fix tst_QSslCertificate::toTextMårten Nordheim2018-05-042-1/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Introduce QPasswordDigestor functionsMårten Nordheim2018-04-233-0/+176
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | QSslKey: Implement PKCS#8 support for the generic backendMårten Nordheim2018-04-231-5/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge remote-tracking branch 'origin/5.11' into devLars Knoll2018-04-121-10/+4
|\| | | | | | | Change-Id: I9f802cb9b4d9ccba77ca39428a5cb1afd2d01642
| * QSslSocket (OpenSSL 1.1) - respect requested protocol versionTimur Pocheptsov2018-04-111-10/+4
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Fix loading pkcs#8 encrypted DER-encoded keys in opensslMårten Nordheim2018-04-11116-8/+579
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Revert "tst_QSslSocket::signatureAlgorithm - fix for OpenSSL 1.1"Timur Pocheptsov2018-04-101-7/+1
| | | | | | | | | | | | | | | | | | | | | | This reverts commit e2694fa602e95a9043561e7dfb9f5956c08a5f14. I'm reverting this patch - I'll fix QSslSocket instead to respect the requested protocol version. Change-Id: Ia4bb09a8801c58bc76837518934ac7a3eedd3c07 Reviewed-by: Lars Schmertmann <lars.schmertmann@governikus.de> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* | Merge remote-tracking branch 'origin/5.11' into devQt Forward Merge Bot2018-04-101-1/+2
|\| | | | | | | Change-Id: I0120f804522c0c652e9537b6e9fe08189f071ed2
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-24 01:17:23 +0000