At 08:38 AM 12/22/2004, 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 an
* 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
> > inform
n-specific 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 bas
On Wed, 2004-12-22 at 15:44 +0100, Enrico Weigelt wrote:
> * Ben Laurie <[EMAIL PROTECTED]> wrote:
>
>
> > 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 t
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
* Ben Laurie <[EMAIL PROTECTED]> wrote:
> 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 u
* 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
>
* 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
> (like the name of the vir
Enrico Weigelt wrote:
* William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
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 un
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 nor
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.
Also,
Enrico Weigelt wrote:
... its time to completely redesign HTTP ...
Hey Enrico, it might be quicker if you listed the things you -do- like :)
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 bef
* William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> 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 n
"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
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 ineffici
* Dale Ghent <[EMAIL PROTECTED]> wrote:
Hi,
> 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
* 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
On Fri, Dec 17, 2004 at 05:27:50AM +0100, Enrico Weigelt wrote:
> is name based virtual hosting ig. generally possible with SSL/https ?
>
The SSL faq has the explanation -
http://httpd.apache.org/docs-2.0/ssl/ssl_faq.html#vhosts2
vh
Mads Toftum
--
`Darn it, who spiked my coffee with
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
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
Hi folks,
is name based virtual hosting ig. generally possible with SSL/https ?
cu
--
-
Enrico Weigelt== metux IT service
phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207
* john smith <[EMAIL PROTECTED]> wrote:
> Actually I thought you should have kept your mouth shut
> rather than bullying somebody else.
> You clearly could do with going to the user line before you "promote"
> yourself
> and or demote others. ;(
Huh? I can't see where he was bullying someone. Th
On Wed, 15 Oct 2003, john smith wrote:
> Actually I thought you should have kept your mouth shut rather than
> bullying somebody else. You clearly could do with going to the user line
> before you "promote" yourself and or demote others. ;(
I'm very confused by this statement... was I bullying?
Actually I thought you should have kept your mouth shut
rather than bullying somebody else.
You clearly could do with going to the user line before you "promote"
yourself
and or demote others. ;(
[EMAIL PROTECTED] wrote:
On Wed, 15 Oct 2003, Joshua Slive wrote:
Oops. Actually, the argument
On Wed, 15 Oct 2003, Joshua Slive wrote:
> Oops. Actually, the argument to should match the argument
> to NameVirtualHost; ie. an IP address or "*". In this case, the two
> directives don't match, which could be part of the problem.
> Hostnames shouldn't be used because they create unnecessary
On Wed, 15 Oct 2003, Cliff Woolley wrote:
> On Wed, 15 Oct 2003, EMRE KUNT (Ebi Bsk. - Sistem Prog) wrote:
>
> > I added the lines, below, to httpd.conf file. It doesnt work. What is wrong?
>
> Please direct this kind of question to the user support mailing list; see
> http://httpd.apache.org/use
On Wed, 15 Oct 2003, EMRE KUNT (Ebi Bsk. - Sistem Prog) wrote:
> I added the lines, below, to httpd.conf file. It doesnt work. What is wrong?
Please direct this kind of question to the user support mailing list; see
http://httpd.apache.org/userslist.html .
(Hint: your lines should not have a '*
com on his browser, i want my Apache to
serve from "apache_home/htdocs/host2/" directory.
To achieve this goal, i use name based virtual hosting (is this wright
choice?).
I added the lines, below, to httpd.conf file. It doesnt work. What is wrong?
Thanks and best regards,
Emre KU
I hope y'all don't mind my posting here as I'm not an Apache developer.
However I think this may be of interest anyway, and only you guys are
likely to know the answer.
I'm aiming to be a sort of ISP, providing, among other things, name
based virtual hosting. I.e., there&#
Thanks Cliff... that was the kind of feedback I was looking for.
Guess I'll have to wait for 2.0.
BTW you guys are the greatest!
-- Rod
On Thursday 25 October 2001 06:21 pm, Cliff Woolley wrote:
> On Thu, 25 Oct 2001, Rod Roark wrote:
> > Um, how? It's clear that all scripts will run as user a
On Thu, 25 Oct 2001, Rod Roark wrote:
> Um, how? It's clear that all scripts will run as user apache,
> but the whole point is that if you don't know the other user's
> documentroot name
Well, I'd kind of missed that you were counting on the 711 directory
permissions. But still...
> then you
Cliff Woolley said:
> On Thu, 25 Oct 2001, Rod Roark wrote:
>
>> I did come up with a possible solution. However I'm not sure if it's complete
>> garbage, mildly useful, or really interesting. That's why I'm posting here.
>>
>> Then, /opt/www/users looks like this:
>>
>> drwx--x--x root r
On Thu, 25 Oct 2001, Rod Roark wrote:
> I did come up with a possible solution. However I'm not sure if it's
> complete garbage, mildly useful, or really interesting. That's why
> I'm posting here.
>
> Then, /opt/www/users looks like this:
>
> drwx--x--x root root .
> drwxrwx--- s
OK, time for a break from the normal routine. :-)
This concerns "name based" virtual hosting. I.e., with just one IP
address.
The problem is how do you give your users access to PHP, servlets,
CGI, etc. and still keep them somewhat secure from each other's
potential misch
y, September 22, 2001 11:41 AM
Subject: Re: general/8118: IPv6 based "virtual" hosting don't work (one httpd serves
more IPv6 addresses) (fwd)
> Hi,
>
> because I don't know how to update an existing (still occuring) bug,
> here is more information - ho
36 matches
Mail list logo
