Re: [Interest] wss:// on localhost
On 3/8/20 9:05 am, Alexander Carôt wrote: I repeat: whatever you do, don't ship a private key. Allright - will consider alternative ideas. Consider generating your own root CA certificate and asking your users to install that in their browser. Then sign the site certificate (for a non-existent, non-registerable domain) with that. Hamish ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] wss:// on localhost
> I repeat: whatever you do, don't ship a private key. Allright - will consider alternative ideas. Best Alex -- http://www.carot.de Email : alexan...@carot.de Tel.: +49 (0)177 5719797 > Gesendet: Montag, 03. August 2020 um 00:28 Uhr > Von: "Thiago Macieira" > An: interest@qt-project.org > Betreff: Re: [Interest] wss:// on localhost > > On Sunday, 2 August 2020 11:43:42 PDT Alexander Carôt wrote: > > P.S.: Also I don't see a way to get access to the key - it is compiled into > > the binary and on top of it it's triple-secured/encypted. > > Very easy to put a breakpoint in your code after it has decrypted the key. > Especially if you're using Qt classes or OpenSSL from a DLL. I agree it's not > every user that will know how to do it, but I bet most people on this mailing > list could do it if they wanted to. > > I repeat: whatever you do, don't ship a private key. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel DPG Cloud Engineering > > > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] wss:// on localhost
On Sunday, 2 August 2020 11:43:42 PDT Alexander Carôt wrote: > P.S.: Also I don't see a way to get access to the key - it is compiled into > the binary and on top of it it's triple-secured/encypted. Very easy to put a breakpoint in your code after it has decrypted the key. Especially if you're using Qt classes or OpenSSL from a DLL. I agree it's not every user that will know how to do it, but I bet most people on this mailing list could do it if they wanted to. I repeat: whatever you do, don't ship a private key. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Win:TLS error/OSX:backward compatibility
> > > Can anyone send me hint how to provide backward compatibility at least to > > > 10.13 (fixing the symbol issue) or lower (fixing the SSL issue) ? > > > > You didn't say what symbols they were. > > Sorry - this is the one which was reported most of the time: > > __chkstd_darwin Correction: it is __chdstk_darwin -- http://www.carot.de Email : alexan...@carot.de Tel.: +49 (0)177 5719797 > Gesendet: Sonntag, 02. August 2020 um 20:08 Uhr > Von: "Alexander Carôt" > An: "Thiago Macieira" > Cc: interest@qt-project.org > Betreff: Re: [Interest] Win:TLS error/OSX:backward compatibility > > > That warning is printed when you try to use one of the QSslSocket functions > > that require OpenSSL and the OpenSSL libraries are not found. > > > > Make sure QSslSocket::supportSsl() returns true. You have to ship the > > OpenSSL > > 1.1 libraries yourself, they are not part of Qt, not even of the pre-built > > binaries. > > > Allright - will do so. > > > > > 2.) In order to provide backward compatibility on OSX I am typically > > > providing two versions: 10.15 and 10.14 are being compiled with the recent > > > version of Qt. This binary launches with 10.13 but throws an errors about > > > missing symbols in libSystem.B.dylib > > > > Are you sure you built Qt with a minimum target version of 10.13? > > My pro-File contains: > > QMAKE_MAC_SDK = macosx10.15 > QMAKE_CFLAGS_RELEASE = "-mmacosx-version-min=10.13" > QMAKE_CXXFLAGS_RELEASE = "-mmacosx-version-min=10.13" > > > > Qt 5.9 cannot do SSL/TLS in 2020 outside of a Mac. You must upgrade to 5.10 > > at > > a minimum. On a Mac, because Qt has used SecureTransport for years, it can > > work. But it could have issues I am not aware of. > > > OK - thanks for sharing this info ! > > > > Either way, Apple stopped supporting 10.12 last year. > > > So - I believe I should use 10.13 as the lowest supported version. > > > > > Can anyone send me hint how to provide backward compatibility at least to > > > 10.13 (fixing the symbol issue) or lower (fixing the SSL issue) ? > > > > You didn't say what symbols they were. > > Sorry - this is the one which was reported most of the time: > > __chkstd_darwin > > There might be others but this would be a good starting point. > > Best > > Alex > > > > > -- > > Thiago Macieira - thiago.macieira (AT) intel.com > > Software Architect - Intel DPG Cloud Engineering > > > > > > > > ___ > > Interest mailing list > > Interest@qt-project.org > > https://lists.qt-project.org/listinfo/interest > > > > -- > http://www.carot.de > Email : alexan...@carot.de > Tel.: +49 (0)177 5719797 > > > > Gesendet: Sonntag, 02. August 2020 um 19:31 Uhr > > Von: "Thiago Macieira" > > An: interest@qt-project.org > > Betreff: Re: [Interest] Win:TLS error/OSX:backward compatibility > > > > On Saturday, 1 August 2020 00:13:21 PDT Alexander Carôt wrote: > > > Hello all, > > > > > > my software's websocket server is now running in secure mode including > > > certificate integration. This works great apart from two details. > > > > > > 1.) On some Windows machines I get the following error: > > > > > > qt.network.ssl: QSslSocket::startServerEncryption: TLS initialization > > > failed > > > > > > I believe there are some missing libs on these machine but I am not sure > > > how > > > to resolve this issue conveniently. > > > > That warning is printed when you try to use one of the QSslSocket functions > > that require OpenSSL and the OpenSSL libraries are not found. > > > > Make sure QSslSocket::supportSsl() returns true. You have to ship the > > OpenSSL > > 1.1 libraries yourself, they are not part of Qt, not even of the pre-built > > binaries. > > > > > 2.) In order to provide backward compatibility on OSX I am typically > > > providing two versions: 10.15 and 10.14 are being compiled with the recent > > > version of Qt. This binary launches with 10.13 but throws an errors about > > > missing symbols in libSystem.B.dylib > > > > Are you sure you built Qt with a minimum target version of 10.13? > > > > > For 10.12 and lower I am compiling my app with Qt version 5.9 which works > > > a > > > usual but the new encryption calls obviously don't. With this version the > > > SSL handshake between browser and app fails. > > > > Qt 5.9 cannot do SSL/TLS in 2020 outside of a Mac. You must upgrade to 5.10 > > at > > a minimum. On a Mac, because Qt has used SecureTransport for years, it can > > work. But it could have issues I am not aware of. > > > > Either way, Apple stopped supporting 10.12 last year. > > > > > Can anyone send me hint how to provide backward compatibility at least to > > > 10.13 (fixing the symbol issue) or lower (fixing the SSL issue) ? > > > > You didn't say what symbols they were. > > > > -- > > Thiago Macieira - thiago.macieira (AT) intel.com > > Software Architect - Intel DPG Cloud Engineering > > > > > > > >
Re: [Interest] wss:// on localhost
> Irrespective to any other detail in this thread: this is, by definition, > not secure (sec by obscurity). Completely right but my point is that my current use case actually does not require any security at all. I am really not interested in trivializing security at all, however, in feel like dealing with significant disproportionate issues. Of course this is a result of the security concept but I also think it's worth discussing conceptual problems resulting in the actual thread. I am afraid this might take a little longer ;-) Best Alex -- http://www.carot.de Email : alexan...@carot.de Tel.: +49 (0)177 5719797 > Gesendet: Sonntag, 02. August 2020 um 21:06 Uhr > Von: "Giuseppe D'Angelo via Interest" > An: interest@qt-project.org > Betreff: Re: [Interest] wss:// on localhost > > Il 02/08/20 20:43, Alexander Carôt ha scritto: > > Also I don't see a way to get access to the key - it is compiled into the > > binary and on top of it it's triple-secured/encypted > > Irrespective to any other detail in this thread: this is, by definition, > not secure (sec by obscurity). > > My 2 c, > -- > Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer > KDAB (France) S.A.S., a KDAB Group company > Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com > KDAB - The Qt, C++ and OpenGL Experts > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] wss:// on localhost
Il 02/08/20 20:43, Alexander Carôt ha scritto: Also I don't see a way to get access to the key - it is compiled into the binary and on top of it it's triple-secured/encypted Irrespective to any other detail in this thread: this is, by definition, not secure (sec by obscurity). My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] wss:// on localhost
P.S.: Also I don't see a way to get access to the key - it is compiled into the binary and on top of it it's triple-secured/encypted. This is what we made sure of course. We had lot of talks with several security experts and the common opinion was "well - it's all localhost traffic which per se is secure. So here we basically have to make sure that the browser is not complaining". -- http://www.carot.de Email : alexan...@carot.de Tel.: +49 (0)177 5719797 > Gesendet: Sonntag, 02. August 2020 um 20:12 Uhr > Von: "Alexander Carôt" > An: "Thiago Macieira" > Cc: interest@qt-project.org > Betreff: Re: [Interest] wss:// on localhost > > > I don't think this is a good idea. You might be violating the terms of > > service > > of your certificate provider by doing that. Please check with them. > > In fact I already did - nobody has a concern about it. This traffic is > completey running on localhost - so nobody apart from the user itself is > affected. This approach simply shall satisfy the browser to launch the > localhost websocket. > > Best > > Alex > > -- > http://www.carot.de > Email : alexan...@carot.de > Tel.: +49 (0)177 5719797 > > > > Gesendet: Sonntag, 02. August 2020 um 19:24 Uhr > > Von: "Thiago Macieira" > > An: interest@qt-project.org > > Betreff: Re: [Interest] wss:// on localhost > > > > On Friday, 31 July 2020 23:53:08 PDT Alexander Carôt wrote: > > > Eventually we figured the ideal solution: > > > > > > We ordered a certificate for a sub-domain of our main domain and made the > > > DNS point to localhost. > > > > > > This way we can address our localhost connection via > > > > > > localhost.ourDomain.net > > > > > > This works perfectly without any user interaction - thanks a lot to all of > > > you for you inspiration ! > > > > > > Of course now I have to deal with the tiny details which I will raise in > > > another email in a bit :-) > > > > I don't think this is a good idea. You might be violating the terms of > > service > > of your certificate provider by doing that. Please check with them. > > > > I can see a big attack vector with the information you provided. Since this > > certificate's private key is distributed with your application, anyone who > > has > > this application can extract the private key and create a web service > > impersonating this domain name. If they can compromise DNS at any level > > leading to the user (your server, the user's ISP or locally on their > > machine), > > they can redirect traffic to this domain to their servers on the Internet. > > And > > since the certificate is trusted by the browsers, they wouldn't be able to > > tell something was wrong. > > > > So PLEASE reanalyse your solution. You MUST NOT ship the private key with > > your > > application. That key must be generated on the user's machine. > > > > -- > > Thiago Macieira - thiago.macieira (AT) intel.com > > Software Architect - Intel DPG Cloud Engineering > > > > > > > > ___ > > Interest mailing list > > Interest@qt-project.org > > https://lists.qt-project.org/listinfo/interest > > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] wss:// on localhost
> I don't think this is a good idea. You might be violating the terms of > service > of your certificate provider by doing that. Please check with them. In fact I already did - nobody has a concern about it. This traffic is completey running on localhost - so nobody apart from the user itself is affected. This approach simply shall satisfy the browser to launch the localhost websocket. Best Alex -- http://www.carot.de Email : alexan...@carot.de Tel.: +49 (0)177 5719797 > Gesendet: Sonntag, 02. August 2020 um 19:24 Uhr > Von: "Thiago Macieira" > An: interest@qt-project.org > Betreff: Re: [Interest] wss:// on localhost > > On Friday, 31 July 2020 23:53:08 PDT Alexander Carôt wrote: > > Eventually we figured the ideal solution: > > > > We ordered a certificate for a sub-domain of our main domain and made the > > DNS point to localhost. > > > > This way we can address our localhost connection via > > > > localhost.ourDomain.net > > > > This works perfectly without any user interaction - thanks a lot to all of > > you for you inspiration ! > > > > Of course now I have to deal with the tiny details which I will raise in > > another email in a bit :-) > > I don't think this is a good idea. You might be violating the terms of > service > of your certificate provider by doing that. Please check with them. > > I can see a big attack vector with the information you provided. Since this > certificate's private key is distributed with your application, anyone who > has > this application can extract the private key and create a web service > impersonating this domain name. If they can compromise DNS at any level > leading to the user (your server, the user's ISP or locally on their > machine), > they can redirect traffic to this domain to their servers on the Internet. > And > since the certificate is trusted by the browsers, they wouldn't be able to > tell something was wrong. > > So PLEASE reanalyse your solution. You MUST NOT ship the private key with > your > application. That key must be generated on the user's machine. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel DPG Cloud Engineering > > > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Win:TLS error/OSX:backward compatibility
> That warning is printed when you try to use one of the QSslSocket functions > that require OpenSSL and the OpenSSL libraries are not found. > > Make sure QSslSocket::supportSsl() returns true. You have to ship the OpenSSL > 1.1 libraries yourself, they are not part of Qt, not even of the pre-built > binaries. Allright - will do so. > > 2.) In order to provide backward compatibility on OSX I am typically > > providing two versions: 10.15 and 10.14 are being compiled with the recent > > version of Qt. This binary launches with 10.13 but throws an errors about > > missing symbols in libSystem.B.dylib > > Are you sure you built Qt with a minimum target version of 10.13? My pro-File contains: QMAKE_MAC_SDK = macosx10.15 QMAKE_CFLAGS_RELEASE = "-mmacosx-version-min=10.13" QMAKE_CXXFLAGS_RELEASE = "-mmacosx-version-min=10.13" > Qt 5.9 cannot do SSL/TLS in 2020 outside of a Mac. You must upgrade to 5.10 > at > a minimum. On a Mac, because Qt has used SecureTransport for years, it can > work. But it could have issues I am not aware of. OK - thanks for sharing this info ! > Either way, Apple stopped supporting 10.12 last year. So - I believe I should use 10.13 as the lowest supported version. > > Can anyone send me hint how to provide backward compatibility at least to > > 10.13 (fixing the symbol issue) or lower (fixing the SSL issue) ? > > You didn't say what symbols they were. Sorry - this is the one which was reported most of the time: __chkstd_darwin There might be others but this would be a good starting point. Best Alex > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel DPG Cloud Engineering > > > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > -- http://www.carot.de Email : alexan...@carot.de Tel.: +49 (0)177 5719797 > Gesendet: Sonntag, 02. August 2020 um 19:31 Uhr > Von: "Thiago Macieira" > An: interest@qt-project.org > Betreff: Re: [Interest] Win:TLS error/OSX:backward compatibility > > On Saturday, 1 August 2020 00:13:21 PDT Alexander Carôt wrote: > > Hello all, > > > > my software's websocket server is now running in secure mode including > > certificate integration. This works great apart from two details. > > > > 1.) On some Windows machines I get the following error: > > > > qt.network.ssl: QSslSocket::startServerEncryption: TLS initialization failed > > > > I believe there are some missing libs on these machine but I am not sure how > > to resolve this issue conveniently. > > That warning is printed when you try to use one of the QSslSocket functions > that require OpenSSL and the OpenSSL libraries are not found. > > Make sure QSslSocket::supportSsl() returns true. You have to ship the OpenSSL > 1.1 libraries yourself, they are not part of Qt, not even of the pre-built > binaries. > > > 2.) In order to provide backward compatibility on OSX I am typically > > providing two versions: 10.15 and 10.14 are being compiled with the recent > > version of Qt. This binary launches with 10.13 but throws an errors about > > missing symbols in libSystem.B.dylib > > Are you sure you built Qt with a minimum target version of 10.13? > > > For 10.12 and lower I am compiling my app with Qt version 5.9 which works a > > usual but the new encryption calls obviously don't. With this version the > > SSL handshake between browser and app fails. > > Qt 5.9 cannot do SSL/TLS in 2020 outside of a Mac. You must upgrade to 5.10 > at > a minimum. On a Mac, because Qt has used SecureTransport for years, it can > work. But it could have issues I am not aware of. > > Either way, Apple stopped supporting 10.12 last year. > > > Can anyone send me hint how to provide backward compatibility at least to > > 10.13 (fixing the symbol issue) or lower (fixing the SSL issue) ? > > You didn't say what symbols they were. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel DPG Cloud Engineering > > > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] wss:// on localhost
On Friday, 31 July 2020 23:53:08 PDT Alexander Carôt wrote: > Eventually we figured the ideal solution: > > We ordered a certificate for a sub-domain of our main domain and made the > DNS point to localhost. > > This way we can address our localhost connection via > > localhost.ourDomain.net > > This works perfectly without any user interaction - thanks a lot to all of > you for you inspiration ! > > Of course now I have to deal with the tiny details which I will raise in > another email in a bit :-) I don't think this is a good idea. You might be violating the terms of service of your certificate provider by doing that. Please check with them. I can see a big attack vector with the information you provided. Since this certificate's private key is distributed with your application, anyone who has this application can extract the private key and create a web service impersonating this domain name. If they can compromise DNS at any level leading to the user (your server, the user's ISP or locally on their machine), they can redirect traffic to this domain to their servers on the Internet. And since the certificate is trusted by the browsers, they wouldn't be able to tell something was wrong. So PLEASE reanalyse your solution. You MUST NOT ship the private key with your application. That key must be generated on the user's machine. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Win:TLS error/OSX:backward compatibility
On Saturday, 1 August 2020 00:13:21 PDT Alexander Carôt wrote: > Hello all, > > my software's websocket server is now running in secure mode including > certificate integration. This works great apart from two details. > > 1.) On some Windows machines I get the following error: > > qt.network.ssl: QSslSocket::startServerEncryption: TLS initialization failed > > I believe there are some missing libs on these machine but I am not sure how > to resolve this issue conveniently. That warning is printed when you try to use one of the QSslSocket functions that require OpenSSL and the OpenSSL libraries are not found. Make sure QSslSocket::supportSsl() returns true. You have to ship the OpenSSL 1.1 libraries yourself, they are not part of Qt, not even of the pre-built binaries. > 2.) In order to provide backward compatibility on OSX I am typically > providing two versions: 10.15 and 10.14 are being compiled with the recent > version of Qt. This binary launches with 10.13 but throws an errors about > missing symbols in libSystem.B.dylib Are you sure you built Qt with a minimum target version of 10.13? > For 10.12 and lower I am compiling my app with Qt version 5.9 which works a > usual but the new encryption calls obviously don't. With this version the > SSL handshake between browser and app fails. Qt 5.9 cannot do SSL/TLS in 2020 outside of a Mac. You must upgrade to 5.10 at a minimum. On a Mac, because Qt has used SecureTransport for years, it can work. But it could have issues I am not aware of. Either way, Apple stopped supporting 10.12 last year. > Can anyone send me hint how to provide backward compatibility at least to > 10.13 (fixing the symbol issue) or lower (fixing the SSL issue) ? You didn't say what symbols they were. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] wss:// on localhost
On Saturday, 1 August 2020 08:00:29 PDT Jason H wrote: > IANAL, and this dives into legal issues, but if the creature function took a > path to a binary, and some options (assuming openssl options?) and allow > the developer/user to specify the binary, I think the legal issues would be > avoided. If the user wanted to use some other mechanism, they would just > provide a script as the binary and map the openssl options to the custom > binary. What's the point of providing a function that simply uses QProcess to run a script? Just use QProcess to run that script. Script left as an exercise to the reader. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
