Author: janpio Date: Fri Aug 7 08:42:34 2020 New Revision: 1880664 URL: http://svn.apache.org/viewvc?rev=1880664&view=rev Log: Updated docs
Modified: cordova/site/public/docs/en/dev/guide/appdev/security/index.html cordova/site/public/feed.xml Modified: cordova/site/public/docs/en/dev/guide/appdev/security/index.html URL: http://svn.apache.org/viewvc/cordova/site/public/docs/en/dev/guide/appdev/security/index.html?rev=1880664&r1=1880663&r2=1880664&view=diff ============================================================================== --- cordova/site/public/docs/en/dev/guide/appdev/security/index.html (original) +++ cordova/site/public/docs/en/dev/guide/appdev/security/index.html Fri Aug 7 08:42:34 2020 @@ -2572,11 +2572,21 @@ <p>There are also plugins that can do true certificate pinning for some platforms, assuming your app is able to do all of its network requests using the plugin (i.e.: no traditional XHR/AJAX requests, etc).</p> +<h2>Using TLS/SSL</h2> + +<p>If your app communicates to an external server, it should be communicating using modern encryption standards. Use <code>https</code> protocol whenever possible.</p> + +<p><a href="https://letsencrypt.org/">Let's Encrypt</a> is a free, automated, and open certificate authority provided by the nonprofit <a href="https://www.abetterinternet.org/">Internet Security Research Group</a>. Let's Encrypt will offer free standard certificates, which will be sufficient for most developers. Enterprise organizations may still want to use a traditional certificate authority that offers more advanced features such as <a href="https://en.wikipedia.org/wiki/Public_key_certificate#Organization_validation">Organization Validation</a> certificates.</p> + +<p>It is also important to keep up to date with security standards as they change over time. What might be acceptable SSL/TLS configuration today may not be acceptable years in the future. Using tools to test your certificate and SSL/TLS configuration should be done regularly. <a href="https://www.ssllabs.com/ssltest/">SSL Labs</a> is a free online service provided by Qualys, Inc to test your server's SSL/TLS configuration and encryption strength, in addition to supported platforms.</p> + <h2>Self-signed Certificates</h2> <p>Using self-signed certificates on your server is not recommended. If you desire SSL, then it is highly recommended that your server have a certificate that has been properly signed by a well-known CA (certificate authority). The inability to do true certificate pinning makes this important.</p> -<p>The reason is that accepting self-signed certificates bypasses the certificate chain validation, which allows any server certificate to be considered valid by the device. This opens up the communication to man-in-the-middle attacks. It becomes very easy for a hacker to not only intercept and read all communication between the device and the server, but also to modify the communication. The device will never know this is happening because it doesn't verify that the server's certificate is signed by a trusted CA. The device has no proof that the server is who it expects. Because of the ease of doing a man-in-the-middle attack, accepting self-signed certificates is only marginally better than just running http instead of https on an untrusted network. Yes, the traffic would be encrypted, but it could be encrypted with the key from a man-in-the-middle, so the man-in-the-middle can access everything, so encryption is useless except to passive observers. Users trust SSL to be s ecure, and this would be deliberately making it insecure, so the SSL use becomes misleading. If this will be used on a trusted network (i.e., you are entirely inside a controlled enterprise), then self-signed certs are still not recommended. The two recommendations in a trusted network are to just use http because the network itself is trusted, or to get a certificate signed by a trusted CA (not self-signed). Either the network is trusted or it is not.</p> +<p>The reason is that accepting self-signed certificates bypasses the certificate chain validation, which allows any server certificate to be considered valid by the device. This opens up the communication to man-in-the-middle attacks. It becomes very easy for a hacker to not only intercept and read all communication between the device and the server, but also to modify the communication. The device will never know this is happening because it doesn't verify that the server's certificate is signed by a trusted CA. The device has no proof that the server is who it expects. Because of the ease of doing a man-in-the-middle attack, accepting self-signed certificates is only marginally better than just running http instead of https on an untrusted network. Yes, the traffic would be encrypted, but it could be encrypted with the key from a man-in-the-middle, so the man-in-the-middle can access everything, so encryption is useless except to passive observers. Users trust SSL to be s ecure, and this would be deliberately making it insecure, so the SSL use becomes misleading.</p> + +<p>If the application is to be used only within a trusted network, such as an internal corporate network. Using self-signed certificates may be acceptable, however the public certificate should be pre-installed on the device(s) that will be running the application. A trusted third-party certificate authority will always be preferable.</p> <p>The principles described here are not specific to Apache Cordova, they apply to all client-server communication.</p> Modified: cordova/site/public/feed.xml URL: http://svn.apache.org/viewvc/cordova/site/public/feed.xml?rev=1880664&r1=1880663&r2=1880664&view=diff ============================================================================== --- cordova/site/public/feed.xml (original) +++ cordova/site/public/feed.xml Fri Aug 7 08:42:34 2020 @@ -6,8 +6,8 @@ </description> <link>https://cordova.apache.org/</link> <atom:link href="https://cordova.apache.org/feed.xml" rel="self" type="application/rss+xml"/> - <pubDate>Fri, 07 Aug 2020 07:27:15 +0000</pubDate> - <lastBuildDate>Fri, 07 Aug 2020 07:27:15 +0000</lastBuildDate> + <pubDate>Fri, 07 Aug 2020 08:21:08 +0000</pubDate> + <lastBuildDate>Fri, 07 Aug 2020 08:21:08 +0000</lastBuildDate> <generator>Jekyll v2.5.3</generator> <item> --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cordova.apache.org For additional commands, e-mail: commits-h...@cordova.apache.org