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@xxxxxxxxx ]
Sent: Dienstag, 6. Dezember 2005 19:04
To: users@xxxxxxxxxxxxxxxx
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@xxxxxxx> 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@xxxxxxxxx]
Sent: Dienstag, 6. Dezember 2005 15:42
To: users@xxxxxxxxxxxxxxxx
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@xxxxxxx> 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@xxxxxxxxx]
Sent: Donnerstag, 24. November 2005 00:43
To: users@xxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxx
" from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
--
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@xxxxxxxxxxxxxxxx
" from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
--
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@xxxxxxxxxxxxxxxx
" from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|