Mailing-List: contact users-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@httpd.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Content-class: urn:content-classes:message
Importance: normal
Priority: normal
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 22 Jul 2009 15:26:29 +0200
Message-ID: 
 <FDD5D99066749040AF9098A720E98977080B775F@CIWMEXZSA0E.ex.ordersx.org>
In-Reply-To: <4A670F85.2050906@ice-sa.com>
Thread-Topic: [users@httpd]  Re: Low priced certificate?
Thread-Index: AcoKzdyjKFfsip6RTQGyyVt/+vpn9wAAH73Q
References: <h45jve$opp$1@ger.gmane.org> <20090722102857.GD75102@univie.ac.at>
 <h4707d$6hk$1@ger.gmane.org>
 <FDD5D99066749040AF9098A720E98977080B775E@CIWMEXZSA0E.ex.ordersx.org>
 <4A670F85.2050906@ice-sa.com>
From: "Boyle Owen" <Owen.Boyle@six-group.com>
To: <users@httpd.apache.org>
Subject: RE: [users@httpd]  Re: Low priced certificate?

> -----Original Message-----
> From: Andr=E9 Warnier [mailto:aw@ice-sa.com]=20
> Sent: Wednesday, July 22, 2009 3:09 PM
> To: users@httpd.apache.org
> Subject: Re: [users@httpd] Re: Low priced certificate?
>=20
>=20
> We are a services company, and provide websites to select=20
> customers, for=20
> their own usage. We know these customers, they know us, and there are=20
> not thousands of them (merely hundreds).
> We store information in these websites for those customers. =20
> Sometimes=20
> this information is relatively private, for the customer.
> (It is not however of the "top secret - defense" variety, nor banking=20
> etc...)
>=20
> We would like to offer to our customers, the possibility of=20
> connecting=20
> to their websites using HTTPS instead of HTTP.
> This is merely so that it would be harder for "foreign"=20
> people to easily=20
> intercept the data being exchanged between the webserver and the=20
> browsers of our customers.

If you have a "private" application (in the sense that server-owner and =
clients already know each other and only want to encrypt traffic), then =
of course you can use a self-signed cert. In this case you are getting =
encryption (protection from eavesdropping) but no authentication (which =
you don't care about because you already know each other).

The cause of much of the confusion is the fact that SSL certs provide =
*two* functions; they contain a key that allows you to set up an =
encrypted channel, but they also contain a document that attests the =
ownership of the domain. This second feature is essential in an =
e-commerce environment where the server and client are not known to each =
other a priori.=20

If you were a shopkeeper and wanted to send your takings off to the =
bank, you might request the bank to send round a security van. When the =
van arrives, would you check the driver's credentials? Obviously you =
should in case some crooks were tapping your phone line and had turned =
up first in a stolen van with fake uniforms. If you don't check the =
credentials, your money will be safe in transit, but might not actually =
be going to the bank :-)

Rgds,
Owen Boyle
Disclaimer: Any disclaimer attached to this message may be ignored.=20

>=20
> It is my understanding that we could set up our own "certificate=20
> authority" (CA) and create our own server certificates.  A customer=20
> browser, upon the first connection, would pop up some message=20
> indicating=20
> that it cannot verify this certificate, and offering maybe to=20
> "authorise" our own CA as a valid one.  Once they did this, the popup=20
> would not happen again, and their communications with the=20
> website would=20
> be encrypted (which is the main point of the exercise).
>=20
> I understand that, in case their DNS system is compromised,=20
> they could=20
> land onto another website pretending to be ours, and thus accept this=20
> other website certificate and CA.
> But I consider this possibility as relatively unlikely, and easily=20
> detected by the customers themselves once they proceed. (*)
>=20
> Is anything wrong with the above thinking ?
>=20
> Thanks for comments.
>=20
>=20
> (*) because each customer application is specific, and in=20
> order to fool=20
> a customer, the miscreant would haver to duplicate this=20
> application, the=20
> data etc..
>=20
> ---------------------------------------------------------------------
> The official User-To-User support forum of the Apache HTTP=20
> 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
>=20
>=20
=20
This message is for the named person's use only. It may contain =
confidential, proprietary or legally privileged information. If you =
receive this message in error, please notify the sender urgently and =
then immediately delete the message and any copies of it from your =
system. Please also immediately destroy any hardcopies of the message.=20
The sender's company reserves the right to monitor all e-mail =
communications through their networks.

---------------------------------------------------------------------
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