Re: [QGIS-Developer] SSL Performance Overhead
This has been covered a few times on StackOverflow. https://stackoverflow.com/questions/548029/how-much-overhead-does-ssl-impose https://stackoverflow.com/questions/149274/http-vs-https-performance Basically, the expensive part is creating the connection (handshaking). After that, when using the connection the overhead should be minimal. Given this I'd suggest the obvious starting point for investigating is to confirm it's not recreating the connection over-and-over. Because it's a database connection it's unlikely there's a slow-down due to a lack of caching. Cheers, Jonathan On 18/06/2019 13:28, Bo Victor Thomsen wrote: Has anyone tried to ascertain how big the overhead is when using SSL - and why ? Regards Bo Victor Thomsen AestasGIS Denamrk Den 18-06-2019 kl. 14:15 skrev Stefan Steiger: Uh, ah, yea, also, sending a password for a DB-user over the intranet-network in plain text is rather bad. While the data retrieved from the DB might not be confidential, maybe there is confidential data in the db. Also, the login used could have permissions onto another DB that has confidential data inside. In my opinion, the default should be SSL, including in intranet. If anybody changes the default for performance reasons, they can, and correspondingly, the blame will be theirs if anything happens. Nowadays, we use SSL even in development. Just my 0.05 $ -Ursprüngliche Nachricht- Von: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] Im Auftrag von Bernhard Ströbl Gesendet: Montag, 17. Juni 2019 15:31 An: qgis-developer@lists.osgeo.org Betreff: Re: [QGIS-Developer] SSL Performance Overhead Hi all, I have to add that we use SSL to encrypt the user credentials as we use LDAP to authentificate users at the database. So SSL is not only relevant looking at data stored in the database. Bernhard Am 17.06.2019 um 13:56 schrieb Andreas Neumann: Hi Stefan, Yes, sure. If I were a bank or the national bank I would also mandate use of SSL. Also, when personal data is involved. But many gov authorities have primarily publically available geoinformation (object data, no personal data) in their DBs and no sensitive data. We are just discussing the defaults, anyone can enable SSL if it is useful or required in their usage scenario. Andreas On 2019-06-17 13:20, Stefan Steiger wrote: One of our customers (Swiss National Bank) mandates the use of SSL in their internal LAN, even for DB connections. Using anything but SSL is an insecure mode of communication, even in LAN. RSA/DSA Accepted key-length is 2048 bit, recommended is 3072, ECC is 160 Bit, recommended 256. -Only latest version of OpenSSL allowed -Accepted TLS 1.1+, recommended TLS 1.2+ -SSL Version 3.0 or older are explicitly forbidden -Sha-1 is disallowed, sha2/3 accepted @ hash length 256 Bit -Extended Validation certificates have to be used -Wildcards in fully qualified names not allowed -Accepted: CTR/CBC/CCM/EAX, recommended GCM -SSL accepted with forward secrecy Disabled, recommended Enabled -Recommended CryptRandom: /dev/random, /dev/urandom, as per IT Security Baseline 2017-07-20 *Von:*QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] *Im Auftrag von *Andreas Neumann *Gesendet:* Montag, 17. Juni 2019 09:05 *An:* Matthias Kuhn *Cc:* qgis-developer@lists.osgeo.org *Betreff:* Re: [QGIS-Developer] SSL Performance Overhead Hi, I would say, that the use of SSL should be encouraged if the connection goes through public networks. If the Postgis connection is within the company LAN I don't see a strong reason for enabling SSL, unless the company LAN is designed in an "unsafe" way, or if sensitive data must be hidden from other employees in the same company. Personally, I never had good results (performance wise) if Postgis connections went through the public Internet, unless it is some "toy data". For this reason, I usually used streaming replication to replicate Postgis, so it is as close as possible to the users who need the data. The streaming replication, if it goes through the public internet, of course should use SSL (or often it goes through an SSH tunnel). Sorry, I don't have any data on the overhead of SSL connections though. Andreas On 2019-06-17 08:48, Matthias Kuhn wrote: Hi, The documentation currently promises "massive speed-ups in PostGIS layer rendering" with SSL disabled. [1 <https://docs.qgis.org/2.18/en/docs/user_manual/managing_data_source/ opening_data.html#creating-a-stored-connection>] I find some references to performance cost of SSL but they should be compensated for with connection pooling which we use for quite some time already. Recently, the web is more and more encrypted - and that is very good! - so I think we should also start to encourage people to encrypt their SSL connections. Or at least certainly not discourage them
Re: [QGIS-Developer] SSL Performance Overhead
Has anyone tried to ascertain how big the overhead is when using SSL - and why ? Regards Bo Victor Thomsen AestasGIS Denamrk Den 18-06-2019 kl. 14:15 skrev Stefan Steiger: Uh, ah, yea, also, sending a password for a DB-user over the intranet-network in plain text is rather bad. While the data retrieved from the DB might not be confidential, maybe there is confidential data in the db. Also, the login used could have permissions onto another DB that has confidential data inside. In my opinion, the default should be SSL, including in intranet. If anybody changes the default for performance reasons, they can, and correspondingly, the blame will be theirs if anything happens. Nowadays, we use SSL even in development. Just my 0.05 $ -Ursprüngliche Nachricht- Von: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] Im Auftrag von Bernhard Ströbl Gesendet: Montag, 17. Juni 2019 15:31 An: qgis-developer@lists.osgeo.org Betreff: Re: [QGIS-Developer] SSL Performance Overhead Hi all, I have to add that we use SSL to encrypt the user credentials as we use LDAP to authentificate users at the database. So SSL is not only relevant looking at data stored in the database. Bernhard Am 17.06.2019 um 13:56 schrieb Andreas Neumann: Hi Stefan, Yes, sure. If I were a bank or the national bank I would also mandate use of SSL. Also, when personal data is involved. But many gov authorities have primarily publically available geoinformation (object data, no personal data) in their DBs and no sensitive data. We are just discussing the defaults, anyone can enable SSL if it is useful or required in their usage scenario. Andreas On 2019-06-17 13:20, Stefan Steiger wrote: One of our customers (Swiss National Bank) mandates the use of SSL in their internal LAN, even for DB connections. Using anything but SSL is an insecure mode of communication, even in LAN. RSA/DSA Accepted key-length is 2048 bit, recommended is 3072, ECC is 160 Bit, recommended 256. -Only latest version of OpenSSL allowed -Accepted TLS 1.1+, recommended TLS 1.2+ -SSL Version 3.0 or older are explicitly forbidden -Sha-1 is disallowed, sha2/3 accepted @ hash length 256 Bit -Extended Validation certificates have to be used -Wildcards in fully qualified names not allowed -Accepted: CTR/CBC/CCM/EAX, recommended GCM -SSL accepted with forward secrecy Disabled, recommended Enabled -Recommended CryptRandom: /dev/random, /dev/urandom, as per IT Security Baseline 2017-07-20 *Von:*QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] *Im Auftrag von *Andreas Neumann *Gesendet:* Montag, 17. Juni 2019 09:05 *An:* Matthias Kuhn *Cc:* qgis-developer@lists.osgeo.org *Betreff:* Re: [QGIS-Developer] SSL Performance Overhead Hi, I would say, that the use of SSL should be encouraged if the connection goes through public networks. If the Postgis connection is within the company LAN I don't see a strong reason for enabling SSL, unless the company LAN is designed in an "unsafe" way, or if sensitive data must be hidden from other employees in the same company. Personally, I never had good results (performance wise) if Postgis connections went through the public Internet, unless it is some "toy data". For this reason, I usually used streaming replication to replicate Postgis, so it is as close as possible to the users who need the data. The streaming replication, if it goes through the public internet, of course should use SSL (or often it goes through an SSH tunnel). Sorry, I don't have any data on the overhead of SSL connections though. Andreas On 2019-06-17 08:48, Matthias Kuhn wrote: Hi, The documentation currently promises "massive speed-ups in PostGIS layer rendering" with SSL disabled. [1 <https://docs.qgis.org/2.18/en/docs/user_manual/managing_data_source/ opening_data.html#creating-a-stored-connection>] I find some references to performance cost of SSL but they should be compensated for with connection pooling which we use for quite some time already. Recently, the web is more and more encrypted - and that is very good! - so I think we should also start to encourage people to encrypt their SSL connections. Or at least certainly not discourage them from using encryption by promising performance benefits. Is there anyone who knows why this sentence was introduced? And if there is (still) an issue with performance when using SSL? Best regards Matthias [1] https://docs.qgis.org/2.18/en/docs/user_manual/managing_data_source/opening_data.html#creating-a-stored-connection <https://docs.qgis.org/2.18/en/docs/user_manual/managing_data_source/ opening_data.html#creating-a-stored-connection> [2] https://github.com/qgis/QGIS-Documentation/pull/3840 ___ QGIS-Developer mailing list QGIS-Developer@li
Re: [QGIS-Developer] SSL Performance Overhead
Uh, ah, yea, also, sending a password for a DB-user over the intranet-network in plain text is rather bad. While the data retrieved from the DB might not be confidential, maybe there is confidential data in the db. Also, the login used could have permissions onto another DB that has confidential data inside. In my opinion, the default should be SSL, including in intranet. If anybody changes the default for performance reasons, they can, and correspondingly, the blame will be theirs if anything happens. Nowadays, we use SSL even in development. Just my 0.05 $ -Ursprüngliche Nachricht- Von: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] Im Auftrag von Bernhard Ströbl Gesendet: Montag, 17. Juni 2019 15:31 An: qgis-developer@lists.osgeo.org Betreff: Re: [QGIS-Developer] SSL Performance Overhead Hi all, I have to add that we use SSL to encrypt the user credentials as we use LDAP to authentificate users at the database. So SSL is not only relevant looking at data stored in the database. Bernhard Am 17.06.2019 um 13:56 schrieb Andreas Neumann: > Hi Stefan, > > Yes, sure. If I were a bank or the national bank I would also mandate > use of SSL. Also, when personal data is involved. But many gov > authorities have primarily publically available geoinformation (object > data, no personal data) in their DBs and no sensitive data. > > We are just discussing the defaults, anyone can enable SSL if it is > useful or required in their usage scenario. > > Andreas > > On 2019-06-17 13:20, Stefan Steiger wrote: > >> One of our customers (Swiss National Bank) mandates the use of SSL in >> their internal LAN, even for DB connections. >> >> Using anything but SSL is an insecure mode of communication, even in LAN. >> >> RSA/DSA Accepted key-length is 2048 bit, recommended is 3072, ECC is >> 160 Bit, recommended 256. >> >> -Only latest version of OpenSSL allowed >> >> -Accepted TLS 1.1+, recommended TLS 1.2+ >> >> -SSL Version 3.0 or older are explicitly forbidden >> >> -Sha-1 is disallowed, sha2/3 accepted @ hash length 256 Bit >> >> -Extended Validation certificates have to be used >> >> -Wildcards in fully qualified names not allowed >> >> -Accepted: CTR/CBC/CCM/EAX, recommended GCM >> >> -SSL accepted with forward secrecy Disabled, recommended Enabled >> >> -Recommended CryptRandom: /dev/random, /dev/urandom, >> >> as per IT Security Baseline 2017-07-20 >> >> *Von:*QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] >> *Im Auftrag von *Andreas Neumann >> *Gesendet:* Montag, 17. Juni 2019 09:05 >> *An:* Matthias Kuhn >> *Cc:* qgis-developer@lists.osgeo.org >> *Betreff:* Re: [QGIS-Developer] SSL Performance Overhead >> >> Hi, >> >> I would say, that the use of SSL should be encouraged if the >> connection goes through public networks. If the Postgis connection is >> within the company LAN I don't see a strong reason for enabling SSL, >> unless the company LAN is designed in an "unsafe" way, or if >> sensitive data must be hidden from other employees in the same company. >> >> Personally, I never had good results (performance wise) if Postgis >> connections went through the public Internet, unless it is some "toy >> data". >> >> For this reason, I usually used streaming replication to replicate >> Postgis, so it is as close as possible to the users who need the data. >> The streaming replication, if it goes through the public internet, of >> course should use SSL (or often it goes through an SSH tunnel). >> >> Sorry, I don't have any data on the overhead of SSL connections though. >> >> Andreas >> >> On 2019-06-17 08:48, Matthias Kuhn wrote: >> >> Hi, >> >> The documentation currently promises "massive speed-ups in PostGIS >> layer rendering" with SSL disabled. [1 >> >> <https://docs.qgis.org/2.18/en/docs/user_manual/managing_data_source/ >> opening_data.html#creating-a-stored-connection>] >> >> I find some references to performance cost of SSL but they should >> be compensated for with connection pooling which we use for quite >> some time already. >> >> Recently, the web is more and more encrypted - and that is very >> good! - so I think we should also start to encourage people to >> encrypt their SSL connections. Or at least certainly not >> discourage them from using encryption by promising performance >> benefits. >> >> Is there anyone who knows why thi
Re: [QGIS-Developer] SSL Performance Overhead
Hi all, I have to add that we use SSL to encrypt the user credentials as we use LDAP to authentificate users at the database. So SSL is not only relevant looking at data stored in the database. Bernhard Am 17.06.2019 um 13:56 schrieb Andreas Neumann: Hi Stefan, Yes, sure. If I were a bank or the national bank I would also mandate use of SSL. Also, when personal data is involved. But many gov authorities have primarily publically available geoinformation (object data, no personal data) in their DBs and no sensitive data. We are just discussing the defaults, anyone can enable SSL if it is useful or required in their usage scenario. Andreas On 2019-06-17 13:20, Stefan Steiger wrote: One of our customers (Swiss National Bank) mandates the use of SSL in their internal LAN, even for DB connections. Using anything but SSL is an insecure mode of communication, even in LAN. RSA/DSA Accepted key-length is 2048 bit, recommended is 3072, ECC is 160 Bit, recommended 256. -Only latest version of OpenSSL allowed -Accepted TLS 1.1+, recommended TLS 1.2+ -SSL Version 3.0 or older are explicitly forbidden -Sha-1 is disallowed, sha2/3 accepted @ hash length 256 Bit -Extended Validation certificates have to be used -Wildcards in fully qualified names not allowed -Accepted: CTR/CBC/CCM/EAX, recommended GCM -SSL accepted with forward secrecy Disabled, recommended Enabled -Recommended CryptRandom: /dev/random, /dev/urandom, as per IT Security Baseline 2017-07-20 *Von:*QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] *Im Auftrag von *Andreas Neumann *Gesendet:* Montag, 17. Juni 2019 09:05 *An:* Matthias Kuhn *Cc:* qgis-developer@lists.osgeo.org *Betreff:* Re: [QGIS-Developer] SSL Performance Overhead Hi, I would say, that the use of SSL should be encouraged if the connection goes through public networks. If the Postgis connection is within the company LAN I don't see a strong reason for enabling SSL, unless the company LAN is designed in an "unsafe" way, or if sensitive data must be hidden from other employees in the same company. Personally, I never had good results (performance wise) if Postgis connections went through the public Internet, unless it is some "toy data". For this reason, I usually used streaming replication to replicate Postgis, so it is as close as possible to the users who need the data. The streaming replication, if it goes through the public internet, of course should use SSL (or often it goes through an SSH tunnel). Sorry, I don't have any data on the overhead of SSL connections though. Andreas On 2019-06-17 08:48, Matthias Kuhn wrote: Hi, The documentation currently promises "massive speed-ups in PostGIS layer rendering" with SSL disabled. [1 <https://docs.qgis.org/2.18/en/docs/user_manual/managing_data_source/opening_data.html#creating-a-stored-connection>] I find some references to performance cost of SSL but they should be compensated for with connection pooling which we use for quite some time already. Recently, the web is more and more encrypted - and that is very good! - so I think we should also start to encourage people to encrypt their SSL connections. Or at least certainly not discourage them from using encryption by promising performance benefits. Is there anyone who knows why this sentence was introduced? And if there is (still) an issue with performance when using SSL? Best regards Matthias [1] https://docs.qgis.org/2.18/en/docs/user_manual/managing_data_source/opening_data.html#creating-a-stored-connection <https://docs.qgis.org/2.18/en/docs/user_manual/managing_data_source/opening_data.html#creating-a-stored-connection> [2] https://github.com/qgis/QGIS-Documentation/pull/3840 ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org <mailto:QGIS-Developer@lists.osgeo.org> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer __ Information from ESET Mail Security, version of virus signature database 19536 (20190617) __ The message was checked by ESET Mail Security. http://www.eset.com ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer __ Information from ESET Mail Security, version of virus signature database 19537 (20190617) __ The message was checked by ESET Mail Security. http://www.eset.com ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] SSL Performance Overhead
Hi Stefan, Yes, sure. If I were a bank or the national bank I would also mandate use of SSL. Also, when personal data is involved. But many gov authorities have primarily publically available geoinformation (object data, no personal data) in their DBs and no sensitive data. We are just discussing the defaults, anyone can enable SSL if it is useful or required in their usage scenario. Andreas On 2019-06-17 13:20, Stefan Steiger wrote: One of our customers (Swiss National Bank) mandates the use of SSL in their internal LAN, even for DB connections. Using anything but SSL is an insecure mode of communication, even in LAN. RSA/DSA Accepted key-length is 2048 bit, recommended is 3072, ECC is 160 Bit, recommended 256. - Only latest version of OpenSSL allowed - Accepted TLS 1.1+, recommended TLS 1.2+ - SSL Version 3.0 or older are explicitly forbidden - Sha-1 is disallowed, sha2/3 accepted @ hash length 256 Bit - Extended Validation certificates have to be used - Wildcards in fully qualified names not allowed - Accepted: CTR/CBC/CCM/EAX, recommended GCM - SSL accepted with forward secrecy Disabled, recommended Enabled - Recommended CryptRandom: /dev/random, /dev/urandom, as per IT Security Baseline 2017-07-20 VON: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] IM AUFTRAG VON Andreas Neumann GESENDET: Montag, 17. Juni 2019 09:05 AN: Matthias Kuhn CC: qgis-developer@lists.osgeo.org BETREFF: Re: [QGIS-Developer] SSL Performance Overhead Hi, I would say, that the use of SSL should be encouraged if the connection goes through public networks. If the Postgis connection is within the company LAN I don't see a strong reason for enabling SSL, unless the company LAN is designed in an "unsafe" way, or if sensitive data must be hidden from other employees in the same company. Personally, I never had good results (performance wise) if Postgis connections went through the public Internet, unless it is some "toy data". For this reason, I usually used streaming replication to replicate Postgis, so it is as close as possible to the users who need the data. The streaming replication, if it goes through the public internet, of course should use SSL (or often it goes through an SSH tunnel). Sorry, I don't have any data on the overhead of SSL connections though. Andreas On 2019-06-17 08:48, Matthias Kuhn wrote: Hi, The documentation currently promises "massive speed-ups in PostGIS layer rendering" with SSL disabled. [1 [1]] I find some references to performance cost of SSL but they should be compensated for with connection pooling which we use for quite some time already. Recently, the web is more and more encrypted - and that is very good! - so I think we should also start to encourage people to encrypt their SSL connections. Or at least certainly not discourage them from using encryption by promising performance benefits. Is there anyone who knows why this sentence was introduced? And if there is (still) an issue with performance when using SSL? Best regards Matthias [1] https://docs.qgis.org/2.18/en/docs/user_manual/managing_data_source/opening_data.html#creating-a-stored-connection [1] [2] https://github.com/qgis/QGIS-Documentation/pull/3840 ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer Links: -- [1] https://docs.qgis.org/2.18/en/docs/user_manual/managing_data_source/opening_data.html#creating-a-stored-connection___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] SSL Performance Overhead
One of our customers (Swiss National Bank) mandates the use of SSL in their internal LAN, even for DB connections. Using anything but SSL is an insecure mode of communication, even in LAN. RSA/DSA Accepted key-length is 2048 bit, recommended is 3072, ECC is 160 Bit, recommended 256. - Only latest version of OpenSSL allowed - Accepted TLS 1.1+, recommended TLS 1.2+ - SSL Version 3.0 or older are explicitly forbidden - Sha-1 is disallowed, sha2/3 accepted @ hash length 256 Bit - Extended Validation certificates have to be used - Wildcards in fully qualified names not allowed - Accepted: CTR/CBC/CCM/EAX, recommended GCM - SSL accepted with forward secrecy Disabled, recommended Enabled - Recommended CryptRandom: /dev/random, /dev/urandom, as per IT Security Baseline 2017-07-20 Von: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] Im Auftrag von Andreas Neumann Gesendet: Montag, 17. Juni 2019 09:05 An: Matthias Kuhn Cc: qgis-developer@lists.osgeo.org Betreff: Re: [QGIS-Developer] SSL Performance Overhead Hi, I would say, that the use of SSL should be encouraged if the connection goes through public networks. If the Postgis connection is within the company LAN I don't see a strong reason for enabling SSL, unless the company LAN is designed in an "unsafe" way, or if sensitive data must be hidden from other employees in the same company. Personally, I never had good results (performance wise) if Postgis connections went through the public Internet, unless it is some "toy data". For this reason, I usually used streaming replication to replicate Postgis, so it is as close as possible to the users who need the data. The streaming replication, if it goes through the public internet, of course should use SSL (or often it goes through an SSH tunnel). Sorry, I don't have any data on the overhead of SSL connections though. Andreas On 2019-06-17 08:48, Matthias Kuhn wrote: Hi, The documentation currently promises "massive speed-ups in PostGIS layer rendering" with SSL disabled. [1<https://docs.qgis.org/2.18/en/docs/user_manual/managing_data_source/opening_data.html#creating-a-stored-connection>] I find some references to performance cost of SSL but they should be compensated for with connection pooling which we use for quite some time already. Recently, the web is more and more encrypted - and that is very good! - so I think we should also start to encourage people to encrypt their SSL connections. Or at least certainly not discourage them from using encryption by promising performance benefits. Is there anyone who knows why this sentence was introduced? And if there is (still) an issue with performance when using SSL? Best regards Matthias [1] https://docs.qgis.org/2.18/en/docs/user_manual/managing_data_source/opening_data.html#creating-a-stored-connection [2] https://github.com/qgis/QGIS-Documentation/pull/3840 ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org<mailto:QGIS-Developer@lists.osgeo.org> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] SSL Performance Overhead
On Mon, Jun 17, 2019 at 1:03 PM Andrea Aime wrote: > Hey all, > sorry to intrude, but I have a bit of related information. > GeoServer uses the same underlying stack as QGIS > Sorry not as QGIS, same as UDig! Cheers Andrea == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- *Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.* ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] SSL Performance Overhead
Hey all, sorry to intrude, but I have a bit of related information. GeoServer uses the same underlying stack as QGIS, at one point we noticed that the reading performance went down, upon investigation it turned out the JDBC driver started using SSL by default when available. So we added a flag to turn off SSL and it indeed helped performance (but not 10 times mind, maybe 20-30% on OSM like map like the one rendering at geoserver.org, did not try on simpler/smaller maps). This was a few months ago, not 10 years ago, so yes, SSL encrypt/decrypt is still indeed taking a toll. Cheers Andrea On Mon, Jun 17, 2019 at 12:46 PM Matthias Kuhn wrote: > On 6/17/19 12:16 PM, Martin Dobias wrote: > > On Mon, Jun 17, 2019 at 12:11 PM Matthias Kuhn > wrote: > >> Wouldn't connection pooling be such a change. That certainly was > >> introduced after. > > Pooling was introduced to deal with multi-threaded rendering and > > should not affect that. There always was a connection that was kept > > alive while layer(s) using that connection existed. > > Interesting. > > I still can't see any good explanation for the overhead detected 10 > years ago, do you have an idea what this could be caused by? > > I just can't imagine that an enterprise level database like postgres > would suffer from such an issue on the security side. > > Cheers Matthias > > ___ > QGIS-Developer mailing list > QGIS-Developer@lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -- Regards, Andrea Aime == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- *Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.* ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] SSL Performance Overhead
On 6/17/19 12:16 PM, Martin Dobias wrote: On Mon, Jun 17, 2019 at 12:11 PM Matthias Kuhn wrote: Wouldn't connection pooling be such a change. That certainly was introduced after. Pooling was introduced to deal with multi-threaded rendering and should not affect that. There always was a connection that was kept alive while layer(s) using that connection existed. Interesting. I still can't see any good explanation for the overhead detected 10 years ago, do you have an idea what this could be caused by? I just can't imagine that an enterprise level database like postgres would suffer from such an issue on the security side. Cheers Matthias ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] SSL Performance Overhead
On Mon, Jun 17, 2019 at 12:11 PM Matthias Kuhn wrote: > > Wouldn't connection pooling be such a change. That certainly was > introduced after. Pooling was introduced to deal with multi-threaded rendering and should not affect that. There always was a connection that was kept alive while layer(s) using that connection existed. Cheers Martin ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] SSL Performance Overhead
Wouldn't connection pooling be such a change. That certainly was introduced after. ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] SSL Performance Overhead
For the record, sending unencrypted data over a local network isn't safe as soon as WIFI is part of said local network. On Mon, Jun 17, 2019, 17:02 Martin Dobias wrote: > Hi Matthias > > On Mon, Jun 17, 2019 at 8:48 AM Matthias Kuhn wrote: > > > > The documentation currently promises "massive speed-ups in PostGIS layer > > rendering" with SSL disabled. [1] > > > > [...] > > > > Is there anyone who knows why this sentence was introduced? And if there > > is (still) an issue with performance when using SSL? > > As Jurgen has commented on the pull request already, we have figured > out that QGIS was taking a lot more time to access features from a > local PostgreSQL database compared to some other app (uDig?). I have > dug out an old mail with the measurement - the difference was ~12 > seconds to fetch data in QGIS vs ~4 seconds to fetch data in the other > app. In the end we figured out that disabling encryption removed that > penalization. All that was back in 2009 :-) > > Unless there have been some improvements in the server/client lib, I > think the promise of massive speed up is still valid... And as Andreas > mentions, most(?) of the time people use the DB on a local network, so > it should not be a big deal to send data on local network unencrypted. > > Cheers > Martin > ___ > QGIS-Developer mailing list > QGIS-Developer@lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] SSL Performance Overhead
Hi Matthias On Mon, Jun 17, 2019 at 8:48 AM Matthias Kuhn wrote: > > The documentation currently promises "massive speed-ups in PostGIS layer > rendering" with SSL disabled. [1] > > [...] > > Is there anyone who knows why this sentence was introduced? And if there > is (still) an issue with performance when using SSL? As Jurgen has commented on the pull request already, we have figured out that QGIS was taking a lot more time to access features from a local PostgreSQL database compared to some other app (uDig?). I have dug out an old mail with the measurement - the difference was ~12 seconds to fetch data in QGIS vs ~4 seconds to fetch data in the other app. In the end we figured out that disabling encryption removed that penalization. All that was back in 2009 :-) Unless there have been some improvements in the server/client lib, I think the promise of massive speed up is still valid... And as Andreas mentions, most(?) of the time people use the DB on a local network, so it should not be a big deal to send data on local network unencrypted. Cheers Martin ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] SSL Performance Overhead
Hi, I would say, that the use of SSL should be encouraged if the connection goes through public networks. If the Postgis connection is within the company LAN I don't see a strong reason for enabling SSL, unless the company LAN is designed in an "unsafe" way, or if sensitive data must be hidden from other employees in the same company. Personally, I never had good results (performance wise) if Postgis connections went through the public Internet, unless it is some "toy data". For this reason, I usually used streaming replication to replicate Postgis, so it is as close as possible to the users who need the data. The streaming replication, if it goes through the public internet, of course should use SSL (or often it goes through an SSH tunnel). Sorry, I don't have any data on the overhead of SSL connections though. Andreas On 2019-06-17 08:48, Matthias Kuhn wrote: Hi, The documentation currently promises "massive speed-ups in PostGIS layer rendering" with SSL disabled. [1 [1]] I find some references to performance cost of SSL but they should be compensated for with connection pooling which we use for quite some time already. Recently, the web is more and more encrypted - and that is very good! - so I think we should also start to encourage people to encrypt their SSL connections. Or at least certainly not discourage them from using encryption by promising performance benefits. Is there anyone who knows why this sentence was introduced? And if there is (still) an issue with performance when using SSL? Best regards Matthias [1] https://docs.qgis.org/2.18/en/docs/user_manual/managing_data_source/opening_data.html#creating-a-stored-connection [2] https://github.com/qgis/QGIS-Documentation/pull/3840 ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer Links: -- [1] https://docs.qgis.org/2.18/en/docs/user_manual/managing_data_source/opening_data.html#creating-a-stored-connection___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] SSL Performance Overhead
Hi, The documentation currently promises "massive speed-ups in PostGIS layer rendering" with SSL disabled. [1] I find some references to performance cost of SSL but they should be compensated for with connection pooling which we use for quite some time already. Recently, the web is more and more encrypted - and that is very good! - so I think we should also start to encourage people to encrypt their SSL connections. Or at least certainly not discourage them from using encryption by promising performance benefits. Is there anyone who knows why this sentence was introduced? And if there is (still) an issue with performance when using SSL? Best regards Matthias [1] https://docs.qgis.org/2.18/en/docs/user_manual/managing_data_source/opening_data.html#creating-a-stored-connection [2] https://github.com/qgis/QGIS-Documentation/pull/3840 ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
