Another attempt to split SSL into encryption and trust
From one perspective, ideally SSL would be split apart into encryption and trust, with the goal of letting you have encryption without trust. In theory you could achieve this with a different handling of https, but lately I have come to think that the user expectation problems of such a solution are insurmountable at this point; too many people just know what https in URLs means for its meaning to change (in a subtle way).
(My personal feeling is that it is pointless and even undesirable to go the other way and try to have trust without encryption.)
So, let's take as given an axiom: if it has
https: visible in the URL
it must have trust, not just encryption. Thus, however a split works,
the SSL encryption must appear to use a
http: URL as far as the user
thus servers could accept it on regular HTTP ports, the client browser
can't just blindly try it with strange web servers, since it would be
a protocol error (and make people unhappy when it showed up in their
(The client browser cannot just quietly try making an https request instead of an http one, because even if it exists there's no certainty that a server's https website supports the same URLs with the same meanings as the http website does.)
If we're willing to accept that the first HTTP request to a web server
won't be encrypted, we can have the server signal clients that it
supports direct SSL on the normal HTTP port by adding an appropriate
new HTTP header to its reply. Cooperative clients would then do SSL on
subsequent connections. (Clients that want all real requests to a new
web server to be encrypted if possible can try a small dummy request,
HEAD /', before their first real request.)
One downside of this is that it would probably have terrible effects on the effectiveness of any intermediate caching proxies, especially transparent ones (at least until the proxies were updated to understand the scheme and either strip out the header or implement the scheme).
(Properly implemented it should not malfunction in the presence of an uncooperative proxy; the client browser would try once to do 'SSL over HTTP', fail, and fall back to ordinary HTTP.)
Comments on this page:Written on 11 November 2008.