Printer Services Mail Archive: PS> FW: Secure / Unsecure on

PS> FW: Secure / Unsecure on one port.

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Sat Jan 25 2003 - 14:29:54 EST

  • Next message: BERKEMA,ALAN C (HP-Roseville,ex1): "PS> [PSI]: ?? next call 01/28/03"

    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@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@sharplabs.com>
    01/24/2003 01:22 PM
            To: Harry Lewis/Boulder/IBM@IBMUS, "McDonald, Ira"
    <imcdonald@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@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
    ----------------------------------------------



    This archive was generated by hypermail 2b29 : Sat Jan 25 2003 - 14:30:29 EST