httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tony Di Croce <dicr...@gmail.com>
Subject Re: [users@httpd] https problem
Date Fri, 09 Dec 2005 15:15:57 GMT
Exactly. I realise that this is non optimal, but I need to be able to handle
secure transactions for a number of clients being served from the same
hardware... And it's not like I'm the first person to do this... In fact,
it's pretty common...

    td

On 12/7/05, Boyle Owen <Owen.Boyle@swx.com> wrote:
>
> 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
>
>


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

Mime
View raw message