Hi folks,
See below for clarification of how a single port works just fine (with
HTTP/1.1 or any other session protocol) for upgrade in the same
connection to TLS mode (always secure, optionally encrypted).
Cheers,
- Ira McDonald
High North Inc
-----Original Message-----
From: Harry Lewis [mailto:harryl at us.ibm.com]
Sent: Friday, January 24, 2003 4:04 PM
To: McDonald, Ira
Subject: RE: Secure / Unsecure on one port.
Ira, thanks for the response. We just reviewed it at the f2f and switched
our position which, earlier today, was 2 ports. OK if I forward your note to
the PSI reflector as it captures the topic better than anything I'v seen.
----------------------------------------------
Harry Lewis
IBM Printing Systems
----------------------------------------------
"McDonald, Ira" <imcdonald at sharplabs.com>
01/24/2003 01:22 PM
To: Harry Lewis/Boulder/IBM at IBMUS, "McDonald, Ira"
<imcdonald at sharplabs.com>
cc:
Subject: RE: Secure / Unsecure on one port.
Hi Harry,
Works exactly like shipping 'ipp:' implementations today.
You come in on the standard PSI port (e.g., '3700' - some
port that is NOT a kernel-mode port less than '1024' decimal)
with an HTTP request (e.g., read capabilities of PSI service)
and the server replies with '426 Upgrade Required' (see below).
The client then MUST initiate the TLS upgrade (see below).
The details for all generic HTTP applications are spelled
out in the 'standards track' RFC 2817 "Upgrading to TLS
Within HTTP/1.1".
See section 3 'Client Requested Upgrade to HTTP over TLS'
and section 4 'Server Requested Upgrade to HTTP over TLS'
and section 5 'Upgrade across Proxies' of RFC 2817.
Cheers,
- Ira
------------------------------------------
[excerpts from RFC 2817]
1. Motivation
The historical practice of deploying HTTP over SSL3 [3] has
distinguished the combination from HTTP alone by a unique URI scheme
and the TCP port number. The scheme 'http' meant the HTTP protocol
alone on port 80, while 'https' meant the HTTP protocol over SSL on
port 443. Parallel well-known port numbers have similarly been
requested -- and in some cases, granted -- to distinguish between
secured and unsecured use of other application protocols (e.g.
snews, ftps). This approach effectively halves the number of
available well known ports.
At the Washington DC IETF meeting in December 1997, the Applications
Area Directors and the IESG reaffirmed that the practice of issuing
parallel "secure" port numbers should be deprecated. The HTTP/1.1
Upgrade mechanism can apply Transport Layer Security [6] to an open
HTTP connection.
In the nearly two years since, there has been broad acceptance of the
concept behind this proposal, but little interest in implementing
alternatives to port 443 for generic Web browsing. In fact, nothing
in this memo affects the current interpretation of https: URIs.
However, new application protocols built atop HTTP, such as the
Internet Printing Protocol [7], call for just such a mechanism in
order to move ahead in the IETF standards process.
The Upgrade mechanism also solves the "virtual hosting" problem.
Rather than allocating multiple IP addresses to a single host, an
HTTP/1.1 server will use the Host: header to disambiguate the
intended web service. As HTTP/1.1 usage has grown more prevalent,
more ISPs are offering name-based virtual hosting, thus delaying IP
address space exhaustion.
TLS (and SSL) have been hobbled by the same limitation as earlier
versions of HTTP: the initial handshake does not specify the intended
hostname, relying exclusively on the IP address. Using a cleartext
HTTP/1.1 Upgrade: preamble to the TLS handshake -- choosing the
certificates based on the initial Host: header -- will allow ISPs to
provide secure name-based virtual hosting as well.
...
4.2 Mandatory Advertisement
A server MAY indicate that a client request can not be completed
without TLS using the "426 Upgrade Required" status code, which MUST
include an an Upgrade header field specifying the token of the
required TLS version.
HTTP/1.1 426 Upgrade Required
Upgrade: TLS/1.0, HTTP/1.1
Connection: Upgrade
The server SHOULD include a message body in the 426 response which
indicates in human readable form the reason for the error and
describes any alternative courses which may be available to the user.
Note that even if a client is willing to use TLS, it must use the
operations in Section 3 to proceed; the TLS handshake cannot begin
immediately after the 426 response.
-----Original Message-----
From: Harry Lewis [mailto:harryl at us.ibm.com]
Sent: Friday, January 24, 2003 1:29 PM
To: McDonald, Ira
Subject: Secure / Unsecure on one port.
Ira, we're having difficulty in the f2f discussions with the concept of 1 vs
2 ports for secure and unsecure connections. I recall, in a phone conv, that
you described a method for coming in on (port 3700 ex.) unsecure and
negotiating, immediately, to secure. Don't think anyone here knows how this
works.
----------------------------------------------
Harry Lewis
IBM Printing Systems
----------------------------------------------