Mailing-List: contact users-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@httpd.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <46039D47.6000307@rowe-clan.net>
Date: Fri, 23 Mar 2007 04:26:31 -0500
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
User-Agent: Thunderbird 1.5.0.10 (X11/20070302)
MIME-Version: 1.0
To: users@httpd.apache.org
References: 
 <FDD5D99066749040AF9098A720E9897703780156@CIWMEXZSA0E.ex.ordersx.org>
In-Reply-To: 
 <FDD5D99066749040AF9098A720E9897703780156@CIWMEXZSA0E.ex.ordersx.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [users@httpd] Request for Input: ApacheCon SSL Training

Boyle Owen wrote:
> 
> The FAQ is fine - it describes the situation as it is on the vast
> majority of extant browsers and servers. The RFC you are going to read
> carefully describes a new proposal; basically, to put an additional
> header into the cleartext preamble before the SSL session is
> established. This additional header will contain the hostname and so,
> when the server comes to do the SSL negotiation, it will already know
> the hostname and so will know what VH to go to and so will be able to
> get the correct certificate. NBVHing will then work over SSL!
> 
> I'm not sure about the uptake of this new standard - obviously it relies
> on the browser sending the new header in the request and I don't know
> what, if any, plans there are for building it into new browsers. The
> trouble might be that it's an improvement that helps the server (it can
> use NBVH) but the work (generating the extra header) has to be done in
> the client-community. The client doesn't noticeably gain anything since
> the TCP/IP details of the server are hidden behind the domain-name (ie,
> the user just types a domain-name into the browser and dowsn't know or
> care whether the host is IP-based or name-based).

I know I've given detailed answers before but perhaps not to users@.

Effectively, several appliance servers/custom clients already support this.
Network attached printer appliances and the like.  It's ideal for apps
that know exactly what they are doing.

The problem with RFC 2816 is that the URI ***REMAINS*** http:.  This is
not https:, the https: scheme defines an SSL/TLS endpoint, and the
Connection: Upgrade schema speaks plain text (as you point out).

So here's the problem, play UI designer for a moment.  How do you decide
1) that it should request to upgrade an arbitrary connection, 2) present
to the user the choice to upgrade, 3) present to the user the security
and integrity of the connection?

It's not a trivial question with trivial solutions, and so far none of
the UI client authors have taken on the challenge.


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org