Richard Levitte - VMS Whacker <[EMAIL PROTECTED]> writes:
> From: Eric Rescorla <[EMAIL PROTECTED]>
>
> ekr> Not as far as I know. It was never really expected that this
> ekr> technique would replace HTTPs for web pages, only for other
> ekr> HTTP/TLS uses. (Though frankly I doubt that as well.)
>
> Uhmm, what exactly is the functional difference between HTTPS and
> HTTP/TLS? For me, they describe the function "running HTTP through a
> SSL or TLS encryption tunnel"...
Well, my usage is that HTTP/TLS is the generic term for any use
of HTTP over TLS. HTTPS refers to the traditional usage of
HTTP over SSL/TLS as described in RFC 2818. I use HTTP Upgrade to
refer to the protocol described in RFC 2817.
> I think the matter is of deployment and laziness to some level. After
> all, RFC2817 isn't even a year old, and it does take time before an
> RFC generates some real stuff (look at RFC2560 which is a year and a
> half old, it took time before there were OCSP-aware products)...
I don't think it's just laziness.
Frankly, RFC 2817 has a lot of problems. Although it allows
automatic negotiation, which is a plus, there's no way to
specify in the URL that the client should EXPECT to negotiation
TLS (other than using https:// which would indicate that you
should do HTTPS, not HTTP Upgrade with a requirement for TLS).
This is a serious reference integrity problem.
Also, HTTP Upgrade interacts very badly with proxies. Since
Upgrade is a hop-by-hop header, there's no way to negotiate
an end-to-end HTTP Upgrade to TLS through a proxy, which is
a serious problem. By contrast, HTTPS just uses the CONNECT
method.
So, I don't expect HTTP Upgrade to displace HTTPS for web
browsers any time soon.
-Ekr
[Eric Rescorla [EMAIL PROTECTED]]
Author of "SSL and TLS: Designing and Building Secure Systems"
http://www.rtfm.com/
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
