Loading ...
Sorry, an error occurred while loading the content.

Re: draft-ietf-tls-http-upgrade reissued

Expand Messages
  • Julien Pierre
    Hi, I know this is an old messsage, but I must ask : has anybody tried to implement this TLS upgrade draft ? Or is anybody contemplating it ? I would certainly
    Message 1 of 15 , May 3, 2000
    • 0 Attachment
      Hi,

      I know this is an old messsage, but I must ask : has anybody tried to
      implement this TLS upgrade draft ? Or is anybody contemplating it ?
      I would certainly like to get the benefits of secure software virtual
      servers, but I have concerns about this draft.

      At first, as a server implementer, the proposal in this draft looks good,
      and quite straightforward to implement . All I have to do is parse the
      clear-text TLS upgrade request from the client, find the right keys and
      certs for the virtual host requested, and upgrade the existing connection to
      TLS. Also, I can force a connection upon the client if an ACL is set. This
      is nothing major and looks clean.

      However, upon further examination, there are logistical and security
      problems with doing a TLS upgrade. Here are a few.

      1) It is a fact that many server products out there use confidential data,
      like application session keys, or other confidential state information, as
      part of the URI.

      Section 8.1 states :
      "servers may apply resource access rules such as 'the FORM on this page must
      be served and submitted using TLS'

      Even if a server enforces such a restriction, the URI will already be
      compromised as part of the TLS upgrade process, because it is transmitted in
      clear by the client before the server instructs it to upgrade to TLS.

      2) Nowadays, web users know if they have an http link that the connection is
      not secure, and that if it's https it is secure (SSL). It's possible by
      looking at the source for an HTML form to determine ahead of time if the
      data you will submit will go out in clear or not. The new upgrade draft
      makes it unpredictable, by its use of regular http URLs.

      With the new draft, there may be http:// link on a web form, for example to
      submit (POST) confidential data, made with the assumption that the server
      has an ACL requiring a TLS upgrade and therefore that the connection will be
      secured.

      A current-generation HTTP client will create a request with the form data
      from the user, and submit it in clear text to the server, compromising the
      data even before the server gets a chance to deny it by requesting a TLS
      upgrade with an HTTP 426 return code. This compromises security in order to
      retain compatibility with existing HTTP clients. I do not think it is an
      acceptable compromise.

      3) Section 8.1 states :

      "8.1 Implications for the https: URI Scheme

      While nothing in this memo affects the definition of the 'https' URI
      scheme, widespread adoption of this mechanism for HyperText content
      could use 'http' to identify both secure and non-secure resources.

      The choice of what security characteristics are required on the
      connection is left to the client and server. This allows either
      party to use any information available in making this determination.
      For example, user agents may rely on user preference settings or
      information about the security of the network such as 'TLS required
      on all POST operations not on my local net', or servers may apply
      resource access rules such as 'the FORM on this page must be served
      and submitted using TLS'. "

      When it comes to security, I don't think ambiguity is a good thing, and it
      is not good to leave it entirely
      "up to the client and server" to determine what security characteristics are
      needed for the connection.
      I think the draft should define at least one standard way to tell clients
      that an upgrade is in order before connection establishment.

      Take the HTML form example described in my second remark.

      What is a new HTTP client aware of the TLS upgrade draft supposed to do when
      submitting such an HTML form ? Should it always try first thing to upgrade
      the connection to any HTTP server to TLS, before issuing any meaningful
      request (containing URI and maybe also POST data) ?

      That would certainly work technically and ensure best possible security, but
      it would be a major waste of bandwidth in 99% of the cases since current
      servers will not understand the upgrade request and reject it. Many existing
      servers don't support keep-alive and will even close the connection,
      introducing extra latency due to the need to reconnect.

      It may also be a waste of CPU for both the server and client, since perhaps
      the connection didn't really need to be secure, but ended up as TLS because
      of the way the client negotiated the upgrade for every server, and the
      server just accepted it.

      I think a key problem even for a next-generation HTTP client that is aware
      of the upgrade mechanism in this draft, and would be able to perform the
      upgrade to TLS - is that the original HTML form fails to specify that the
      client should not POST the data in clear, but must request upgrade to TLS.

      There needs to be a way to inform the client to request security prior to
      the establishment of the connection. I think something still needs to be
      specified in the URL to let the client know ahead of time that security is
      required for the connection. It cannot be a regular https:// URL since that
      will not allow the server to differentiate the virtual host for which the
      data is intended. I believe a clean way to do it is to instead have a
      distinct protocol name in the URL.

      Perhaps there should be other ways to specify it than a protocol name, and
      perhaps it doesn't belong in the HTML and not HTTP specification, but I
      think that this is a major hole in the draft. Certainly, a new protocol name
      means that some clients will not be able to follow some links on new servers
      that require a TLS step up, but I think it is acceptable in the name of
      uncompromised security.


      I believe there is another approach to solving this problem of tying secure
      virtual servers to IP addresses. It is completely different than the
      proposal in this draft, and does not address the issues of using dual ports
      for non-secure and TLS, but I believe is is still relevant.

      Instead of trying to define a mechanism to upgrade the connection from
      non-secure to secure, the virtual host negotiation could be made a standard
      part of the SSL/TLS protocols. I think that makes sense since these
      protocols exchange certificates which are tied to the virtual host names.
      This is how I would envision it would work :

      Let's take two virtual hosts, say secure.sun.com and secure.netscape.com .
      They both resolve to the same IP address.

      A client wants to connect to https://secure.sun.com . The server happens to
      present its public key with the certificate for secure.netscape.com . At
      that point, the client normally brings a pop-up dialog saying that the
      certificate doesn't match the host requested - which was secure.sun.com ,
      then asks the user if he wants to continue, and the user usually stops the
      connection.

      Instead, the client would by default agree to communicate with the server on
      the current SSL/TLS socket, specifically to issue a "virtual host change"
      request for secure.sun.com .

      The server would then realize that it also knows the key and cert for
      secure.sun.com, and would be given the opportunity to renegotiate the SSL
      connection with the client, this time presenting secure.sun.com's public key
      and certificate. The client could then verify that certificate and accept
      it, and the whole process would be transparent for the user.

      As you will note, this process requires two full SSL/TLS handshakes, so it
      is more expensive in CPU. But that can be optimized. The secure virtual
      server could have a unique public key, with several certificates signing
      that same key - one certificate for each virtual host. It would then only
      have to transmit the certificate for secure.sun.com, without having to
      transmit a different public key. This second certificate would satisfy the
      client, and would be much faster since it would save a second full
      handshake. As part of TLS, this process would be generically applicable to
      any other type of TCP client/server application with TLS, not specifically
      tied to HTTP.

      If you have made it this far, I'm now waiting for all your objections, so go
      ahead and shoot !

      Scott Lawrence wrote:

      > The secretariat didn't forward this announcement to this list, so I
      > will.
      >
      > The only change from version -04 is the addition of the standard
      > boilerplate and references regarding the keywords (MUST, SHOULD,
      > MAY, etc).
      >
      > A New Internet-Draft is available from the on-line Internet-Drafts
      > directories.
      > This draft is a work item of the Transport Layer Security Working
      > Group of the IETF.
      >
      > Title : Upgrading to TLS Within HTTP/1.1
      > Author(s) : R. Khare, S. Lawrence
      > Filename : draft-ietf-tls-http-upgrade-05.txt
      > Pages : 13
      > Date : 05-Jan-00
      >
      > This memo explains how to use the Upgrade mechanism in HTTP/1.1 to
      > initiate Transport Layer Security (TLS) over an existing TCP
      > connection. This allows unsecured and secured HTTP traffic to share
      > the same well known port (in this case, http: at 80 rather than
      > https: at 443). It also enables 'virtual hosting,' so a single HTTP
      > + TLS server can disambiguate traffic intended for several hostnames
      > at a single IP address.
      > Since HTTP/1.1[1] defines Upgrade as a hop-by-hop mechanism, this
      > memo also documents the HTTP CONNECT method for establishing
      > end-to-end tunnels across HTTP proxies. Finally, this memo
      > establishes new IANA registries for public HTTP status codes, as
      > well as public or private Upgrade product tokens.
      >
      > A URL for this Internet-Draft is:
      > http://www.ietf.org/internet-drafts/draft-ietf-tls-http-upgrade-05.t
      > xt
      >
      > Internet-Drafts are also available by anonymous FTP. Login with the
      > username
      > "anonymous" and a password of your e-mail address. After logging in,
      > type "cd internet-drafts" and then
      > "get draft-ietf-tls-http-upgrade-05.txt".
      >
      > A list of Internet-Drafts directories can be found in
      > http://www.ietf.org/shadow.html
      > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
      >
      > Internet-Drafts can also be obtained by e-mail.
      >
      > Send a message to:
      > mailserv@....
      > In the body type:
      > "FILE /internet-drafts/draft-ietf-tls-http-upgrade-05.txt".
      >
      > NOTE: The mail server at ietf.org can return the document in
      > MIME-encoded form by using the "mpack" utility. To use this
      > feature, insert the command "ENCODING mime" before the "FILE"
      > command. To decode the response(s), you will need "munpack" or
      > a MIME-compliant mail reader. Different MIME-compliant mail
      > readers
      > exhibit different behavior, especially when dealing with
      > "multipart" MIME messages (i.e. documents which have been split
      > up into multiple messages), so check your local documentation on
      > how to manipulate these messages.
      >
      > --
      > Scott Lawrence Director of R & D <lawrence@...>
      > Agranat Systems Embedded Web Technology http://www.agranat.com/

      --
      for a good time, try kill -9 -1
    • Rohit Khare
      ... Yes, Scott has, and some other Internet Printing Protocol folks. ... Thanks! Scott & I will take all the credit for the fine editing job, and none of the
      Message 2 of 15 , May 3, 2000
      • 0 Attachment
        At 10:42 PM -0700 5/3/00, Julien Pierre wrote:
        >I know this is an old messsage, but I must ask : has anybody tried to
        >implement this TLS upgrade draft ?

        Yes, Scott has, and some other Internet Printing Protocol folks.

        >At first, as a server implementer, the proposal in this draft looks good,
        >and quite straightforward to implement .

        Thanks! Scott & I will take all the credit for the fine editing job,
        and none of the blame for the ideas :-)

        >1) It is a fact that many server products out there use confidential data,
        >like application session keys, or other confidential state information, as
        >part of the URI.

        Can't do much about that.

        This is a general theme of my following comments. Guns can be pointed
        at feet. Triggers can be pulled...

        >Even if a server enforces such a restriction, the URI will already be
        >compromised as part of the TLS upgrade process, because it is transmitted in
        >clear by the client before the server instructs it to upgrade to TLS.

        In general, I suspect that a secure-real-time web application should
        be negotiating TLS *before* handing out a FORM at all. But even if it
        did, the following rule applies:

        You can *never* prevent a client from publishing data in the New York Times.

        If the user's filling in sensitive data, it's the user-agent's job to
        demand secure upgrades before sending as much as the server's, if not
        more.

        >2) Nowadays, web users know if they have an http link that the connection is
        >not secure, and that if it's https it is secure (SSL).

        User behavior has little to do with TCP port numbers. On the other
        hand, nothing in the draft supposes that we will ever change the
        existing practice for Web Hypertext surfing applications.

        >A current-generation HTTP client will create a request with the form data
        >from the user, and submit it in clear text to the server, compromising the
        >data even before the server gets a chance to deny it by requesting a TLS
        >upgrade with an HTTP 426 return code. This compromises security in order to
        >retain compatibility with existing HTTP clients. I do not think it is an
        >acceptable compromise.

        Don't send the FORM in the clear, either.

        >When it comes to security, I don't think ambiguity is a good thing, and it
        >is not good to leave it entirely
        >"up to the client and server" to determine what security characteristics are
        >needed for the connection.

        There is no such thing as absolute security. It is always, in the
        end, in the eye of the beholders.

        >I think the draft should define at least one standard way to tell clients
        >that an upgrade is in order before connection establishment.

        Yes, it does -- 426.

        >That would certainly work technically and ensure best possible security, but
        >it would be a major waste of bandwidth in 99% of the cases since current
        >servers will not understand the upgrade request and reject it. Many existing
        >servers don't support keep-alive and will even close the connection,
        >introducing extra latency due to the need to reconnect.

        Bala Krishnamurthy's PRO-COW compliance survey can tell you about the
        smaller fraction that don't support any form of keep-alive.

        >It may also be a waste of CPU for both the server and client, since perhaps
        >the connection didn't really need to be secure, but ended up as TLS because
        >of the way the client negotiated the upgrade for every server, and the
        >server just accepted it.

        Purely as a matter of opinion, I'm worried about keeping Andy Grove
        employed, not the other way around :-) Someday, every packet will
        finally be encrypted, and the cycle-time argument is moot.

        >It cannot be a regular https:// URL since that
        >will not allow the server to differentiate the virtual host for which the
        >data is intended.

        Sure it can -- interpret https: in a next-generation "client" as an
        invitation to first try Upgrade on port 80, then fall-back to 423.

        >Instead of trying to define a mechanism to upgrade the connection from
        >non-secure to secure, the virtual host negotiation could be made a standard
        >part of the SSL/TLS protocols. I think that makes sense since these
        >protocols exchange certificates which are tied to the virtual host names.

        This has long been on the "to-do" list for TLS/SSL. Installed base
        strikes again, though, in making this case fairly unlikely. But I
        agree that's the "right" solution for so many more TLS/SSL enabled
        apps than HTTP alone.

        Late night thoughts,
        Rohit Khare
      • Scott Lawrence
        Rohit covered the ground pretty well, and all the points you raise were discussed the first time around in one way or another, but I ll reiterate a point or
        Message 3 of 15 , May 4, 2000
        • 0 Attachment
          Rohit covered the ground pretty well, and all the points you raise
          were discussed the first time around in one way or another, but I'll
          reiterate a point or two.

          Users have been trained to believe that an 'https:' scheme means
          'secure', but what does it really mean? What it means is 'try this
          connection first on port 443 and negotiate (via the TLS/SSL
          handshake) a set of security services'. Key to this is
          'negotiate' - the resulting connection could negotiate a set of
          services using any of several cipher suites, including easily
          breakable or null encryption. The 'https:' is, in effect, a single
          bit of information about how secure the connection for the request
          should be, and that isn't enough to be meaningful. A proper
          comprehensive mechanism might provide for (for example) additional
          attributes to accompany HTML href that would specify the minimum
          required security services, but those don't exist and are outside
          the scope of a protocol spec.

          Several reviewers objected (as you have) to the fact that an http:
          URL is exposed when first requested, and suggested that this
          represents a 'leak' - it should only be used on a secure connection.
          The implication is that content (such as the link) should never be
          used over a connection less secure than the one over which it was
          first obtained (I serve a document over a secure connection, the
          user clicks on a link and exposes a piece of it on an unsecured
          channel). The problem with this argument is that web clients do not
          now and never have had this rule - secured and unsecured content is
          treated in the same way. What is the security status (rules for
          linking) of a document I get from a floppy given to me by someone
          else who downloaded it? If there is a need for labelling of content
          with security attributes, then that need is best met in the content
          itself, and the 'single bit' of appending an 's' to the scheme name
          is grossly insufficient.

          The spec also serves to complete the definition of how the HTTP
          Upgrade mechanism should be used for any protocol change on an
          existing connection. When we actually tried to work it out for this
          one case, we found that a number of issues (such as the lack of 426)
          had not been addressed in the original 1.1 RFCs.

          --
          Scott Lawrence Director of R & D <lawrence@...>
          Agranat Systems Embedded Web Technology http://www.agranat.com/
        • Rohit Khare
          ... To be sure, the blame is also on Martin Arlitt s shoulders :-) http://fog.hpl.hp.com/techreports/1999/HPL-1999-99.html ... The bottom line is that two
          Message 4 of 15 , May 4, 2000
          • 0 Attachment
            >Bala Krishnamurthy's PRO-COW compliance survey can tell you about
            >the smaller fraction that don't support any form of keep-alive.

            To be sure, the blame is also on Martin Arlitt's shoulders :-)

            http://fog.hpl.hp.com/techreports/1999/HPL-1999-99.html

            >PRO-COW: Protocol Compliance on the Web
            >
            >Krishnamurthy, Balachander; Arlitt, Martin
            >
            >HPL-1999-99
            >990921
            >External
            >
            >Keyword(s): HTTP/1.1; protocol; World Wide Web; compliancy
            >
            >Abstract: With the recent (draft) standardization of the HTTP/1.1
            >protocol on the Web, it is natural to ask what percentage of popular
            >Web sites speak HTTP/1.1 and how compliant are these so-called
            >HTTP/1.1 servers. We attempt to answer these questions through a
            >series of experiments based on the protocol standard. The tests are
            >run on a comprehensive list of popular Web sites to which a good
            >fraction of the Web traffic is directed. Our experiments were
            >conducted on a global extensible testing infrastructures that we
            >built to answer the above questions. The same infrastructure will be
            >used to answer questions like the percentage of the traffic flow
            >that is end-to-end HTTP/1.1 protocol compliancy and the subset of
            >features actually available to end users.
            >
            >23 Pages


            The bottom line is that two thirds or more of public Web servers
            already support persistent connections.

            Best,
            Rohit Khare
          • Julien Pierre
            Hi, ... I don t think you ll get away with that. See below. ... My question is : what would cause it to perform that TLS negotiation before hand, since the URL
            Message 5 of 15 , May 4, 2000
            • 0 Attachment
              Hi,

              Rohit Khare wrote:

              > Thanks! Scott & I will take all the credit for the fine editing job,
              > and none of the blame for the ideas :-)

              I don't think you'll get away with that. See below.

              > >1) It is a fact that many server products out there use confidential data,
              > >like application session keys, or other confidential state information, as
              > >part of the URI.
              >
              > Can't do much about that.
              >
              > This is a general theme of my following comments. Guns can be pointed
              > at feet. Triggers can be pulled...
              >
              > >Even if a server enforces such a restriction, the URI will already be
              > >compromised as part of the TLS upgrade process, because it is transmitted in
              > >clear by the client before the server instructs it to upgrade to TLS.
              >
              > In general, I suspect that a secure-real-time web application should
              > be negotiating TLS *before* handing out a FORM at all.

              My question is : what would cause it to perform that TLS negotiation before hand,
              since the URL is regular http ?

              > But even if it
              > did, the following rule applies:
              >
              > You can *never* prevent a client from publishing data in the New York Times.
              >
              > If the user's filling in sensitive data, it's the user-agent's job to
              > demand secure upgrades before sending as much as the server's, if not
              > more.

              I don't think users will waste their time filling forms if they are not ahead of
              time certain that it will be transmitted securely.
              The user-agent can only warn after the negotiation fails, and the user only has
              the option of discarding all the data he entered.

              > >2) Nowadays, web users know if they have an http link that the connection is
              > >not secure, and that if it's https it is secure (SSL).
              >
              > User behavior has little to do with TCP port numbers. On the other
              > hand, nothing in the draft supposes that we will ever change the
              > existing practice for Web Hypertext surfing applications.

              Maybe your draft is appropriate for your internet printing applications. But
              clearly, it will not fill the needs of web surfers and ISPs who want to provide
              secure virtual hosting without exhausting the IPv4 address space.

              The duplicate TCP port number issue is IMHO less of a problem because it is rare
              to exhaust all 2**16 possible TCP ports on a server. That would mean you are
              running that many different daemons ...

              > >A current-generation HTTP client will create a request with the form data
              > >from the user, and submit it in clear text to the server, compromising the
              > >data even before the server gets a chance to deny it by requesting a TLS
              > >upgrade with an HTTP 426 return code. This compromises security in order to
              > >retain compatibility with existing HTTP clients. I do not think it is an
              > >acceptable compromise.
              >
              > Don't send the FORM in the clear, either.

              Again, how do you propose that the client make the decision to upgrade ?
              Does it have to try to upgrade on every non-secure HTTP link ?
              Will the browser prompt users for every link whether they want security ?

              > >When it comes to security, I don't think ambiguity is a good thing, and it
              > >is not good to leave it entirely
              > >"up to the client and server" to determine what security characteristics are
              > >needed for the connection.
              >
              > There is no such thing as absolute security. It is always, in the
              > end, in the eye of the beholders.

              That's no reason to make it easier for people to shoot themselves in the foot,
              which is what this draft does.

              > >I think the draft should define at least one standard way to tell clients
              > >that an upgrade is in order before connection establishment.
              >
              > Yes, it does -- 426.

              Just how do you get a 426 before you establish a connection with the server ?
              Take the case with my HTML form, residing on site a, a product catalog site,
              which has no security.
              It's got a link to POST the order data to site b , which is a secure virtual
              server supporting TLS upgrade.
              With your proposal, this link must be a regular http link.
              What will cause the browser to negotiate security when the credit card
              information is submitted to site b ?
              I contend that there has to be something on the order page to tell it to do so. I
              think it should be part of the URL, perhaps a protocol of "httpt" - to specify
              http over TLS with upgrade.
              The trigger cannot be a prompting option configured globally in the user-agent,
              because it would not be practical for users to be prompted for security on every
              regular HTTP request, and they would just disable it.


              > >That would certainly work technically and ensure best possible security, but
              > >it would be a major waste of bandwidth in 99% of the cases since current
              > >servers will not understand the upgrade request and reject it. Many existing
              > >servers don't support keep-alive and will even close the connection,
              > >introducing extra latency due to the need to reconnect.
              >
              > Bala Krishnamurthy's PRO-COW compliance survey can tell you about the
              > smaller fraction that don't support any form of keep-alive.

              Even so, the original point is bandwidth waste, and it is still valid.
              To implement this, the user-agent must always initiate an upgrade request to the
              server as its first request, then wait for the server to accept or ignore that
              request. This also adds latency in the initial client request to the server,
              which is delayed by this negotiation.


              > >It may also be a waste of CPU for both the server and client, since perhaps
              > >the connection didn't really need to be secure, but ended up as TLS because
              > >of the way the client negotiated the upgrade for every server, and the
              > >server just accepted it.
              >
              > Purely as a matter of opinion, I'm worried about keeping Andy Grove
              > employed, not the other way around :-) Someday, every packet will
              > finally be encrypted, and the cycle-time argument is moot.

              I'm in very strong disagreement. Keeping Intel (or Sun, for the matter) in
              business is not the issue.
              You may not be aware of that fact, but in a typical secure web server today, the
              overhead of doing encryption represents about 90% of CPU cycles spent. This means
              a web server is an order of magnitude slower if it has to server secure
              connections vs non-secure.

              In turn, your proposal would result in an average tenfold increase in the
              hardware requirement for servers, as well as waste of energy to power all those
              CPUs, all for no good reason at all. Or the alternative would be a tenfold
              increase in average web server latency, given no hardware upgrade.

              I contend that there are web applications for which it's perfectly ok to not be
              secured - for instant, accessing publicly available content. And there is a
              minority of web applications where security is absolutely required, like
              electronic commerce.

              So far, I have never heard of a single application where security "would be nice,
              but it's ok if it is not available" . This is what this draft really enables. I
              call it a misfeature and I'm not eager to see it appear in mainstream HTTP
              clients and servers.

              I think it is necessary for a web application to be able to enforce security or
              no security.


              > >It cannot be a regular https:// URL since that
              > >will not allow the server to differentiate the virtual host for which the
              > >data is intended.
              >
              > Sure it can -- interpret https: in a next-generation "client" as an
              > invitation to first try Upgrade on port 80, then fall-back to 423.

              No, this would break the semantic of the https URL.
              When you specify an https URL nowadays, it implicitly tells the client to connect
              onto the default https protocol port, which is 443, as long as the port is not
              explicitly specified.
              It is not very common, but I certainly have seen URLs of the form
              https://mysite:443 , with the port explicitly.
              But the biggest problem is , if a different port is specified.
              What would be the behavior that you would propose for, say, an https://mysite:444
              URL ?
              Should the client skip the connection to port 80 and try TLS directly on 444 ?
              This proposal seems shaky to me, because it effectively modifies the protocol by
              virtue of running on a different port. I think the protocol should be able to run
              on any TCP port without major behavior changes like this.

              > >Instead of trying to define a mechanism to upgrade the connection from
              > >non-secure to secure, the virtual host negotiation could be made a standard
              > >part of the SSL/TLS protocols. I think that makes sense since these
              > >protocols exchange certificates which are tied to the virtual host names.
              >
              > This has long been on the "to-do" list for TLS/SSL. Installed base
              > strikes again, though, in making this case fairly unlikely. But I
              > agree that's the "right" solution for so many more TLS/SSL enabled
              > apps than HTTP alone.

              Good. I think I will join their mailing list. Any pointers ?

              --
              for a good time, try kill -9 -1
            • Julien Pierre
              Hi, ... Agreed. However, one can disable the null & easily breakable cipher suites in their client, and therefore be sure that when https URLs are submitted,
              Message 6 of 15 , May 4, 2000
              • 0 Attachment
                Hi,

                Scott Lawrence wrote:

                > Rohit covered the ground pretty well, and all the points you raise
                > were discussed the first time around in one way or another, but I'll
                > reiterate a point or two.
                >
                > Users have been trained to believe that an 'https:' scheme means
                > 'secure', but what does it really mean? What it means is 'try this
                > connection first on port 443 and negotiate (via the TLS/SSL
                > handshake) a set of security services'. Key to this is
                > 'negotiate' - the resulting connection could negotiate a set of
                > services using any of several cipher suites, including easily
                > breakable or null encryption.

                Agreed. However, one can disable the null & easily breakable cipher
                suites in their client, and therefore be sure that when https URLs are
                submitted, the connection is secure. The NULL encryption is by default
                disabled in mainstream browsers.


                > If there is a need for labelling of content
                > with security attributes, then that need is best met in the content
                > itself, and the 'single bit' of appending an 's' to the scheme name
                > is grossly insufficient.

                I agree that it would be better to get more security information in the
                content links than just that one "s" bit.

                However, the complete lack of even that one bit to determine the
                security attribute, which is what you propose by using regular http
                URLs, is not merely grossly insufficient, but completely unacceptable.

                I understand that you are trying to keep some level of compatibility
                with existing clients, and at the same time trying to unify the ports
                for secure/non-secure servers, and allowing secure virtual servers. I
                believe however that none of the problems are solved adequately :

                - existing HTTP clients will compromise security when connected to the
                new servers, because they will not be able to negotiate the TLS ugrade
                - existing HTTPS clients will not even connect to the new servers,
                because the server will be expecting an initial non-secure connection
                followed by an upgrade

                This shows that it's not a practical solution for saving TCP ports at
                this time. It requires an entirely new generation of servers and
                clients, and even then there is still doubt about how the upgrade to TLS
                is enforced, as mentioned in previous e-mails.

                --
                for a good time, try kill -9 -1
              • John Stracke
                ... Just because a client always asks to upgrade doesn t mean the server has to obey. -- /============================================================== ...
                Message 7 of 15 , May 4, 2000
                • 0 Attachment
                  Julien Pierre wrote:

                  > You may not be aware of that fact, but in a typical secure web server today, the
                  > overhead of doing encryption represents about 90% of CPU cycles spent. This means
                  > a web server is an order of magnitude slower if it has to server secure
                  > connections vs non-secure.
                  >
                  > In turn, your proposal would result in an average tenfold increase in the
                  > hardware requirement for servers, as well as waste of energy to power all those
                  > CPUs, all for no good reason at all. Or the alternative would be a tenfold
                  > increase in average web server latency, given no hardware upgrade.

                  Just because a client always asks to upgrade doesn't mean the server has to obey.

                  --
                  /==============================================================\
                  |John Stracke | http://www.ecal.com |My opinions are my own.|
                  |Chief Scientist |=============================================|
                  |eCal Corp. |"HTTP is what happens in the absence of good |
                  |francis@...|design." -- Keith Moore |
                  \==============================================================/
                • Scott Lawrence
                  ... If they are that concerned about it, then they should not fill out forms that were not delivered securely. If the form was delivered over an unsecured
                  Message 8 of 15 , May 4, 2000
                  • 0 Attachment
                    > From: Julien Pierre

                    > I don't think users will waste their time filling forms
                    > if they are not ahead of
                    > time certain that it will be transmitted securely.

                    If they are that concerned about it, then they should not fill out
                    forms that were not delivered securely. If the form was delivered
                    over an unsecured connection, it may have been modified in any
                    number of ways to subvert the apparent intent of the form. Browsers
                    don't normally expose the ACTION attribute of a form - an attacker
                    may have changed that, or modified field names - the possibilities
                    are endless. Encrypting one exchange in a multiple exchange
                    transaction is no security at all.

                    > The duplicate TCP port number issue is IMHO less of a
                    > problem because it is rare
                    > to exhaust all 2**16 possible TCP ports on a server.

                    The concern is with the well-known ports - a much much smaller
                    space.

                    --
                    Scott Lawrence Director of R & D <lawrence@...>
                    Agranat Systems Embedded Web Technology http://www.agranat.com/
                  • Julien Pierre
                    Hi, ... So how does that make the draft useful if the upgrade is never allowed ? -- for a good time, try kill -9 -1
                    Message 9 of 15 , May 4, 2000
                    • 0 Attachment
                      Hi,

                      John Stracke wrote:

                      > > In turn, your proposal would result in an average tenfold increase in the
                      > > hardware requirement for servers, as well as waste of energy to power all those
                      > > CPUs, all for no good reason at all. Or the alternative would be a tenfold
                      > > increase in average web server latency, given no hardware upgrade.
                      >
                      > Just because a client always asks to upgrade doesn't mean the server has to obey.

                      So how does that make the draft useful if the upgrade is never allowed ?

                      --
                      for a good time, try kill -9 -1
                    • Julien Pierre
                      Hi, ... OK, assume the form was delivered on a secure server. Then it gets submitted to somebody else - a virtual host on a payment processing server - to
                      Message 10 of 15 , May 4, 2000
                      • 0 Attachment
                        Hi,

                        Scott Lawrence wrote:

                        > > From: Julien Pierre
                        >
                        > > I don't think users will waste their time filling forms
                        > > if they are not ahead of
                        > > time certain that it will be transmitted securely.
                        >
                        > If they are that concerned about it, then they should not fill out
                        > forms that were not delivered securely. If the form was delivered
                        > over an unsecured connection, it may have been modified in any
                        > number of ways to subvert the apparent intent of the form. Browsers
                        > don't normally expose the ACTION attribute of a form - an attacker
                        > may have changed that, or modified field names - the possibilities
                        > are endless. Encrypting one exchange in a multiple exchange
                        > transaction is no security at all.

                        OK, assume the form was delivered on a secure server. Then it gets
                        submitted to somebody else - a virtual host on a payment processing
                        server - to actually process the transaction. This is very common. The
                        action URL will use regular http .
                        How does the security upgrade get triggered ?

                        One more thing to consider :
                        Let's say you are browsing a site and the connection got upgraded to TLS
                        . Then you sit idle for a while, and your keep-alive connection times
                        out. You are on a different part of the site now, filled with normal
                        http:// links. You click on one. The client has to reconnect. How does
                        the security get restored ?


                        >
                        > > The duplicate TCP port number issue is IMHO less of a
                        > > problem because it is rare
                        > > to exhaust all 2**16 possible TCP ports on a server.
                        >
                        > The concern is with the well-known ports - a much much smaller
                        > space.
                        >
                        > --
                        > Scott Lawrence Director of R & D <lawrence@...>
                        > Agranat Systems Embedded Web Technology http://www.agranat.com/

                        --
                        for a good time, try kill -9 -1
                      • John Stracke
                        ... Who said never? A client that wants to use the draft can ask for an upgrade on every HTTP request. Servers that aren t willing to spend cycles on TLS for a
                        Message 11 of 15 , May 5, 2000
                        • 0 Attachment
                          Julien Pierre wrote:

                          > John Stracke wrote:
                          >
                          > > Just because a client always asks to upgrade doesn't mean the server has to obey.
                          >
                          > So how does that make the draft useful if the upgrade is never allowed ?

                          Who said never?

                          A client that wants to use the draft can ask for an upgrade on every HTTP request.
                          Servers that aren't willing to spend cycles on TLS for a particular request can just
                          ignore the Upgrade: header.

                          --
                          /==============================================================\
                          |John Stracke | http://www.ecal.com |My opinions are my own.|
                          |Chief Scientist |=============================================|
                          |eCal Corp. |"God does not play games with His loyal |
                          |francis@...|servants." "Whoo-ee, where have you *been*?" |
                          | |--_Good Omens_ |
                          \==============================================================/
                        • Julien Pierre
                          Hi, ... That still does not solve the problem !!! If the client tries to upgrade to TLS on every request, it will fail 99% of the time, because servers don t
                          Message 12 of 15 , May 5, 2000
                          • 0 Attachment
                            Hi,

                            John Stracke wrote:

                            > Julien Pierre wrote:
                            >
                            > > John Stracke wrote:
                            > >
                            > > > Just because a client always asks to upgrade doesn't mean the server has to obey.
                            > >
                            > > So how does that make the draft useful if the upgrade is never allowed ?
                            >
                            > Who said never?
                            >
                            > A client that wants to use the draft can ask for an upgrade on every HTTP request.
                            > Servers that aren't willing to spend cycles on TLS for a particular request can just
                            > ignore the Upgrade: header.

                            That still does not solve the problem !!!

                            If the client tries to upgrade to TLS on every request, it will fail 99% of the time,
                            because servers don't support it. Suppose in 1% of the cases it will actually work.

                            Now, suppose that in 2% of the cases, the request data was intended to be confidential
                            and the user really didn't want to submit the data unsecured, but the server didn't
                            negotiate TLS. The only way for a user to make sure he does not mistakenly submit data
                            unencrypted is to setup his browser to prompt him on every single HTTP request that
                            didn't successfully negotiate TLS.

                            In other words, a waste of time 98% of requests. Do you really find that to be acceptable
                            ?

                            The whole point I'm trying to make is that there should be a way for a web application
                            that is intended to be secure to enforce that fact and reasonably function on a server
                            running on a common port with HTTP and TLS upgrade support. The draft does not propose a
                            way to do that.

                            It would be as simple as a new type of "httpt" URL - which would tell the user-agent to
                            connect insecurely with the server, and immediately negotiate a TLS connection; and
                            otherwise not to proceed if the TLS upgrade fail. This cannot be a global user-agent
                            setting for reasons explained before - security is not always required nor desirable.

                            If you really want to get ISPs to stop wasting IP addresses on multiple secure servers,
                            as well as separate the ports, then you need to make it possible to create new secure web
                            applications that will work with the new user-agents and servers proposed in the new
                            draft, without incurring a high risk of falling back to non-secure connections. The draft
                            is currently too vague in the way that the security is enforced and makes it way too easy
                            to shoot yourself in the foot and end up with a non-secure connection if the negotiation
                            fails, rather than aborting.

                            --
                            for a good time, try kill -9 -1
                          • Julien Pierre
                            Hi, ... Not as much. I meant also that the 98% of the time security pop-up * millions of users would be a huge waste of time. I m sure most everyone would
                            Message 13 of 15 , May 5, 2000
                            • 0 Attachment
                              Hi,

                              Rohit Khare wrote:

                              > You know, we send the HTTP/1.1 and Host: tokens 100% of the time.
                              > Isn't that wasteful, too?

                              Not as much. I meant also that the 98% of the time security pop-up *
                              millions of users would be a huge waste of time. I'm sure most everyone
                              would disable the browser setting if it existed.

                              > >Now, suppose that in 2% of the cases, the request data was intended
                              > >to be confidential
                              > >and the user really didn't want to submit the data unsecured, but
                              > >the server didn't
                              > >negotiate TLS.
                              >
                              > This client would have to force the upgrade via OPTIONS as outlined
                              > in the spec.

                              But how would the end-user inform its client of the fact that he wanted
                              the data to be secure ? You would have to remember to "force" security
                              somehow before submitting on a form ?

                              The security requirement is usually dictated by application logic. I
                              think the web application should have a way to hint the client, in the
                              way of something in the referring document, so that it would happen
                              transparently.

                              I'm not criticizing the underlying network protocol. I'm criticizing the
                              URL specification that clients will use.
                              The server will support both HTTP and HTTP with TLS upgrade. But there is
                              no good way for the client to decide when to use which, since http://
                              URLs are used.

                              > >The whole point I'm trying to make is that there should be a way for
                              > >a web application
                              > >that is intended to be secure to enforce that fact and reasonably
                              > >function on a server
                              > >running on a common port with HTTP and TLS upgrade support. The
                              > >draft does not propose a
                              > >way to do that.
                              >
                              > We believe it does, the last-call in the working group and the ietf
                              > announce list believes it does, and now it falls to all of us,
                              > including yourself, to find out if any of that rough consenus can be
                              > backed by running code.

                              I am quite confident that I can, but I'm not convinced yet that this is
                              the right way to do it.

                              > An "application" -- say,
                              > http://www.foo.edu/randompath/ReallySecureApp.cgi should send back a
                              > 426 for ANY request for a resource under /randompath/. A "user" who
                              > requires the same can use OPTIONS. A user who does not care, but
                              > wants to follow the lead of the server, should reuse the Upgraded TLS
                              > connection as long as he would have an equivalent port 443.

                              Again, what mechanism tells the client to use OPTIONS ?

                              > And recall that this method is *not* being proposed as the idea for
                              > hypertext publishing. The common browser is too deployed to be
                              > changed in its ways.

                              I don't think that's true. The rate of adoption for new HTTP software may
                              not be what it was in 1994 - 1996, but HTTP is still evolving, and there
                              is still an evolution in the mainstream browsers and servers. In fact,
                              the whole reason I'm here on this list is that I'm trying to make the
                              Netscape server support this evolution. I know some Netscape client
                              engineers are reading this as well, and they would like to make it happen
                              on their side too.

                              The fact is, routable static IP addresses have become expensive due to
                              the fact that we are quickly running out of them. ISPs want a way to do
                              secure software virtual servers, without buying expensive IP addresses
                              for each. There is a demand in the marketplace for this, maybe not
                              necessarily for the purpose of hypertext publishing, but certainly for
                              electronic commerce. Since the current protocols do not allow this, the
                              solution calls for a new generation of servers and clients. It will
                              certainly take time to upgrade a significant portion of HTTP clients and
                              servers in use today, but I think it can happen gradually. My wish is to
                              see it happen using open IETF standards in the next generation of HTTP
                              servers and clients, rather than have to wait for the one after that,
                              once the quirks in the current specs are acknowledged.

                              --
                              for a good time, try kill -9 -1
                            • John Stracke
                              ... Servers that don t support it ignore it, because RFC-2616 doesn t provide an error code to mean I don t understand that Upgrade: . (I just tried it on
                              Message 14 of 15 , May 8, 2000
                              • 0 Attachment
                                Julien Pierre wrote:

                                > If the client tries to upgrade to TLS on every request, it will fail 99% of the time,
                                > because servers don't support it.

                                Servers that don't support it ignore it, because RFC-2616 doesn't provide an error code to
                                mean "I don't understand that Upgrade:". (I just tried it on Apache 1.3.9 and 1.3.12, NES
                                3.6, and IIS 5.0; they all behaved exactly the same with and without "Upgrade: foo".) This
                                means that a client that sends the Upgrade: all the time won't break anything; it will cost
                                a few extra bytes, but not the extra round trips you're talking about.

                                --
                                /================================================================\
                                |John Stracke | http://www.ecal.com |My opinions are my own. |
                                |Chief Scientist |===============================================|
                                |eCal Corp. |The cheapest, fastest, most reliable components|
                                |francis@...|of a computer system are those that aren't |
                                | |there.--Gordon Bell |
                                \================================================================/
                              Your message has been successfully submitted and would be delivered to recipients shortly.