On Monday, April 13, 2015 at 4:57:58 PM UTC+2, Richard Barnes wrote: > In order to encourage web developers to move from HTTP to HTTPS, I would > like to propose establishing a deprecation plan for HTTP without security.
I think server side SSL certificates should be deprecated as a means to encrypt a connection. Ideally this is what should happen: 1. User downloads a browser (be it Firefox, Chrome, Opera, etc.) securely (https?) from the official download location. 2. Upon installation a private key is created for that browser installation and signed by the browser's certificate server. 3. When the user later connect to a server that support automatic encryption, the browser sends a (public) session key that the server should use, this key is signed with the browser installation key, the server can verify the signature and that this key is not modified by checking the certificate server. 4. The server exchanges it's session key with the browser. 5. A secure/encrypted connection is now possible. I know, not that well explained and over simplified. But the concept is hopefully clear, but in case it's not... This is today's server certificates system but in reverse. This concept does not replace https as it is today, but does allow "free" encrypted connections. Web designers, hosting companies etc only need to ensure their server software is up to date and are able to support this. The benefit is that there is no server side certificates needed to establish a encrypted connection. The browser/client installation certificate can easily be changed each time a browser is updated. And can be set to expire within a certain number of months. Not sure what to call this concept. "Reverse-HTTPS" maybe? RHTTPS for short? Traditional serverside certificates are still needed, especially the "green bar" ones. And free basic ones like StartSSL gives out are still of use, to allow old browsers to use HTTPS, and to support a fallback in case a browser certificate has expired (and still allow a secure connection). The issue today (even with free certificates like StartSSL gives out) is that webmasters ans hosting companies have to do a yearly dance to update the certificates. And not all hosting companies support HTTPS for all their packages. Sites that make some profit can probably afford to pay for the extra HTTPS feature and pay for a certificate. Myself I'm lucky in that my host provides free HTTPS support for the particular package I have (though not for the smallest package). My concept has a flaw though. Browser makers need to set up their own certificate server to sign the generated browser installation keys. And server software (Apache, nginx, etc.) need to support a type of RHTTPS so they can send a session key to the browser. The benefit though is that servers do not need a certificate installed to create a encrypted connection. Further security could be built on top of this where the server or client or both have authenticated certificate (so that there is not only a encrypted connection but also identified server and client) A concept like RHTTPS would allow a slow migration with no direct need for webmasters nor browser users to change anything themselves, with zero cost to webmasters/hosters nor the end users. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
