> but for now the localhost wss failed again. If you have another hint please > let me know - I won't give up ;-)
Eventually I succeeded with this tool: https://github.com/FiloSottile/mkcert After certificate generation and installation I was able connecting to localhost - very good ! Now I need to figure how to automize this process on any client's machine. Further inspiration appreciated - thanks for your help ! Best Alex -- http://www.carot.de Email : alexan...@carot.de Tel.: +49 (0)177 5719797 > Gesendet: Dienstag, 28. Juli 2020 um 08:05 Uhr > Von: "Alexander Carôt" <alexander_ca...@gmx.net> > An: "Mårten Nordheim" <marten.nordh...@qt.io> > Cc: "Thiago Macieira" <thiago.macie...@intel.com>, "Paul Pfützenreuter" > <paul.pfuetzenreu...@gmx.de>, "interest@qt-project.org" > <interest@qt-project.org> > Betreff: Re: [Interest] wss:// on localhost > > Hallo Marten, > > thanks for your additionl reply ! > > There are two reasons why I have to use a secure websocket: > > 1.) In some cases our website connects to our app not on localhost but some > other place on the LAN. > > 2.) Our site is part of a CMS-based project which per default runs with SSL. > Changing the specific sites to no-SSL (http) and the corresponding ws leades > to mixed content often ignored by the browser. > > In fact in our current workaroud we redirect to http and run a non-secure ws > but this fails for some browsers and especially in context with 1) it fails > completely - so I believe there is no other choice than using SSL-Websockets > and I am happy that theoretically there is a way to do achieve this is a > user-friendly way. However, I am still struggeling. So far this tutorial > looked promising: > > https://www.freecodecamp.org/news/how-to-get-https-working-on-your-local-development-environment-in-5-minutes-7af615770eec/ > > but for now the localhost wss failed again. If you have another hint please > let me know - I won't give up ;-) > > Best > > Alex > > > -- > http://www.carot.de > Email : alexan...@carot.de > Tel.: +49 (0)177 5719797 > > > > Gesendet: Montag, 27. Juli 2020 um 15:45 Uhr > > Von: "Mårten Nordheim" <marten.nordh...@qt.io> > > An: "Alexander Carôt" <alexander_ca...@gmx.net>, "Thiago Macieira" > > <thiago.macie...@intel.com> > > Cc: "Paul Pfützenreuter" <paul.pfuetzenreu...@gmx.de>, > > "interest@qt-project.org" <interest@qt-project.org> > > Betreff: Re: [Interest] wss:// on localhost > > > > Hello Alexander, > > > > I don't know (or recall) what your setup is like. The following answer > > assumes the website you refer to also runs on the local machine: > > > > Somewhat going in the other direction I'd say wss/https is not necessary if > > your application actually only listens to localhost (127.0.0.1/[::1]). > > It won't travel across the network at that point, and if the local machine > > is compromised encryption doesn't matter much. > > > > If you are listening to other addresses as well though (to let other > > clients in the network connect as well) then you need to generate > > certificates > > that includes the hostname or IP of the machine running the server since > > "localhost" is no longer enough/correct for that. > > > > However if the website is remote and you run attempt to connect to a > > websocket on the local machine then it needs to be encrypted and Thiago's > > suggestion will get you most of the way. You will also need to get the OS > > to trust the certificate for the browser to accept it as well. Usually with > > untrusted certificates browsers will show a warning and let you ignore it, > > but that doesn't happen in most browsers when opening a websocket > > connection in the background! > > > > Mårten > > > > ________________________________________ > > From: Interest <interest-boun...@qt-project.org> on behalf of Alexander > > Carôt <alexander_ca...@gmx.net> > > Sent: Tuesday, July 21, 2020 19:32 > > To: Thiago Macieira > > Cc: Paul Pfützenreuter; interest@qt-project.org > > Subject: Re: [Interest] wss:// on localhost > > > > Hej Thiago, > > > > > Whether they work or not is irrelevant, since you shouldn't be shipping > > > the > > > same certificate to all users. You'd have to make it extremely long-lived > > > (expiry 20 years from now). Generating a short-lived one (3 months) > > > limits the > > > damage if it somehow gets misused. > > > > > > just to avoid misunderstandings: The goal is not sending existing > > certificates as part of the application download but rather generate the > > certificte automatically upon launching the app ? > > > > > > > There are lots of examples on the Internet on how to do this with the > > > openssl > > > command. You'll have to find out how to do it with the API, if you don't > > > want > > > to ship the command. > > > > > > If my assumption above is right then any kind of automized process would be > > fine to me - e.g. running the openssl command as part of a script, which is > > executed before launching the application or probably generate the > > certificate within the app code which would be even more convenient. > > > > Is this somehow the right track or am I completely mistaken ? Sorry again - > > completely new in the domain of security ;-) > > > > Best > > > > Alex > > > > > > > > > > > > > > > > > > > > > 1) create a private/public key pair (usually RSA, but doesn't need to be). > > > Creating a private key usually involves random number, so please be sure > > > that > > > OpenSSL's random generator is properly seeded, if it can't be guaranteed > > > to > > > auto-seed. Qt's QRandomGenerator::system() is of cryptographic quality and > > > requires no seeding[*], so you can use it to generate random data to seed > > > OpenSSL if necessary. RSA key pairs are usually big these days (2048 to > > > 4096 > > > bits), so you may want to investigate an elliptic curve key instead, which > > > would reduce the computation time. > > > > > > 2) create a certificate-signing request (CSR), which contains the > > > certificate > > > header fields. Notably, it has the CN (Common Name) field, which > > > identifies > > > which hostnames it applies for. You want "localhost" > > > > > > 3) sign the CSR. You'll sign with the key used in #1, causing this to be > > > self- > > > signed. The result is the certificate. > > > > > > There are lots of examples on the Internet on how to do this with the > > > openssl > > > command. You'll have to find out how to do it with the API, if you don't > > > want > > > to ship the command. > > > > > > For anyone wondering about turning off the SSL error on self-signed > > > certificates: self-signing isn't inherently bad. The SSL error comes not > > > because the certificate is self-signed, but because it's not signed by any > > > certificate in the Certificate Authority list. The fact it's self-signed > > > is > > > simply extra information, as it's the most common cause of an authority > > > not > > > being found. But if you add the certificate itself to the CA list (in > > > fact, > > > make it the only entry!), then it'll match to a CA and you get no SSL > > > error. > > > > > > [*] this is also why René is having problems with the RDRAND instruction > > > in > > > the other thread. > > > -- > > > 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 > _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
