httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Boyle Owen" <Owen.Bo...@swx.com>
Subject RE: [users@httpd] https problem
Date Wed, 07 Dec 2005 08:25:57 GMT
Plain text please...

I'm sure your doing this for the best of reasons, but you are actually doing exactly what
someone who was trying to spoof a site would do (see http://en.wikipedia.org/wiki/Spoofing_attack)...

The point is that HTTPS provides more than just encryption of the data in transit; it also
*authenticates* the website. So you can be sure that the site you are submitting your credit-card
number to is really the site you typed into the browser. If you redirect to a different site,
you break this. 

Of course, you can put a banner on a.com and b.com which says, "All our e-commerce activity
is handled by c.com" and then customers have a reassurance that when they go to c.com, they
are on the right site (this is basically what clients of e-commerce sites like WorldPay do).

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

-----Original Message-----
From: Tony Di Croce [mailto:dicroce@gmail.com]
Sent: Dienstag, 6. Dezember 2005 19:04
To: users@httpd.apache.org
Subject: Re: [users@httpd] https problem


I agree it is non-optimal...

But short of implementing something like user mode linux, its the best way to do what I need
to do...

BTW, I plan on making nice-shop.com forward information to "nasty-hacker.com" that allows
nasty-hacker.com to render the page so that it looks like it came rom nice-shop.com...

    td


On 12/6/05, Boyle Owen <Owen.Boyle@swx.com> wrote:
Plain text please...

>a.com and b.com https link to c.com, so the users browser URL will change,
>and the certs will be registered to c.com... So I guess I don't see how
>they're getting mismatched?

OK - if you redirect you won't get a browser warning. But it still looks a bit fishy to a
suspicious web-surfer (should be everybody). You're on a site called www.nice-shop.com and
when you hit, "Go to checkout", the URL changes to www.nasty-hacker.com. OK - not really...
but the fact that the URL has changed at all is discouraging. How does your customer know
*definitatively* that a.com and c.com are related? The only way to be sure of the identity
of a website is to check the certificate and your certificate vouchsafes c.com - not a.com...

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


-----Original Message-----
From: Tony Di Croce [mailto: dicroce@gmail.com]
Sent: Dienstag, 6. Dezember 2005 15:42
To: users@httpd.apache.org
Subject: Re: [users@httpd] https problem



Hmm...

But why would the URL in the browser not match the name in the SSL cert? They would match...

a.com and b.com are port 80 VH's
c.com is a port 443 VH (with SSL certs installed)

a.com and b.com https link to c.com, so the users browser URL will change, and the certs will
be registered to c.com... So I guess I don't see how they're getting mismatched?

   td


On 11/24/05, Boyle Owen <Owen.Boyle@swx.com> wrote:
Plain text please...

Assume you set up two or more name-based VHs on port 80 (plain HTTP). Then you set up a single
SSL VH on port 443. Now, HTTPS to any domain will go to the SSL VH.

SSL will "work" in that you won't get an error and the session will be encrypted but you will
get *warnings* that the URL in the browser doesn't match the site name in the SSL certificate.
This is not very useful for e-commerce... (would you type in your credit card number on a
site called "nice-shop" when the browser was warning you that the cert belonged to "nasty-hacker"?)

If you try to add additional SSL VHs, apache will always use the certificate from the first
SSL VH to establish a session so you still get warnings.

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


-----Original Message-----
From: Tony Di Croce [mailto: dicroce@gmail.com]
Sent: Donnerstag, 24. November 2005 00:43
To: users@httpd.apache.org
Subject: Re: [users@httpd] https problem



I assume a.com and b.com resolve to the same IP address.
If so, https to either domain will go to <IP address>:443.
Remember that SSL cannot use the Hostname to distinguish sites, so the two requests look the
same to apache and so you get the first VH on IP:443.

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

I have been planning to build a server with multiple virtual hosts. The idea is that each
host could have web stores, but when it came time to actually get credit card info, they would
forward you to the one host on the box that was on port 443 (via an https link)... This page
would get the card number and process the order... Of course, when they go to this page, the
domain in the URL in their browser would change... but thats OK...

This should work, right?



--
Free Linux Technical Articles
http://www.linuxtecharticles.com
Diese E-mail ist eine private und persönliche Kommunikation. Sie hat keinen Bezug zur Börsen-
bzw. Geschäftstätigkeit der SWX Gruppe. This e-mail is of a private and personal nature.
It is not related to the exchange or business activities of the SWX Group. Le présent e-mail
est un message privé et personnel, sans rapport avec l'activité boursière du Groupe SWX.


This message is for the named person's use only. It may contain confidential, proprietary
or legally privileged information. No confidentiality or privilege is waived or lost by any
mistransmission. 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. You must not, directly or indirectly, use, disclose,
distribute, print, or copy any part of this message if you are not the intended recipient.
The sender's company reserves the right to monitor all e-mail communications through their
networks. Any views expressed in this message are those of the individual sender, except where
the message states otherwise and the sender is authorised to state them to be the views of
the sender's company.

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





--
Free Linux Technical Articles
http://www.linuxtecharticles.com

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





-- 
Free Linux Technical Articles
http://www.linuxtecharticles.com 

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


Mime
View raw message