* Graham Leggett [EMAIL PROTECTED] wrote:
snip
You forget that there is a trust issue here. SSL brings with it not only
encryption, but certification of the data that's being sent. If the SSL
protocol somehow allowed external unprotected and untrusted information
(like the name of the
* Sander Temme [EMAIL PROTECTED] wrote:
On Dec 18, 2004, at 12:19 AM, Enrico Weigelt wrote:
What fools are sitting there in the IETF ?!
Fools that are highly aware of the hundreds of millions of web browser
installations out there that know nothing but the standard versions of
SSL/TLS
* Ben Laurie [EMAIL PROTECTED] wrote:
snip
There's a well-known solution to this issue: STARTTLS. When you've
written the RFCs and persuaded everyone to adopt them, let us know.
I dont think that current http can be extended to support this.
We not just only need a new port for it, also a new
On Wed, Dec 22, 2004 at 03:41:08PM +0100, Enrico Weigelt wrote:
* Sander Temme [EMAIL PROTECTED] wrote:
On Dec 18, 2004, at 12:19 AM, Enrico Weigelt wrote:
What fools are sitting there in the IETF ?!
Fools that are highly aware of the hundreds of millions of web browser
flexibility need. RFC2616 addresses (whether you
like it or not) YOUR application-specific need.
regards,
tt
317-510-5987
-Original Message-
From: Enrico Weigelt [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 22, 2004 9:41 AM
To: dev@httpd.apache.org
Subject: Re: SSL + name based virtual
* Enrico Weigelt wrote:
* Graham Leggett [EMAIL PROTECTED] wrote:
You forget that there is a trust issue here. SSL brings with it not
only encryption, but certification of the data that's being sent. If
the SSL protocol somehow allowed external unprotected and untrusted
information
At 08:38 AM 12/22/2004, Enrico Weigelt wrote:
* Graham Leggett [EMAIL PROTECTED] wrote:
snip
You forget that there is a trust issue here. SSL brings with it not only
encryption, but certification of the data that's being sent. If the SSL
protocol somehow allowed external unprotected and
Enrico Weigelt wrote:
* William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
snip
http://www.ietf.org/rfc/rfc2817.txt
spells out methods that the server can -insist- that an upgraded
connection is used, and the client can instigate an upgraded
connection as well even if the server doesn't require it.
But
Sander Temme wrote:
S. (Wants to know which CA signs wildcard certificates and is
trusted by a reasonable fraction of the installed base.
He'd love to have one.)
I think Thawte do/did them - but it was a while ago when I last found
out about them. They were expensive though compared to
Enrico Weigelt wrote:
What fools are sitting there in the IETF ?!
Couldn't they just define a new protocol (probably running on its
own port) which allows specifying additional headers *before*
SSL handshake starts or another SSL version, which allows passing
additional info from client-server
Enrico Weigelt wrote:
... its time to completely redesign HTTP ...
Hey Enrico, it might be quicker if you listed the things you -do- like :)
On Dec 18, 2004, at 12:19 AM, Enrico Weigelt wrote:
What fools are sitting there in the IETF ?!
Fools that are highly aware of the hundreds of millions of web browser
installations out there that know nothing but the standard versions of
SSL/TLS and whose users cannot be forced to upgrade.
* William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
Hi,
Using another spec, connection upgrade TLS, it works perfectly,
but that spec is only supported by some printer drivers. No
http client supports TLS upgrade that I'm aware of.
where're the differences between SSL and TLS handshake ?
cu
--
* Dale Ghent [EMAIL PROTECTED] wrote:
Hi,
snip
With SSL, this HTTP request is already encrypted. The server will need
to have a way to figure out what SSL key to use to decrypt that HTTP
request, but can't do it unless it knows what host/site address the
request is for so it can use the
At 11:23 AM 12/17/2004, Enrico Weigelt wrote:
hmm, is it somehow possible to work with multiple cert on the
same socket ? does the SSL handshake leave any chance that probably
more then one cert can be tried, until someone matches ?
No. That isn't in the spec, and would be horribly
William A. Rowe, Jr. [EMAIL PROTECTED] writes:
Using a wildcard cert, this simply works, as long as the
common name pattern matches all server names.
are wildcard certs generally accepted by the current cohort of
browsers?
--
joe
* William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
snip
http://www.ietf.org/rfc/rfc2817.txt
spells out methods that the server can -insist- that an upgraded
connection is used, and the client can instigate an upgraded
connection as well even if the server doesn't require it.
But under no
On Dec 16, 2004, at 11:27 PM, Enrico Weigelt wrote:
Hi folks,
is name based virtual hosting ig. generally possible with SSL/https ?
No
As you know, name-based virtual hosting requires that the client supply
the desired site's hostname in the Host: header of the HTTP request.
With SSL, this HTTP
At 10:27 PM 12/16/2004, Enrico Weigelt wrote:
Hi folks,
is name based virtual hosting ig. generally possible with SSL/https ?
It's simultaneously impossible and entirely doable.
https handshakes to a cert's common name before the Host:
name field is determined, which is guaranteed to be wrong
19 matches
Mail list logo
