Re: [PHP] https question

[Daniel Brown]

On Wed, Sep 25, 2013 at 1:55 PM, Tedd Sperling  wrote:
> Hi gang:
>
> I have a client who had his entire site moved to another host -- no big 
> problem.
>
> However, the old site had a https directory, where I had secure scripts to do 
> credit-card transactions, but the new site doesn't have a https directory -- 
> in fact it doesn't even have a http directory at all. So, what options do I 
> have to do secure transactions?
>
> I remember someone saying that this could be done via a .htaccess file, but I 
> don't have the code, nor am I positive this is the answer.
>
> What do you recommend?

Sounds like it may have been moved from a Plesk server to a
non-Plesk server (or something using a similar path setup).  If it's
still Apache-based, yes, an .htaccess mod_rewrite directive should
suffice.  And, while it's out-of-scope for this list, an example, for
posterity:

# .htaccess - placed in the web root
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [QSA,R,L]


-- 

Network Infrastructure Manager
http://www.php.net/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https question

[Joshua Kehn]

On Sep 25, 2013, at 2:24 PM, Tedd Sperling  wrote:
> 
> I understand that cc processing should be done via https.
> 
> Normally, that means to me that I place my $ scripts in a https directory -- 
> the problem is that I don't have one with this host.
> 
> So, I am asking how does one do that with a https directory?
> 
> Thanks,
> 
> tedd
> ___
> tedd sperling
> tedd.sperl...@gmail.com
> 


I'm saying the site should be served entirely under HTTPS. There shouldn't be 
separate https/http directories. Apache (or whatever your web server is) has a 
certificate installed on it and that vhost is configured to only respond to 
https requests. Typically this also means running a separate vhost on http that 
redirects to the https variant.

Where is this new host? It should be a dedicated box (vps or other) due to how 
the certificates need to be issued (dedicated ip address).

Best,

–Josh

Joshua Kehn | @joshkehn 
http://joshuakehn.com


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https question

[Tedd Sperling]

On Sep 25, 2013, at 1:58 PM, Joshua Kehn  wrote:

> On Sep 25, 2013, at 1:55 PM, Tedd Sperling  wrote:
> 
>> Hi gang:
>> 
>> I have a client who had his entire site moved to another host -- no big 
>> problem.
>> 
>> However, the old site had a https directory, where I had secure scripts to 
>> do credit-card transactions, but the new site doesn't have a https directory 
>> -- in fact it doesn't even have a http directory at all. So, what options do 
>> I have to do secure transactions?
>> 
>> I remember someone saying that this could be done via a .htaccess file, but 
>> I don't have the code, nor am I positive this is the answer.
>> 
>> What do you recommend?
>> 
>> Thanks,
>> 
>> tedd
> 
> Did you setup the server (Apache / nginx) configuration? The entire site 
> should be served under https if you're doing CC processing
> 
> Best,
> 
> –Josh

I understand that cc processing should be done via https.

Normally, that means to me that I place my $ scripts in a https directory -- 
the problem is that I don't have one with this host.

So, I am asking how does one do that with a https directory?

Thanks,

tedd
___
tedd sperling
tedd.sperl...@gmail.com


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https question

[Joshua Kehn]

On Sep 25, 2013, at 1:55 PM, Tedd Sperling  wrote:

> Hi gang:
> 
> I have a client who had his entire site moved to another host -- no big 
> problem.
> 
> However, the old site had a https directory, where I had secure scripts to do 
> credit-card transactions, but the new site doesn't have a https directory -- 
> in fact it doesn't even have a http directory at all. So, what options do I 
> have to do secure transactions?
> 
> I remember someone saying that this could be done via a .htaccess file, but I 
> don't have the code, nor am I positive this is the answer.
> 
> What do you recommend?
> 
> Thanks,
> 
> tedd

Did you setup the server (Apache / nginx) configuration? The entire site should 
be served under https if you're doing CC processing

Best,

–Josh

Joshua Kehn | @joshkehn 
http://joshuakehn.com


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https help

[Negin Nickparsa]

Thank you

Re: [PHP] https help

[Tamara Temple]

On May 31, 2011, at 12:34 AM, Negin Nickparsa wrote:


I need to create a login page with HTTPS to yahoo
Do I have to have a valid certificate?

I have  not trust certification centre, so before anything under  
HTTPS will
be shown up, the window will come with information: valid  
certificate: yes,

valid domain: yes, valid authority for SSL key: no.
am I right?
https://www.yahoo.com/";;
//addy querystring, if appropriate
if(count($_GET) != 0) {
$url .= "?";
foreach($_GET as $key => $value) {
$url .= "$key=$value&";
}
}
//send permanent move redirect
header($url, true, 301);
}
?>
but it goes to http://www.yahoo.com


I don't have an answer to your question, but you should look at  
http_build_query: http://us.php.net/manual/en/function.http-build-query.php 
 for the last part of your code. It makes the query string safe for  
transmittal.


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https help

[viraj]

yahoo don't have ssl enabled on all their content it seems.

http://privacy.yahoo.com/privacy/us/security/details.html


~viraj


On Tue, May 31, 2011 at 11:11 AM, Negin Nickparsa  wrote:
> it is the output:
> http://www.yahoo.com/?s=https
>
> can i force it to show me
> https://www.yahoo.com
>
> ?
>

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https help

[Negin Nickparsa]

it is the output:
http://www.yahoo.com/?s=https

can i force it to show me
https://www.yahoo.com

?

Re: [PHP] https help

[Negin Nickparsa]

I need to create a login page with HTTPS to yahoo
Do I have to have a valid certificate?

I have  not trust certification centre, so before anything under HTTPS will
be shown up, the window will come with information: valid certificate: yes,
valid domain: yes, valid authority for SSL key: no.
 am I right?
https://www.yahoo.com/";;
//addy querystring, if appropriate
if(count($_GET) != 0) {
$url .= "?";
foreach($_GET as $key => $value) {
$url .= "$key=$value&";
}
}
//send permanent move redirect
header($url, true, 301);
}
?>
but it goes to http://www.yahoo.com

RE: [PHP] https help

[admin]

Negin,
That is pretty vague. 
More details please




Richard L. Buskirk
Senior Software Engineer/Systems Administrator

You can't grow your business with systems that are on life support...


-Original Message-
From: Negin Nickparsa [mailto:nickpa...@gmail.com] 
Sent: Monday, May 30, 2011 4:04 PM
To: php-general@lists.php.net
Subject: [PHP] https help

hi all,
I want to write an application that can be logged to yahoo.com using https
protocol
Would  you please put me some suggestions and advices?

if ($_SERVER['SERVER_PORT'] != 443) {
header("Location: https://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI']);
}


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] HTTPS SSL

[Gaurav Kumar]

Jordan,

Do you have a shared hosting? i.e. you must have hosted your site/page on
some server.

Most of the hosting server these days provide you with the feature of
installing SSL certificate.

So what you need is-

Buy a SSL certificate from a vendor. There are so many of them available
these days OR enquire with your hosting provider that if they provide a SSL
(may be a free SSL).

The certificate comes with a "KEY" (bunch of encrypted charcters). Put in
the key in your hosting panel SSL feature.

Also some server restrict the SSL to Static IP or may provide you with a
Shared SSL.

Thanks,

Gaurav Kumar

http://www.UncleCode.Com 
Download Scripts, Resources For Free
http://www.unclecode.com/2010/08/how-to-use-post-method-request-in-php-curl-execute-http-post-method-in-php-curl/
http://www.unclecode.com/2010/08/how-to-send-an-attachment-in-an-email-using-php-php-send-email-with-attachment/
http://www.unclecode.com/2009/10/mpdf-create-pdf-from-html-using-php-on-the-fly/



On Thu, Sep 2, 2010 at 5:21 PM, Jordan Jovanov wrote:

> Hello everybody
>
> I need me a little help.
> I have one web page with hhtp protocol, but i need to change in https.
> Somebody tell me that I need to create some SSL certificate.
> I  use some Apache server.
> Do you somebody know does is easy and can i do?
> Does need to write some php scripts or anything?
>
> Thanks a lot.
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
Thanks,

Gaurav Kumar

http://www.UncleCode.Com
Download Scripts, Resources For Free

Re: [PHP] HTTPS SSL

[Andy McKenzie]

Jordan,

  Bostjan hit the main points, but if you're trying to run a secure
server, you probably ought to know more about it than you do now.
It's pretty easy to arrange a secure connection that isn't actually
secure if you don't know what you're doing.  I'd recommend a good
Apache book -- I have one that I found quite helpful from WROX press,
and I'm sure O'Reilly has one as well.  There are probably other
companies with good books out, but those are the ones I know off-hand
that I'd trust.

-Alex

On Thu, Sep 2, 2010 at 7:51 AM, Jordan Jovanov  wrote:
> Hello everybody
>
> I need me a little help.
> I have one web page with hhtp protocol, but i need to change in https.
> Somebody tell me that I need to create some SSL certificate.
> I  use some Apache server.
> Do you somebody know does is easy and can i do?
> Does need to write some php scripts or anything?
>
> Thanks a lot.
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] HTTPS SSL

[Bostjan Skufca]

You should look up something like "openssl how to create self signed
certificate" on google. Once cert is created, you should look up "apache ssl
howto". The rest is just following instructions intelligently. Or use a
consulting company.

b.

PS: This has nothing to do with PHP, in case you haven't noticed :)


On 2 September 2010 13:51, Jordan Jovanov  wrote:

> Hello everybody
>
> I need me a little help.
> I have one web page with hhtp protocol, but i need to change in https.
> Somebody tell me that I need to create some SSL certificate.
> I  use some Apache server.
> Do you somebody know does is easy and can i do?
> Does need to write some php scripts or anything?
>
> Thanks a lot.
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP] HTTPS

[Ashley Sheridan]

On Sun, 2010-08-01 at 13:29 +0200, Jordan Jovanov wrote:

> Hello
> 
> I have one web page with hhtp protocol, but i need to change in https.
> Do you somebody know does is easy and can i do?
> Does need to write some php scripts or anything.
> 
> Thanks a lot.
> 


You need to set up a security certificate. You can create an unsigned
one yourself, but visitors will be warned that it is unsigned when they
attempt to go there. You can buy one quite cheaply, but it might depend
on the hosting you have. Some hosting will only support you installing
certificates through them, which generally costs more.

Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: [PHP] https setup

[Michael A. Peters]

PJ wrote:


Don't forget, you have to have a certificate, real or dummy for this to
work. :-)




Note that Firefox makes things difficult for non tech users with self 
signed certs, so for a live site open to the public, you really do want 
to spend the dough on a certificate from an authority.


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https setup

[PJ]

Shanon Swafford wrote:
>> -Original Message-
>> From: PJ [mailto:af.gour...@videotron.ca] 
>> Sent: Thursday, June 04, 2009 3:59 PM
>> To: php-general@lists.php.net
>> Subject: [PHP] https setup
>>
>> Can't find anything on G or web - but I probably didn't try hard enough.
>> I am unable to set my virtual hosts to handle https.
>> I have apache22, mod_ssl, opnenssl and the httpd and httpd-vhosts.conf
>> files are set up "correctly" but directing a sensitive user information
>> page to an HTTPS page returns an error of "not found". The virtual hosts
>> works fine, except for HTTPS.
>> This is on my intranet for local developing.
>> TIA
>> 
>
> 
> -
>
> >From what I've found, it doesn't work like http.  You can NOT do virtual
> hosts via https with apache listening on the same IP AND PORT.  Something
> about the encrypted session is set up before the domain is analyzed by
> apache.
>
> You have to have a unique IP or PORT for each domain you want to serve with
> https.
>
> For example, if you want:
> https://example1.com
>  and
> https://example2.com
>
> all on the same http server, you have to either:
>
> assign a separate IP for each domain and let apache do the vhost by IP
>  or
> define a separate PORT for each domain and make apache do the vhost by PORT.
>
> If I'm wrong, somebody please let me know because I'd love to do vhosts like
> this as well.
>
> Regards,
> Shanon
>
>
>   
I solved my problem. Problem was unclear directions for setup;
httpd-ssl.conf and httpd-vhosts.conf were not properly explalin for
configuration. The secure setup is done in the ssl file with the 443
port and the same host is repeated in the vhost file.  I haven't
mentioned this, but my setup is with name-based vhosts, not address or
whatever...
So far as I can see, this should work fine for numerous hosts both on
whatever ports you choose plus the default 443 for ssl.
Don't forget, you have to have a certificate, real or dummy for this to
work. :-)


-- 
Hervé Kempf: "Pour sauver la planète, sortez du capitalisme."
-
Phil Jourdan --- p...@ptahhotep.com
   http://www.ptahhotep.com
   http://www.chiccantine.com/andypantry.php


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https setup

[PJ]

Per Jessen wrote:
> PJ wrote:
>
>   
>> Can't find anything on G or web - but I probably didn't try hard
>> enough. 
>> 
>
> Correct :-)
>
>   
>> I am unable to set my virtual hosts to handle https. 
>> I have apache22, mod_ssl, opnenssl and the httpd and httpd-vhosts.conf
>> files are set up "correctly" but directing a sensitive user
>> information page to an HTTPS page returns an error of "not found". The
>> virtual hosts works fine, except for HTTPS.
>> This is on my intranet for local developing.
>> 
>
> Is your webserver listening for https requests?  Port 443, check it
> with "netstat -ltn".  Or check your "listen.conf" file.
>
> /Per
>
>   
Thanks for responding.
The problem was muddy instructions for the setup. I finally figure it out.

-- 
Hervé Kempf: "Pour sauver la planète, sortez du capitalisme."
-
Phil Jourdan --- p...@ptahhotep.com
   http://www.ptahhotep.com
   http://www.chiccantine.com/andypantry.php


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https setup

[PJ]

Michael A. Peters wrote:
> PJ wrote:
>> Can't find anything on G or web - but I probably didn't try hard enough.
>> I am unable to set my virtual hosts to handle https.
>> I have apache22, mod_ssl, opnenssl and the httpd and httpd-vhosts.conf
>> files are set up "correctly" but directing a sensitive user information
>> page to an HTTPS page returns an error of "not found". The virtual hosts
>> works fine, except for HTTPS.
>> This is on my intranet for local developing.
>> TIA
>>
>
> By "not found" do you mean a 404 error from the https domain?
> If so, then you probably just have the DocumentRoot directive set up
> incorrectly for your secure domain.
>
The problem was and remains in httpd-ssl.conf. It is not at all  clear
how the ssl.conf and the vhosts.conf files are related. The same site is
entered in https-ssl.conf and in httpd-vhosts.conf but uner different
ports *:80 and :*:443.
What is rather annoying is that in the ssl-conf file there is a dummy
setup but it does not indicate that this is what you have to change -
rather than the vhosts file. Nothing like having the blind leading the
blind. ;-)
I solved my immediate problem by modifying the httpd-ssl.conf file; up
to then I understood that the the configuration for vhosts depended on
the port where vhosts was pointing. Now, what is not clear is whether I
need to add more entries in the httpd-ssl.conf file for the other sites;
I would assume yes.
Thanks for responding. PJ

-- 
Hervé Kempf: "Pour sauver la planète, sortez du capitalisme."
-
Phil Jourdan --- p...@ptahhotep.com
   http://www.ptahhotep.com
   http://www.chiccantine.com/andypantry.php


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https setup

[Michael A. Peters]

PJ wrote:

Can't find anything on G or web - but I probably didn't try hard enough.
I am unable to set my virtual hosts to handle https.
I have apache22, mod_ssl, opnenssl and the httpd and httpd-vhosts.conf
files are set up "correctly" but directing a sensitive user information
page to an HTTPS page returns an error of "not found". The virtual hosts
works fine, except for HTTPS.
This is on my intranet for local developing.
TIA



By "not found" do you mean a 404 error from the https domain?

If so, then you probably just have the DocumentRoot directive set up 
incorrectly for your secure domain.


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https setup

[Per Jessen]

PJ wrote:

> Can't find anything on G or web - but I probably didn't try hard
> enough. 

Correct :-)

> I am unable to set my virtual hosts to handle https. 
> I have apache22, mod_ssl, opnenssl and the httpd and httpd-vhosts.conf
> files are set up "correctly" but directing a sensitive user
> information page to an HTTPS page returns an error of "not found". The
> virtual hosts works fine, except for HTTPS.
> This is on my intranet for local developing.

Is your webserver listening for https requests?  Port 443, check it
with "netstat -ltn".  Or check your "listen.conf" file.

/Per

-- 
Per Jessen, Zürich (20.2°C)


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https and Credit Cards

[דניאל דנון]

You are right - Decline the job, you don't want any credit-card stealing on
your head

On Wed, Apr 15, 2009 at 1:10 PM, Richard Heyes  wrote:

> Hi,
>
> > To add to what others have said: CC processors with which I have worked
> will
> > audit your site *before* certifying your site to accept CC information.
> In
> > other words, if you don't do SSL, you won't be *allowed* to process
> cards.
>
> FWIW, companies exist that will host your "buy" page(s), so  you don't
> end up with the hassle of buying and installing your own SSL
> certificate.
>
> --
> Richard Heyes
>
> HTML5 Canvas graphing for Firefox, Chrome, Opera and Safari:
> http://www.rgraph.net (Updated April 11th)
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP] https and Credit Cards

[Richard Heyes]

Hi,

> To add to what others have said: CC processors with which I have worked will
> audit your site *before* certifying your site to accept CC information. In
> other words, if you don't do SSL, you won't be *allowed* to process cards.

FWIW, companies exist that will host your "buy" page(s), so  you don't
end up with the hassle of buying and installing your own SSL
certificate.

-- 
Richard Heyes

HTML5 Canvas graphing for Firefox, Chrome, Opera and Safari:
http://www.rgraph.net (Updated April 11th)

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https and Credit Cards

[phphelp -- kbk]

On Apr 13, 2009, at 10:19 PM, Skip Evans wrote:

But doesn't also the form need to be secure since you're sending CC  
information from that form back to the web site's server?


That's what I've always assumed.

I need some opinions on this, and if I'm right I think the client  
will defer to a few more votes.


To add to what others have said: CC processors with which I have  
worked will audit your site *before* certifying your site to accept  
CC information. In other words, if you don't do SSL, you won't be  
*allowed* to process cards.


Ken



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https and Credit Cards

[Leonard Burton]

Sounds like your client wants to end up listed in a Terminated Merchant File.


On Mon, Apr 13, 2009 at 11:19 PM, Skip Evans  wrote:
> Hey all,
>
> I've always put any forms that collect credit card information behind a
> secure connection, https, figuring that sending that information from the
> client browser to the server should be secure, but I'm having convincing a
> client that it is necessary.
>
> He instead insists that only the call to the credit card processor's server
> needs to be secure and of course the processor supplies the connection
> there.
>
> But doesn't also the form need to be secure since you're sending CC
> information from that form back to the web site's server?
>
> That's what I've always assumed.
>
> I need some opinions on this, and if I'm right I think the client will defer
> to a few more votes.
>
> --
> 
> Skip Evans
> Big Sky Penguin, LLC
> 503 S Baldwin St, #1
> Madison WI 53703
> 608.250.2720
> http://bigskypenguin.com
> 
> Those of you who believe in
> telekinesis, raise my hand.
>  -- Kurt Vonnegut
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



-- 
Leonard Burton, N9URK
http://www.jiffyslides.com
serv...@jiffyslides.com
leonardbur...@gmail.com

"The prolonged evacuation would have dramatically affected the
survivability of the occupants."

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https and Credit Cards

[Andrew Ballard]

On Mon, Apr 13, 2009 at 11:19 PM, Skip Evans  wrote:
> Hey all,
>
> I've always put any forms that collect credit card information behind a
> secure connection, https, figuring that sending that information from the
> client browser to the server should be secure, but I'm having convincing a
> client that it is necessary.
>
> He instead insists that only the call to the credit card processor's server
> needs to be secure and of course the processor supplies the connection
> there.
>
> But doesn't also the form need to be secure since you're sending CC
> information from that form back to the web site's server?
>
> That's what I've always assumed.
>
> I need some opinions on this, and if I'm right I think the client will defer
> to a few more votes.
>
> --

It is absolutely essential. The form itself should be encrypted using
SSL, and it should likewise only accept data that has been encrypted.
If not, smart consumers will simply purchase elsewhere because they
know their information is not being protected. In addition to lost
sales, your client (and possibly you) could also get hit on the other
end with penalties, increased processing fees, or loss of privileges
from his payment processor if they find out that the site is not
securing cardholder information.

You (and your client) should read up on PCI compiance.
http://www.pcicomplianceguide.org/

Andrew

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https and Credit Cards

[Richard Heyes]

Hi,

> I've always put any forms that collect credit card information behind a
> secure connection, https, figuring that sending that information from the
> client browser to the server should be secure, but I'm having convincing a
> client that it is necessary.
>
> He instead insists that only the call to the credit card processor's server
> needs to be secure and of course the processor supplies the connection
> there.
>
> But doesn't also the form need to be secure since you're sending CC
> information from that form back to the web site's server?

Yes. Any connection to you where your punter supplies CC details
should be secure. If the punters ISP runs a transparent proxy for
example, then these details could be easily captured if not sent over
a secure connection.

-- 
Richard Heyes

HTML5 Canvas graphing for Firefox, Chrome, Opera and Safari:
http://www.rgraph.net (Updated April 11th)

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https and Credit Cards

[Paul M Foster]

On Mon, Apr 13, 2009 at 10:19:34PM -0500, Skip Evans wrote:

> Hey all,
>
> I've always put any forms that collect credit card information
> behind a secure connection, https, figuring that sending that
> information from the client browser to the server should be
> secure, but I'm having convincing a client that it is necessary.
>
> He instead insists that only the call to the credit card
> processor's server needs to be secure and of course the
> processor supplies the connection there.
>
> But doesn't also the form need to be secure since you're
> sending CC information from that form back to the web site's
> server?
>
> That's what I've always assumed.
>
> I need some opinions on this, and if I'm right I think the
> client will defer to a few more votes.

You're absolutely right, no question, and for exactly the reasons you
give. The path back to the server from the client is unencrypted if you
don't use https, and the credit card information is in the clear when
transmitted.

In fact, if I were a hacker and found out that you were doing this, I'd
make it my business to hijack that connection so I could transparently
capture credit card information. I mean, for a hacker, that's just too
sweet a setup.

Incidentally, if he insists, I'd decline the job. Even if he signed
waiver after waiver to absolve you of responsibility (which I'd make him
sign), he could still go after you later when the consequences hit. Let
some less ethical coder do it the way he wants.

Paul

-- 
Paul M. Foster

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https forced redirect question

[Jim Lucas]

Robert Cummings wrote:

On Fri, 2008-02-15 at 15:05 -0500, Robert Cummings wrote:

On Fri, 2008-02-15 at 14:58 -0500, nihilism machine wrote:
why isnt this redirecting my page to https://www.mydomain.com instead  
the page stays at my domain.com

checkHTTPS();
$this->checkWWW();
$this->ServerName = $_SERVER['SERVER_NAME'];
}

// Check if HTTPS
public function checkHTTPS() {
if ($_SERVER['HTTPS'] != "on") {
$this->HTTPS = false;
} else {
$this->HTTPS = true;
}
}

// Redirect to HTTPS Site
public function HTTPSRedirect() {
if($this->HTTPS = false) {


Because you're assigning false. Some people switch the order of the
operands so that a typoe like this generates an order. Personally, I

  ^
Should be "error".

For some reason my finger to brain connection has been experiencing an
inordinate number of erroneous packets today.

Cheers,
Rob.


You should possibly try a reboot.  I have found that this helps, once in 
a while.


But also, in this case the OP could opt-out of assigning anything and 
just use this instead.


if ( $this->HTTPS ) {
...
}

He is already assigning a value either way it gets called

Jim Lucas

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https forced redirect question

[Robert Cummings]

On Fri, 2008-02-15 at 15:05 -0500, Robert Cummings wrote:
> On Fri, 2008-02-15 at 14:58 -0500, nihilism machine wrote:
> > why isnt this redirecting my page to https://www.mydomain.com instead  
> > the page stays at my domain.com
> >  > 
> > class URL {
> > 
> > // Public Variables
> > public $HTTPS;
> > public $ServerName;
> > public $WWW;
> > 
> > // Public Functions
> > 
> > public function __construct() {
> > $this->checkHTTPS();
> > $this->checkWWW();
> > $this->ServerName = $_SERVER['SERVER_NAME'];
> > }
> > 
> > // Check if HTTPS
> > public function checkHTTPS() {
> > if ($_SERVER['HTTPS'] != "on") {
> > $this->HTTPS = false;
> > } else {
> > $this->HTTPS = true;
> > }
> > }
> > 
> > // Redirect to HTTPS Site
> > public function HTTPSRedirect() {
> > if($this->HTTPS = false) {
> 
> 
> Because you're assigning false. Some people switch the order of the
> operands so that a typoe like this generates an order. Personally, I
  ^
Should be "error".

For some reason my finger to brain connection has been experiencing an
inordinate number of erroneous packets today.

Cheers,
Rob.
-- 
..
| InterJinn Application Framework - http://www.interjinn.com |
::
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for   |
| creating re-usable components quickly and easily.  |
`'

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https forced redirect question

[Robert Cummings]

On Fri, 2008-02-15 at 14:58 -0500, nihilism machine wrote:
> why isnt this redirecting my page to https://www.mydomain.com instead  
> the page stays at my domain.com
>  
> class URL {
> 
>   // Public Variables
>   public $HTTPS;
>   public $ServerName;
>   public $WWW;
>   
>   // Public Functions
>   
>   public function __construct() {
>   $this->checkHTTPS();
>   $this->checkWWW();
>   $this->ServerName = $_SERVER['SERVER_NAME'];
>   }
>   
>   // Check if HTTPS
>   public function checkHTTPS() {
>   if ($_SERVER['HTTPS'] != "on") {
>   $this->HTTPS = false;
>   } else {
>   $this->HTTPS = true;
>   }
>   }
>   
>   // Redirect to HTTPS Site
>   public function HTTPSRedirect() {
>   if($this->HTTPS = false) {


Because you're assigning false. Some people switch the order of the
operands so that a typoe like this generates an order. Personally, I
just live on the edge ;)

Cheers,
Rob.
-- 
..
| InterJinn Application Framework - http://www.interjinn.com |
::
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for   |
| creating re-usable components quickly and easily.  |
`'

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] HTTPS

[Richard Lynch]

On Mon, January 29, 2007 12:30 am, chetan rane wrote:
> i am writing a progrram for a Jabber COnnection manager. I want to
> access
> the client XML using HTTPS. do any one know a way to so it

http://php.net/curl
will get you through the S part of HTTPS nice and easy.

Mucking with the XML, you have a handful of choices ranging from
SimpleXML in PHP 5 to Ye Olde James Clark expat from early PHP 4
days...

If there's any way to use PHP 5, do so.  XML parsing in PHP 4 can be
tedious and downright painful, especially in the aforementioned James
Clark expat lib...

-- 
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] HTTPS

[Peter Lauri]

http://php.net/curl

Best regards,
Peter Lauri

www.dwsasia.com - company web site
www.lauri.se - personal web site
www.carbonfree.org.uk - become Carbon Free


-Original Message-
From: chetan rane [mailto:[EMAIL PROTECTED] 
Sent: Monday, January 29, 2007 8:31 AM
To: php-general@lists.php.net
Subject: [PHP] HTTPS

hi everyone

i am writing a progrram for a Jabber COnnection manager. I want to access
the client XML using HTTPS. do any one know a way to so it


Have any one the

-- 
Have A plesant Day
Chetan. D. Rane
Location: Pune , India
Contact: +91-9890792762
otherID: [EMAIL PROTECTED]
 [EMAIL PROTECTED]

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] HTTPS with NuSOAP

[Peter Lauri]

[snip]
> soapclient('https://webservices.netsuite.com/wsdl/v1_3_1/netsuite.wsdl');

The 's' in 'https' should be all that nuSOAP would need to know that
it should use SSL, if nuSOAP can do that.

[/snip]

Correct. NuSOAP do detect automatically, and if CURL is configured it will
work.

[snip]
> 'role internalId="theinternalid"'=>''));

Does that work to set the attribute?
[/snip]

It does not work, I figured out after many questions and a lot of digging in
the source code that I have to use soapval for that.

[snip]
> 2006-03-22 10:56:25.644283 soapclient: call: operation=LoginRequest,
> namespace=http://tempuri.org, soapAction=, rpcParams=, style=rpc,
> use=encoded, endpointType=soap

I have to wonder how the namespace tempuri.org got involved...
[/snip]

I am very new to SOAP, and I actually do not know what namespace really is
for the moment. Right now I am cheating a little and am using the SOAP
messages that MindReef's SOAPscore is generating for me automatically. I
want to learn more about SOAP, but there are few resources on the net.


[snip]
> HTTP method POST is not supported by this URL

This sounds to me like you've managed to use https/SSL, and are "in"
to the point of logging in, but something has convinced nuSOAP and/or
the WSDL that it should be using POST somewhere, and the server that's
handling the request don't like POST...

So maybe your question is how to get nuSOAP to use GET instead of POST.

Just guessing...
[/snip]

It was not about the url not liking POST, it was about the url not being
up-to-date. The documentation from NetSuite.com (the web service provider)
is so bad, their main income is from paid support, so they try to keep
documentation not good enough so that people are forced to buy from them.
But so far I have not needed to do that.

Thank you for your comments; you seem to be a darn knowledgeable person :)

/Peter

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] HTTPS with NuSOAP

[Peter Lauri]

[snip]
>
> 'account'=>'theaccountnumber',
>
> 'role internalId="theinternalid"'=>''));

Does that work to set the attribute?
[/snip]

You are correct, that does NOT work. I found out to use soapval instead.

Thank you!

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] HTTPS with NuSOAP

[Richard Lynch]

On Wed, March 22, 2006 1:41 am, Peter Lauri wrote:
> I am trying to use a Web Service on the following endpoint
> https://webservices.netsuite.com/wsdl/v1_3_1/netsuite.wsdl. As seen in
> the
> url, it is under HTTPS. I have compiled PHP with CURL and verified
> that CURL
> is working. In the documentation for NuSOAP I can not find how I set
> the
> soapclient to transmit via HTTPS.
>
>
>
> This is my code:
>
>
>
> 
> require_once('nusoap/lib/nusoap.php');
>
>
>
> $soapclient = new
>
> soapclient('https://webservices.netsuite.com/wsdl/v1_3_1/netsuite.wsdl');

The 's' in 'https' should be all that nuSOAP would need to know that
it should use SSL, if nuSOAP can do that.

> $login_info = array('passport'=>array(
>
> 'email'=>'myemail',
>
> 'password'=>'mypassword',
>
> 'account'=>'theaccountnumber',
>
> 'role internalId="theinternalid"'=>''));

Does that work to set the attribute?

> $soapclient->call('LoginRequest', $login_info);
>
>
>
> echo '';
>
>
>
> print_r($login_info);
>
>
>
> print_r($soapclient);
>
>
>
> echo '';
>
>
>
> ?>
>
>
>
> The full dump of the soapclient can be seen on
> http://devdws.com/soap/error.htm. This are parts of the dump that I
> think is
> valuable in solving this problem:
>
>
>
> 
>
>
>
> [error_str] => HTTP Error: Unsupported HTTP response status 405
> Method
> Not Allowed (soapclient->response has contents of the response)
>
> [debug_str] => 2006-03-22 10:56:25.644147 soapclient: instantiate
> SOAP
> with endpoint at
> https://webservices.netsuite.com/wsdl/v1_3_1/netsuite.wsdl
>
> 2006-03-22 10:56:25.644283 soapclient: call: operation=LoginRequest,
> namespace=http://tempuri.org, soapAction=, rpcParams=, style=rpc,
> use=encoded, endpointType=soap

I have to wonder how the namespace tempuri.org got involved...

> |
>
> |
>
> |
>
>
>
> [response] => HTTP/1.1 405 Method Not Allowed
>
> Date: Wed, 22 Mar 2006 03:56:26 GMT
>
> Server: Oracle-Application-Server-10g
>
> P3P: CP="CAO PSAa OUR BUS PUR"
>
> Vary: User-Agent
>
> Content-Length: 152
>
> Cache-Control: private
>
> Content-Type: text/html
>
>
>
> 405 Method Not Allowed
>
> HTTP method POST is not supported by this URL

This sounds to me like you've managed to use https/SSL, and are "in"
to the point of logging in, but something has convinced nuSOAP and/or
the WSDL that it should be using POST somewhere, and the server that's
handling the request don't like POST...

So maybe your question is how to get nuSOAP to use GET instead of POST.

Just guessing...

-- 
Like Music?
http://l-i-e.com/artists.htm

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] HTTPS with NuSOAP

[Angelo Zanetti]

I am trying to use a Web Service on the following endpoint
https://webservices.netsuite.com/wsdl/v1_3_1/netsuite.wsdl. As seen in the
url, it is under HTTPS. I have compiled PHP with CURL and verified that CURL
is working. In the documentation for NuSOAP I can not find how I set the
soapclient to transmit via HTTPS.



perhaps try the nuSOAP mailing list:

https://lists.sourceforge.net/lists/listinfo/nusoap-general

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https://...

[Robby Russell]

On Thu, 2004-10-28 at 11:01 -0500, Afan Pasalic wrote:
> Hi Robby,
> Yes, I looked at SERVER_PORT/SERVER_PROTOCOL. What I got is 80 and 
> HTTP/1.1 when I manually change http:// to https:// I'm getting 443 and 
> HTTP/1.1
> 
> I am not so good in this: you want to say that SSL use 443 port
> 
> -afan

There you go, the standard SSL port is 443. If you want to verify that
you are on 443, then you can use SERVER_PORT

-Robby


-- 
/***
* Robby Russell | Owner.Developer.Geek
* PLANET ARGON  | www.planetargon.com
* Portland, OR  | [EMAIL PROTECTED]
* 503.351.4730  | blog.planetargon.com
* PHP/PostgreSQL Hosting & Development
* --- Now supporting PHP5 and PHP4 ---
/


signature.asc
Description: This is a digitally signed message part

Re: [PHP] https://...

[Afan Pasalic]

Well, didn't know that one.
Thanks Greg, didn't know that one :)
Today is successful day - learned something new :)
-afan
Greg Donald wrote:
On Thu, 28 Oct 2004 11:01:53 -0500, Afan Pasalic <[EMAIL PROTECTED]> wrote:
I am not so good in this: you want to say that SSL use 443 port

Yup.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Fwd: Re: [PHP] https://...]

[Afan Pasalic]

Ok, this works just great! Thanks Warren.
Also, I found after I changed manualy http:// in https:// that
SCRIPT_URI will show whole URL (https://www.) and if I don't use SSL
will not show anything!
Thanks to all guys you wanted to help me!
-afan
Vail, Warren wrote:
Depends on the server and the release, but my apache shows
If($_SERVER["HTTPS"] == "on") // if true is secure
Lots of other information like cypher key size, etc.
Look in the $_SERVER array.
Keep in mind that lots of servers are setup to use the same htdocs base
directory for both secure and insecure pages, what happens if someone comes
to your unsecured page using https?  Another example is, if you have coded
full urls for images, the browser will usually complain if the page is
accessed via https and the image via http.
Warren Vail
-Original Message-
From: Greg Donald [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, October 27, 2004 3:01 PM
To: php-general
Subject: Re: [PHP] https://...

On Wed, 27 Oct 2004 16:35:14 -0500, Afan Pasalic <[EMAIL PROTECTED]> wrote:
hi,
how can I check using php that I use SSL?
tried with
REQUEST_URI
HTTP_HOST
PATH_INFO
but any of these does show http://

phpinfo() describes my SSL stuff pretty well if that's what you mean.
And I also found:
http://marc.theaimsgroup.com/?l=php-general&m=109767486431095&w=2

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https://...

[Afan Pasalic]

Yes, this one is correct one!
:)
Thanks Warren.
-afan
Rens Admiraal wrote:
But keep in mind that the var containing the value (I think 
$_SERVER["HTTPS"] is the right one) is only set when https:// is used...

Vail, Warren wrote:
Depends on the server and the release, but my apache shows
If($_SERVER["HTTPS"] == "on") // if true is secure
Lots of other information like cypher key size, etc.
Look in the $_SERVER array.
Keep in mind that lots of servers are setup to use the same htdocs base
directory for both secure and insecure pages, what happens if someone 
comes
to your unsecured page using https?  Another example is, if you have 
coded
full urls for images, the browser will usually complain if the page is
accessed via https and the image via http.

Warren Vail
-Original Message-
From: Greg Donald [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 
27, 2004 3:01 PM
To: php-general
Subject: Re: [PHP] https://...

On Wed, 27 Oct 2004 16:35:14 -0500, Afan Pasalic <[EMAIL PROTECTED]> wrote:
 

hi,
how can I check using php that I use SSL?
tried with
REQUEST_URI
HTTP_HOST
PATH_INFO
but any of these does show http://
  

phpinfo() describes my SSL stuff pretty well if that's what you mean.
And I also found:
http://marc.theaimsgroup.com/?l=php-general&m=109767486431095&w=2
 


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https://...

[Afan Pasalic]

that's why I use it, sure.
but can't find anything that helps me.
Greg Donald wrote:
On Wed, 27 Oct 2004 16:35:14 -0500, Afan Pasalic <[EMAIL PROTECTED]> wrote:
hi,
how can I check using php that I use SSL?
tried with
REQUEST_URI
HTTP_HOST
PATH_INFO
but any of these does show http://

phpinfo() describes my SSL stuff pretty well if that's what you mean.
And I also found:
http://marc.theaimsgroup.com/?l=php-general&m=109767486431095&w=2

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https://...

[Greg Donald]

On Thu, 28 Oct 2004 11:01:53 -0500, Afan Pasalic <[EMAIL PROTECTED]> wrote:
> I am not so good in this: you want to say that SSL use 443 port

Yup.


-- 
Greg Donald
Zend Certified Engineer
http://gdconsultants.com/
http://destiney.com/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https://...

[Afan Pasalic]

Hi Robby,
Yes, I looked at SERVER_PORT/SERVER_PROTOCOL. What I got is 80 and 
HTTP/1.1 when I manually change http:// to https:// I'm getting 443 and 
HTTP/1.1

I am not so good in this: you want to say that SSL use 443 port
-afan
Robby Russell wrote:
On Wed, 2004-10-27 at 16:35 -0500, Afan Pasalic wrote:
hi,
how can I check using php that I use SSL?
tried with
REQUEST_URI
HTTP_HOST
PATH_INFO
but any of these does show http://
Thanks!
-afan

Have you looked at $_SERVER['SERVER_PORT'] and
$_SERVER['SERVER_PROTOCOL']
?
-Robby
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https://...

[Rens Admiraal]

But keep in mind that the var containing the value (I think 
$_SERVER["HTTPS"] is the right one) is only set when https:// is used...

Vail, Warren wrote:
Depends on the server and the release, but my apache shows
If($_SERVER["HTTPS"] == "on") // if true is secure
Lots of other information like cypher key size, etc.
Look in the $_SERVER array.
Keep in mind that lots of servers are setup to use the same htdocs base
directory for both secure and insecure pages, what happens if someone comes
to your unsecured page using https?  Another example is, if you have coded
full urls for images, the browser will usually complain if the page is
accessed via https and the image via http.
Warren Vail
-Original Message-
From: Greg Donald [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, October 27, 2004 3:01 PM
To: php-general
Subject: Re: [PHP] https://...

On Wed, 27 Oct 2004 16:35:14 -0500, Afan Pasalic <[EMAIL PROTECTED]> wrote:
 

hi,
how can I check using php that I use SSL?
tried with
REQUEST_URI
HTTP_HOST
PATH_INFO
but any of these does show http://
   

phpinfo() describes my SSL stuff pretty well if that's what you mean.
And I also found:
http://marc.theaimsgroup.com/?l=php-general&m=109767486431095&w=2
 

Re: [PHP] https://...

[Rens Admiraal]

You can find the exact $_SERVER var by checking the values printed by 
this loop:

foreach ($_SERVER as $var => $value)
{
   echo "\$_SERVER[\"{$var}\"] = {$value}";
}
Vail, Warren wrote:
Depends on the server and the release, but my apache shows
If($_SERVER["HTTPS"] == "on") // if true is secure
Lots of other information like cypher key size, etc.
Look in the $_SERVER array.
Keep in mind that lots of servers are setup to use the same htdocs base
directory for both secure and insecure pages, what happens if someone comes
to your unsecured page using https?  Another example is, if you have coded
full urls for images, the browser will usually complain if the page is
accessed via https and the image via http.
Warren Vail
-Original Message-
From: Greg Donald [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, October 27, 2004 3:01 PM
To: php-general
Subject: Re: [PHP] https://...

On Wed, 27 Oct 2004 16:35:14 -0500, Afan Pasalic <[EMAIL PROTECTED]> wrote:
 

hi,
how can I check using php that I use SSL?
tried with
REQUEST_URI
HTTP_HOST
PATH_INFO
but any of these does show http://
   

phpinfo() describes my SSL stuff pretty well if that's what you mean.
And I also found:
http://marc.theaimsgroup.com/?l=php-general&m=109767486431095&w=2
 

RE: [PHP] https://...

[Vail, Warren]

Depends on the server and the release, but my apache shows

If($_SERVER["HTTPS"] == "on") // if true is secure

Lots of other information like cypher key size, etc.

Look in the $_SERVER array.

Keep in mind that lots of servers are setup to use the same htdocs base
directory for both secure and insecure pages, what happens if someone comes
to your unsecured page using https?  Another example is, if you have coded
full urls for images, the browser will usually complain if the page is
accessed via https and the image via http.

Warren Vail


-Original Message-
From: Greg Donald [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, October 27, 2004 3:01 PM
To: php-general
Subject: Re: [PHP] https://...


On Wed, 27 Oct 2004 16:35:14 -0500, Afan Pasalic <[EMAIL PROTECTED]> wrote:
> hi,
> how can I check using php that I use SSL?
> tried with
> REQUEST_URI
> HTTP_HOST
> PATH_INFO
> but any of these does show http://

phpinfo() describes my SSL stuff pretty well if that's what you mean.

And I also found:
http://marc.theaimsgroup.com/?l=php-general&m=109767486431095&w=2


-- 
Greg Donald
Zend Certified Engineer
http://gdconsultants.com/
http://destiney.com/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https://...

[Greg Donald]

On Wed, 27 Oct 2004 16:35:14 -0500, Afan Pasalic <[EMAIL PROTECTED]> wrote:
> hi,
> how can I check using php that I use SSL?
> tried with
> REQUEST_URI
> HTTP_HOST
> PATH_INFO
> but any of these does show http://

phpinfo() describes my SSL stuff pretty well if that's what you mean.

And I also found:
http://marc.theaimsgroup.com/?l=php-general&m=109767486431095&w=2


-- 
Greg Donald
Zend Certified Engineer
http://gdconsultants.com/
http://destiney.com/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https://...

[Robby Russell]

On Wed, 2004-10-27 at 16:35 -0500, Afan Pasalic wrote:
> hi,
> how can I check using php that I use SSL?
> tried with
> REQUEST_URI
> HTTP_HOST
> PATH_INFO
> but any of these does show http://
> 
> Thanks!
> 
> -afan
> 

Have you looked at $_SERVER['SERVER_PORT'] and
$_SERVER['SERVER_PROTOCOL']
?

-Robby

-- 
/***
* Robby Russell | Owner.Developer.Geek
* PLANET ARGON  | www.planetargon.com
* Portland, OR  | [EMAIL PROTECTED]
* 503.351.4730  | blog.planetargon.com
* PHP/PostgreSQL Hosting & Development
/



signature.asc
Description: This is a digitally signed message part

Re: [PHP] https & sessions failing to persist

[Curt Zirzow]

* Thus wrote Michael R. Wayne ([EMAIL PROTECTED]):
> On Fri, Apr 30, 2004 at 08:52:37PM +, Curt Zirzow wrote:
> > 
> > session.cookie_path
> > session.cookie_domain
> > session.cookie_secure
> 
> session.cookie_path   /
> session.cookie_secure Off
> session.cookie_domain no value
> 
> But we never use cookies:
> session.use_cookies   Off

do'h.. i completly missed that.  



Curt
-- 
"I used to think I was indecisive, but now I'm not so sure."

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https & sessions failing to persist

[Michael R. Wayne]

On Fri, Apr 30, 2004 at 08:52:37PM +, Curt Zirzow wrote:
> 
> session.cookie_path
> session.cookie_domain
> session.cookie_secure

session.cookie_path /
session.cookie_secure   Off
session.cookie_domain   no value

But we never use cookies:
session.use_cookies Off

/\/\ \/\/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https & sessions failing to persist

[Curt Zirzow]

* Thus wrote Michael R. Wayne ([EMAIL PROTECTED]):
> 
> Upgraded our PHP installation from 4.1.2 to 4.3.4, scripts that
> worked fine before are no longer doing so.  The failure can be
> traced to the fact that sessions are never being reused (i.e. a new
> session gets started with each connection).  The session files get
> written with proper information but never get read.
> 
> The relevant session variables are:
>Session Supportenabled 
>session.auto_start On
>session.use_cookiesOff
>session.use_trans_sid  On

What about:

session.cookie_path
session.cookie_domain
session.cookie_secure



Curt
-- 
"I used to think I was indecisive, but now I'm not so sure."

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https detection

[Curt Zirzow]

* Thus wrote Rosen ([EMAIL PROTECTED]):
> I.e. if  I use _SERVER["SERVER_PORT"] = 443  - for https connection and 80
> for "normal" - i'll be able to determite if user is in https mode - I think
> thath should be works . ?

There is no guarantee that port 443 == https and 80 == http.

Curt
-- 
"My PHP key is worn out"

  PHP List stats since 1997: 
  http://zirzow.dyndns.org/html/mlists/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https detection

[Eugene Lee]

On Sun, Oct 12, 2003 at 08:52:30PM +1000, Tom Rogers wrote:
: Sunday, October 12, 2003, 8:46:41 PM, Eugene wrote:
: EL> On Sun, Oct 12, 2003 at 01:24:40PM +0200, Rosen wrote:
: EL> : 
: EL> : I.e. if  I use _SERVER["SERVER_PORT"] = 443  - for https connection
: EL> : and 80 for "normal" - i'll be able to determite if user is in https
: EL> : mode - I think thath should be works . ?
: 
: EL> Technically, you can't guarantee that anything running over port 443
: EL> will be HTTPS.  This is part of the more general problem of running your
: EL> web server on non-standard ports.
: 
: His script will only see valid ssl connections as all other attempts should be
: ditched by apache or whatever before php gets involved...in theory anyway :)

Unless Apache is configured so that both SSL and non-SSL virtualhosts
to point to the same directory containing said script, or said script is
shared (via PHP include(), require(), etc.) by other PHP scripts in both
SSL and non-SSL virtualhosts.  :-)

And $_SERVER['HTTPS'] is so much easier to check for existence!

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https detection

[Eugene Lee]

On Sun, Oct 12, 2003 at 01:24:40PM +0200, Rosen wrote:
: 
: I.e. if  I use _SERVER["SERVER_PORT"] = 443  - for https connection and 80
: for "normal" - i'll be able to determite if user is in https mode - I think
: thath should be works . ?

Technically, you can't guarantee that anything running over port 443
will be HTTPS.  This is part of the more general problem of running your
web server on non-standard ports.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https detection

[Eugene Lee]

On Sun, Oct 12, 2003 at 01:09:15PM +0200, Rosen wrote:
: 
: Is there a way to determite with PHP thath site visitor is in https (SSL)
: mode or in normal mode ?

Check for the existence of $_SERVER['HTTPS'] which gets set only on SSL
pages.  I wonder why it's still not mentioned in the official docs.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https detection

[Rosen]

I.e. if  I use _SERVER["SERVER_PORT"] = 443  - for https connection and 80
for "normal" - i'll be able to determite if user is in https mode - I think
thath should be works . ?

Thanks,
Rosen





 "Tom Rogers" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi,
>
> Sunday, October 12, 2003, 9:09:15 PM, you wrote:
> R> Hi,
> R> Is there a way to determite with PHP thath site visitor is in https
(SSL)
> R> mode or in normal mode ?
>
> R> Thanks,
> R> Rosen
>
>
> put phpinfo(32); at the top of the page and that should show what is
available
> with an ssl connection if you make one.
>
> --
> regards,
> Tom

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] https detection

[Tom Rogers]

Hi,

Sunday, October 12, 2003, 9:09:15 PM, you wrote:
R> Hi,
R> Is there a way to determite with PHP thath site visitor is in https (SSL)
R> mode or in normal mode ?

R> Thanks,
R> Rosen


put phpinfo(32); at the top of the page and that should show what is available
with an ssl connection if you make one.

-- 
regards,
Tom

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] HTTPS POST without user/client intervention

[Jeff Harris]

|-Original Message-
|From: PHP List [mailto:[EMAIL PROTECTED]
|Sent: Tuesday, July 15, 2003 1:02 PM
|To: [EMAIL PROTECTED]
|Subject: [PHP] HTTPS POST without user/client intervention
|
|I am writing a php script to accept an HTTPS POST of data from a remote
|site, process the data, and send an HTTPS POST response back (not
|necessarily to the same remote site). I can do this pretty easily in
|PERL (which I may have to if I can't find a PHP solution).  Also I need
|to do the https post without any kind of client or user interaction. I
|have checked through php.net and phpbuilder.com but have only come up
|with things for HTTP POST (no SSL Encryption).  Anyone run across
|something like this, or can point me in a direction to look?
|

On Jul 16, 2003, "Ralph Guzman" claimed that:
|
|I think what you are looking for is socket connections:
|http://www.php.net/manual/en/function.fsockopen.php
|
|Or CURL
|
|http://www.php.net/manual/en/ref.curl.php
|

Another option for you is to ouput a blank page with just a form pointing
where you need it to, with hidden inputs, and at the end of the page or in
a ,


document.form.submit();


Assuming your client has JavaScript.

Jeff Harris
-- 
Registered Linux user #304026.
"lynx -source http://jharris.rallycentral.us/jharris.asc | gpg --import"
Key fingerprint = 52FC 20BD 025A 8C13 5FC6  68C6 9CF9 46C2 B089 0FED
Responses to this message should conform to RFC 1855.



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] HTTPS POST without user/client intervention

[Ralph Guzman]

I think what you are looking for is socket connections:
http://www.php.net/manual/en/function.fsockopen.php

Or CURL

http://www.php.net/manual/en/ref.curl.php


-Original Message-
From: PHP List [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 15, 2003 1:02 PM
To: [EMAIL PROTECTED]
Subject: [PHP] HTTPS POST without user/client intervention

I am writing a php script to accept an HTTPS POST of data from a remote
site, process the data, and send an HTTPS POST response back (not
necessarily to the same remote site). I can do this pretty easily in
PERL (which I may have to if I can't find a PHP solution).  Also I need
to do the https post without any kind of client or user interaction. I
have checked through php.net and phpbuilder.com but have only come up
with things for HTTP POST (no SSL Encryption).  Anyone run across
something like this, or can point me in a direction to look?

-- 
Woody

In a world without boundaries why
do we need Gates and Windows?


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] HTTPS POST without user/client intervention

[Chris Shiflett]

--- PHP List <[EMAIL PROTECTED]> wrote:
> > As for sending a POST request to a remote site via SSL, just check
> > out cURL, which also has a convenient PEAR package.
> 
> This is what I am trying to do...and thanks for point out cURL...I will
> check it out.

In that case, you should find this helpful:

http://www.php.net/curl

If you like PEAR, this might be handy:

http://pear.php.net/Net_Curl

cURL does support SSL, so it should provide what you need.

Chris

=
Become a better Web developer with the HTTP Developer's Handbook
http://httphandbook.org/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] HTTPS POST without user/client intervention

[PHP List]

On Tue, 2003-07-15 at 15:12, Chris Shiflett wrote:
> --- PHP List <[EMAIL PROTECTED]> wrote:
> > I am writing a php script to accept an HTTPS POST of data from a
> > remote site, process the data, and send an HTTPS POST response back
> > (not necessarily to the same remote site).
> 
> Can you perhaps rephrase what you are trying to do? The way I interpret what
> you are asking may be much simpler than what you really mean to do.
> 
> To "accept" an HTTPS POST only requires that your Web server is SSL-enabled.
> There is nothing special you must do. For example, a PHP script can print out
> all posted data like this:
> 
> print_r($_POST);
Yup...I already accept the https posts just fine...


> 
> As for sending a POST request to a remote site via SSL, just check out cURL,
> which also has a convenient PEAR package.

This is what I am trying to do...and thanks for point out cURL...I will
check it out.

Sorry for being unclear...

-- 
Woody

In a world without boundaries why
do we need Gates and Windows?


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] HTTPS POST without user/client intervention

[Chris Shiflett]

--- PHP List <[EMAIL PROTECTED]> wrote:
> I am writing a php script to accept an HTTPS POST of data from a
> remote site, process the data, and send an HTTPS POST response back
> (not necessarily to the same remote site).

Can you perhaps rephrase what you are trying to do? The way I interpret what
you are asking may be much simpler than what you really mean to do.

To "accept" an HTTPS POST only requires that your Web server is SSL-enabled.
There is nothing special you must do. For example, a PHP script can print out
all posted data like this:

print_r($_POST);

This simple example also replies to the remote site (over SSL) that sent the
HTTPS request, since that's where standard out goes. Basically, since SSL lies
between TCP and HTTP, by the time your PHP script gets the data, there is
really no difference. The difference is in the Web server, not the code (unless
you want to check whether the current connection is SSL).

As for sending a POST request to a remote site via SSL, just check out cURL,
which also has a convenient PEAR package.

Chris

=
Become a better Web developer with the HTTP Developer's Handbook
http://httphandbook.org/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] HTTPS vs. HTTP ?

[Analysis & Solutions]

Hey Folks:

Speaking of identity theft, here's a fun story.  Involves a Hollywood 
Video store.  HV is a large chain of video rental stores.

http://www.nydailynews.com/2002-07-09/News_and_Views/Crime_File/a-156851.asp

--Dan

-- 
   PHP classes that make web design easier
SQL Solution  |   Layout Solution   |  Form Solution
sqlsolution.info  | layoutsolution.info |  formsolution.info
 T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y
 4015 7 Av #4AJ, Brooklyn NY v: 718-854-0335 f: 718-854-0409

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] HTTPS vs. HTTP ?

[Brinkman, Theodore]

You know the retail establishment has invested alot of money, what about the
underpaid waiter/checkout person they employ?

What is that waiter doing with your credit card when he/she takes it from
the table for processing?

Is the checkout person have a photographic memory writing down name/credit
card combinations when they take their smoke break?

Is the establishment using unencrypted wireless networks to link their POS
terminals to their backend systems?

What if the b&m store has an antiquated system that prints out your entire
CC# on the reciepts?

What if they still use a card-impression system?

Heck, what if they set your card on the big magnet they use to turn off the
security tags on the stuff you just bought?

What if they pretend your card has been denied with a code which requires
them to destroy the card?  They certainly won't give it back, and they'll be
able to copy the numbers down at their leisure.

  You can play 'what if' until the cows come home.  That doesn't change the
fact that the *VAST* majority of stolen credit card information was *NOT*
stolen as a result of an online transaction.  Most are stolen through much
more mundane methods, like 'shoulder surfing' at the register, or a waiter
copying the info while they're away from the table.  I don't shop at b&m
shops that I don't feel I can trust, any more than I shop at e-sites that I
don't feel I can trust.  I don't trust *ANY* e-site that isn't willing to go
to the effort to properly protect the transaction (certificates from a
trusted CA, encrypted communication, reasonable security efforts, etc.).

Properly signed certificates don't prove the vendor is trustworthy.  They
provide some sound evidence that the vendor is who they say they are.  A
self-signed certificate doesn't say anything except that they say they are
who they say they are.  The encryption provides a reasonable guarantee that
nobody except you and the vendor will be able to see your transaction.

The reason more CC fraud happens online isn't that more info is stolen
there.  It's that the vendor has no way of knowing that YOU are who you say
you are.  Thousands of sets of credit card info are stolen every day
*offline*.  You don't hear about it because it happens in ways that are
impossible to detect.  Some vendor's online site gets hacked, and you hear
about it because it could be detected.

- Theo

P.S.: Shopping carts 'too boring'?!  Of course they're boring!

-Original Message-----
From: Richard Lynch [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 08, 2002 4:33 PM
To: [EMAIL PROTECTED]
Subject: Re: [PHP] HTTPS vs. HTTP ?


>>>How do you know their certificate hasn't been stolen, and they haven't
even
>figured it out yet?  How do you know they were trustworthy people in the
>first place?<<
>
>Why do you ASSUME that they're NOT trustworthy people?  Do you go through 
>your entire life in that shell?

Everybody gets a limited amount of trust extended to them, for "free"

That amount is NOWHERE NEAR the trust where I hand them my credit card
number.

Do you hand your credit-card to random people in the street?

With a brick-and-mortar retail establishment, I can tell a lot from
location, size, even the "look" of the store -- I also know, right off the
bat, that they've invested a *TON* of money and won't be able to make it
back in a short-time con.

With a web-site, I can tell:
They paid $119 to somebody for the CA.
They paid $20/month or so to somebody else.
They maybe paid somebody to design/build the site, or a turn-key system,
or...

That really doesn't tell me a whole lot.

I don't know:

They aren't storing my credit card number in their database "just
temporarily" while we process it.
[I've had to fix this error a couple times myself, and I hate doing shopping
carts.  Too boring.  I quit doing them.  I can't imagine how many times a
shopping cart "regular" has walked into this situation.]

They aren't using a badly-designed system where my CC# appears in "ps
aux" output.

They aren't using a badly-designed system where the CC# is stored on the
disk during processing.
[Hint -- Last I checked, Linkpoint's PHP interface did this.  Guess what
happens when you get a network time out or the script fails for some reason?
 Your CC# is left hanging around in that file.  Sure, if the instructions
were followed, only root can read it...  If the server hasn't been hacked. 
If, if, if...]

The scripts that process my CC # have correct permissions, and are
accessible only to one, okay, *two* people to avoid somebody inserting a
back-door.

The list of failure points is endless, and I *STILL* don't even trust that
randomsite.com has had any kind of background check carried out by the

Re: [PHP] HTTPS vs. HTTP ?

[Miguel Cruz]

On Mon, 8 Jul 2002, Analysis & Solutions wrote:
> Allow me to emphasize Richard's point about not trusting certificate 
> authorities.  I have an SSL certificate.  It was fairly simple to get, 
> despite several discrepancies in my documentation.
> 
> While it made things easier for me, which I'm thankful for.  Fortunately,
> I'm a legitimate operator.  But, it certainly demonstrates that subverting
> the process for nefarious reasons is a piece of cake.

But you're both ignoring the actual significant point (which I already 
made at great length, and feel somewhat like a sap for repeating):

Having a certificate signed by a recognized certificate authority provides 
at least some guarantee that you are communicating with the named party 
using somewhat reliable encryption.

On the other hand, if you connect with a remote site that has a
self-signed certificate, it's little better than using cleartext to port
80; almost anyone who would realistically have been in a position to snoop
on your HTTP traffic is also in a position to intercept and decode your
HTTPS traffic by masquerading as the remote host. So what's the point?

Self-signed certificates only make sense if you able to securely
distribute your signer's public key to your users in advance of the web
transaction. This is fine for internal or staff use, but it is pretty
unwieldy when you're dealing with the general public.

miguel


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] HTTPS vs. HTTP ?

[Analysis & Solutions]

Folks:

Allow me to emphasize Richard's point about not trusting certificate 
authorities.  I have an SSL certificate.  It was fairly simple to get, 
despite several discrepancies in my documentation.

While it made things easier for me, which I'm thankful for.  Fortunately,
I'm a legitimate operator.  But, it certainly demonstrates that subverting
the process for nefarious reasons is a piece of cake.

Enjoy,

--Dan

-- 
   PHP classes that make web design easier
SQL Solution  |   Layout Solution   |  Form Solution
sqlsolution.info  | layoutsolution.info |  formsolution.info
 T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y
 4015 7 Av #4AJ, Brooklyn NY v: 718-854-0335 f: 718-854-0409

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] HTTPS vs. HTTP ?

[Richard Lynch]

>>>How do you know their certificate hasn't been stolen, and they haven't even
>figured it out yet?  How do you know they were trustworthy people in the
>first place?<<
>
>Why do you ASSUME that they're NOT trustworthy people?  Do you go through 
>your entire life in that shell?

Everybody gets a limited amount of trust extended to them, for "free"

That amount is NOWHERE NEAR the trust where I hand them my credit card
number.

Do you hand your credit-card to random people in the street?

With a brick-and-mortar retail establishment, I can tell a lot from
location, size, even the "look" of the store -- I also know, right off the
bat, that they've invested a *TON* of money and won't be able to make it
back in a short-time con.

With a web-site, I can tell:
They paid $119 to somebody for the CA.
They paid $20/month or so to somebody else.
They maybe paid somebody to design/build the site, or a turn-key system,
or...

That really doesn't tell me a whole lot.

I don't know:

They aren't storing my credit card number in their database "just
temporarily" while we process it.
[I've had to fix this error a couple times myself, and I hate doing shopping
carts.  Too boring.  I quit doing them.  I can't imagine how many times a
shopping cart "regular" has walked into this situation.]

They aren't using a badly-designed system where my CC# appears in "ps
aux" output.

They aren't using a badly-designed system where the CC# is stored on the
disk during processing.
[Hint -- Last I checked, Linkpoint's PHP interface did this.  Guess what
happens when you get a network time out or the script fails for some reason?
 Your CC# is left hanging around in that file.  Sure, if the instructions
were followed, only root can read it...  If the server hasn't been hacked. 
If, if, if...]

The scripts that process my CC # have correct permissions, and are
accessible only to one, okay, *two* people to avoid somebody inserting a
back-door.

The list of failure points is endless, and I *STILL* don't even trust that
randomsite.com has had any kind of background check carried out by the
people issuing Certifcates.  Jeez, people -- We're talking one of the major
players is MICROSOFT!  Do you trust them with Security?!

I've seen too many bad home-brew shopping carts to have any faith in them. 
I still shop on-line, but rely on the fact that I can only get dinged for
$50, and we'll all be paying even higher interest rates next year.  I have
no trust that my CC# isn't being exposed.

>>>The more I think about this, the more I agree with people who just won't do
>eCommerce at all...<<

Hey, I'm not saying I don't shop on-line.  I'm saying I have no faith that I
won't be calling up the credit card company and canceling the stolen account
much faster than at a traditional store.

I have no faith that the e-theft of credit cards won't raise my interest
rates.

The CC companies have already proven that they will accept an inordinately
high level of theft and just pass on the cost to consumers.  What do they
care what your interest rates are?

-- 
Like Music?  http://l-i-e.com/artists.htm

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] HTTPS vs. HTTP ? - the weakest link

[Miguel Cruz]

On Mon, 8 Jul 2002, Brinkman, Theodore wrote:
> Think about it for a moment.  E-commerce involving properly signed sites is,
> at the very least, more secure than handing your credit card to a waiter in
> a restauraunt.  The waiter can walk off with your card, and come back 2
> minutes later with your card.  You'll never know if he copied down the name,
> cc number and expiration date for later use.

And in real life, that's how most credit card numbers are stolen.

miguel


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] HTTPS vs. HTTP ? - the weakest link

[Brinkman, Theodore]

Think about it for a moment.  E-commerce involving properly signed sites is,
at the very least, more secure than handing your credit card to a waiter in
a restauraunt.  The waiter can walk off with your card, and come back 2
minutes later with your card.  You'll never know if he copied down the name,
cc number and expiration date for later use.

- Theo

-Original Message-
From: B.C. Lance [mailto:[EMAIL PROTECTED]]
Sent: Sunday, July 07, 2002 12:37 AM
To: [EMAIL PROTECTED]
Subject: Re: [PHP] HTTPS vs. HTTP ? - the weakest link


sorry to barge in. but the weakest link ain't in ssl. doesn't really 
matter how secure vs insecure it is. you can come up with the most 
secure technology in the whole world that no one can break into. the 
weakest link lies on the user/customer themselves.

you just need a trojan horse in their computer and there goes the 
neighbourhood. they can by all means send their credit card information 
over to amazon.com. but this piece of information will still be open to 
the person who plant the horse in the machine.

so i suppose the debate over here should really be: is ecommerce safe?
and not: http vs https


just my 2 cents
b.c. lance


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] HTTPS vs. HTTP ?

[Martin Clifford]

>>How do you know their certificate hasn't been stolen, and they haven't even
figured it out yet?  How do you know they were trustworthy people in the
first place?<<

Why do you ASSUME that they're NOT trustworthy people?  Do you go through your entire 
life in that shell?

>>The more I think about this, the more I agree with people who just won't do
eCommerce at all...<<

Just the opposite for me.  Time to go web-shoppin!

Martin

-- 
Like Music?  http://l-i-e.com/artists.htm 


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php 



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] HTTPS vs. HTTP ?

[Chris Hewitt]

Chris Shiflett wrote:

>
> I think I'm going to compile all of my SSL explanations into a more 
> clear and informative explanation and post it on the Web somewhere. 

Yes please.

Chris


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] HTTPS vs. HTTP ?

[Alberto Serra]

ðÒÉ×ÅÔ!

This is for Chris and Miguel and all the people who threw in infos.

I just wanted to thank you all :) It's been really useful, and yes 
Chris, I guess you should post an explanation of the process somewhere. 
Most of us are prepared to use HTTPS but we can hardly explain our 
customers (and ourselves) what the hell we are doing.

ÐÏËÁ
áÌØÂÅÒÔÏ
ëÉÅ×

-- 


@-_=}{=_-@-_=}{=_-@-_=}{=_-@-_=}{=_-@-_=}{=_-@-_=}{=_-@-_=}{=_-@

LoRd, CaN yOu HeAr Me, LiKe I'm HeArInG yOu?
lOrD i'M sHiNiNg...
YoU kNoW I AlMoSt LoSt My MiNd, BuT nOw I'm HoMe AnD fReE
tHe TeSt, YeS iT iS
ThE tEsT, yEs It Is
tHe TeSt, YeS iT iS
ThE tEsT, yEs It Is...


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] HTTPS vs. HTTP ?

[Chris Shiflett]

Miguel Cruz wrote:

>Nobody thinks they're checking whether or not goodguys.com are good guys. 
>It is your job as a consumer to research them. Once you have researched 
>them and decided to do business with them, the certificate authority gives 
>you a pretty solid basis for believing that you actually are dealing with 
>the people you were prepared to trust. That's the point.
>

Miguel is absolutely right, and he probably did a better job at making 
this more clear, since I seem to be failing miserably. :)



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] HTTPS vs. HTTP ?

[Chris Shiflett]

Alberto Serra wrote:

>> However, it is adequate to know that one key is used to do the 
>> encrypting, while the other is used for the decrypting. These are 
>> generally referred to as public and private keys, because one is made 
>> available to the public while the other is kept safely stored (in the 
>> case of Web browsers, it is stored in the certificate repository of 
>> the browser).
>
>
> Yes, glad that I did use PGP sometimes :) this part is clear :) So 
> Verisign is actually just "signing" the key as I did on PGP and that 
> means anyone trusting me can trust you if they receive a message 
> signed with your key, because when evaluating the message they will 
> now it';s been signed by a key that I would trust myself. Right?


I have very little experience with PGP, so I can't confirm the 
similarities here. However, I think you may be still misunderstanding 
the role of VeriSign (I could easily be wrong). I'll explain it again 
briefly, just to be certain.

The asymmetric cryptography that guarantees your HTTP communication 
cannot be decrypted except by the final recipient is only half (or less 
than half) of the battle. You need to also have some sort of assurance 
that the final recipient is who they claim to be and not an imposter.

When you apply for a digital certificate from VeriSign, you must present 
a request in a specific format. Part of this process of purchase 
involves you proving that you are the holder of the public key (verified 
by the generation of the request by your Web server software) and the 
legitimate owner of the specific domain name the certificate is being 
used for. With this information, VeriSign will use the fact that pretty 
much every Web client on the planet trusts VeriSign to issue you a 
certificate that says:

"We, VeriSign, assure you that the following public key belongs to 
www.niceguy.org."

This means that nearly every Web client on the planet will trust that 
the public key mentioned in that digital certificate really belongs to 
www.niceguy.org, so any communication encrypted with it can only be 
decrypted by the private key of www.niceguy.org.

>> Digital certificates solve this problem. A digital certificate, as 
>> RSA describes it, is a document that says:
>>
>> "I guarantee that this particular public key is associated with this 
>> particular user; Trust me!"
>
>
> So actually, when you spend your $200 what happens is:
>   1) Verisign (or whoever) starts a process to control they really wanna
>  play with you (and this has nothing to do with IT or SSL, they will
>  have their own policies)
>   2) Verisign (or whoever) starts a process to control your public key
>  and possibly something else in your system
>   3) If the above has a positive answer they just sign your kay and hand
>  it over to you. So there is no need for a central db. Trust is *in*
>  the key and need not be searched for. The only thing to do is to
>  verify that the trusting key has not been revoked.


VeriSign doesn't do extensive checks on your use of the digital 
certificate, because that is all outside of the scope of SSL. Their 
methods are to ensure that the claim they are making in the digital 
certificate (mentioned above) is true. Since that's all they're 
guaranteeing, that's all they need to ensure.

Also, VeriSign does keep a central repository of all digital 
certificates it has issued. Next time you are on an SSL site, go into 
the security configuration menus specific to your browser and see if you 
can find a way to verify the certificate. This will manually kick off 
the process to verify the certificate with the CA. You can revoke a 
certificate to make it fail this check and pretty much render it 
useless, except that people can still use it to encrypt email.

>> So, assuming for the moment that we trust the certificate, we can 
>> assume that a particular public key belongs to a particular user. For 
>> example, you can be guaranteed that a public key belongs to me (Chris 
>> Shiflett) and thus, only Chris Shiflett will be able to decrypt the 
>> communication. If someone is trying to pose as me, you may send them 
>> encrypted communication, but they won't be able to decrypt it.
>
>
> Yes, because they have stolen the public key and could crypt the 
> question but since they have not the private key they cannot open the 
> answer. 


Actually, what I meant here is not that they will even use the public 
key, but that other people whose browsers are tricked into thinking 
they're really talking to www.niceguy.org will use niceguy.org's public 
key to encrypt the communication. Then, only niceguy.org will be able to 
decrypt the communication, regardless of who receives it.

The digital certificate is quite public itself. If you go to an 
SSL-enabled site, you can view theirs (since they have to present it to 
your browser). The statement it makes doesn't change, so it doesn't 
matter if the criminal has possession of it; it's pub

Re: [PHP] HTTPS vs. HTTP ?

[Miguel Cruz]

On Mon, 8 Jul 2002, Alberto Serra wrote:
> Chris Shiflett wrote:
>> Of course, as users of Web browsers such as Netscape and Internet 
>> Explorer, we have to trust AOL/Time Warner and Microsoft, respectively, 
>> (yeah, scary thought) to only trust CAs that have high integrity, 
>> security, etc. An extensive C&A (Certification and Accredidation) 
>> process is used to make this guarantee.
> 
> Yes, but this is the part I doubt. When I buy a certificate from Kiev, 
> how on earth those guys sitting in Washington are to know who I am and 
> what I do for a living? They will have to handle the job to someone 
> else. This layering of delegations will include banks and governmental 
> stuff, and there is no such thing as a government that will not accept 
> bribery.

We (in the USA) bought our corporate certificate from Thawte, a company in
South Africa.

You wouldn't believe the amount of stuff they had me dredge up; it was
like a scavenger hunt. I had to get the lawyers to dig out the official
incorporation documents; I had to get accounting to dig out all sorts of
tax bills; I had to get phone bills and executive signatures and who knows
what else. When I sent them some Delaware incorporation document, they
were familiar enough with the format to know that an (unnumbered) page was
missing, and to ask me to find it and fax it to them.

> What we *do not* believe (correct me Richard if I misunderstood you) is 
> that Verisign (or whoever in their place) will actually do more than 
> verifying that www.goodguys.org is really existing and it's there. And 
> this is just a protection against hackers but has nothing to with 
> consumer's privacy or security. People at goodguys.org will not be 
> checked anyway as far as they behaviour as a company is concerbed (that 
> would cost *much* more than $200 and it would be way to easy for the 
> crooks to buy themselves a virginity by doubling the money).

Nobody thinks they're checking whether or not goodguys.com are good guys. 
It is your job as a consumer to research them. Once you have researched 
them and decided to do business with them, the certificate authority gives 
you a pretty solid basis for believing that you actually are dealing with 
the people you were prepared to trust. That's the point.

miguel


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] HTTPS vs. HTTP ?

[Alberto Serra]

ðÒÉ×ÅÔ!

>> Chris Shiflett wrote:
> it is very misleading and would indicate that I 
> have very little knowledge about PKI systems, 

Come on, nobody here would ever think of that. Especially since most of 
us (put me as first one in the list) should know much more about PKI 
ourselves before judging anybody's knowledge :) Which is why we keep 
making questions that sometimes may be pretty absurd.

> I was trying to point out 
> how insecure this model would be if encryption were all that SSL 
> provided and the only trust involved was the trust of a domain name.

Yes, I've got it now.

> No government, as far as I know, can break the public key cryptography 
> currently being used by most SSL-enabled sites (using the strong 
> security - 128 bit certificates). This includes the United States.

I was saying this because I remember (maaany years ago, when the whole 
PGP thing started) reading some fire exchanges about RSA keys and the 
way the encrypting chips were going to be "friendly" to american eyes. 
Honestly, at that time I was not that interested to the issue and I just 
gave it a quick read, which left me with a wrong opinion.

> Now, SSL only encrypts your communication in transit, of course. I'm 
> sure your local government could find a way to make the entity you are 
> communicating with release the information in the communication to them. 
> This is, of course, outside the scope of SSL.

And outside the scope of my worries :) I am responsible for the software 
I deliver, whatever happens out of it is none of my bag :)

> However, it is adequate to know that one key is used to do the 
> encrypting, while the other is used for the decrypting. These are 
> generally referred to as public and private keys, because one is made 
> available to the public while the other is kept safely stored (in the 
> case of Web browsers, it is stored in the certificate repository of the 
> browser).

Yes, glad that I did use PGP sometimes :) this part is clear :) So 
Verisign is actually just "signing" the key as I did on PGP and that 
means anyone trusting me can trust you if they receive a message signed 
with your key, because when evaluating the message they will now it';s 
been signed by a key that I would trust myself. Right? Man, I don't even 
wanna imagine where and how Verisign password is kept LOLOL

> Digital certificates solve this problem. A digital certificate, as RSA 
> describes it, is a document that says:
> 
> "I guarantee that this particular public key is associated with this 
> particular user; Trust me!"

So actually, when you spend your $200 what happens is:
   1) Verisign (or whoever) starts a process to control they really wanna
  play with you (and this has nothing to do with IT or SSL, they will
  have their own policies)
   2) Verisign (or whoever) starts a process to control your public key
  and possibly something else in your system
   3) If the above has a positive answer they just sign your kay and hand
  it over to you. So there is no need for a central db. Trust is *in*
  the key and need not be searched for. The only thing to do is to
  verify that the trusting key has not been revoked.

That is, if it works like PGP. But this is probably too easy, as this 
way they would have no way to revoke my key without invalidating all 
keys on this planet. So this is a simplification. But just tell me if I 
got the basic message.

> So, assuming for the moment that we trust the certificate, we can assume 
> that a particular public key belongs to a particular user. For example, 
> you can be guaranteed that a public key belongs to me (Chris Shiflett) 
> and thus, only Chris Shiflett will be able to decrypt the communication. 
> If someone is trying to pose as me, you may send them encrypted 
> communication, but they won't be able to decrypt it.

Yes, because they have stolen the public key and could crypt the 
question but since they have not the private key they cannot open the 
answer.

> Well, I disagree that this has nothing to do with the SSL protocol 
> itself. Identification is a very important part of enabling secure 
> transactions to take place over the Web. Without this, there would be no 
> "ecommerce" as it has been dubbed.
...
> Of course, as users of Web browsers such as Netscape and Internet 
> Explorer, we have to trust AOL/Time Warner and Microsoft, respectively, 
> (yeah, scary thought) to only trust CAs that have high integrity, 
> security, etc. An extensive C&A (Certification and Accredidation) 
> process is used to make this guarantee.

Yes, but this is the part I doubt. When I buy a certificate from Kiev, 
how on earth those guys sitting in Washington are to know who I am and 
what I do for a living? They will have to handle the job to someone 
else. This layering of delegations will include banks and governmental 
stuff, and there is no such thing as a government that will not accept 
bribery.

Chris, what me and Richard doubt is *NOT*

Re: [PHP] HTTPS vs. HTTP ?

[Tracker 1]

Personally, I think the concept of NEEDING https is a bit rediculous.

Generally, trying to get through the front door, would be the same as
trying to get through a concrete wall with a baseball bat...

Now, finding a back door, and getting at THEIR database is the REAL key.
people don't generally try and hack routers... most current router systems
haven't been hacked.. there are attempts, same as anything else.. it just
isn't very common.

if you can steal the keys, you can steal the database, which holds more
than stealing a site for a few minutes.

--
===
Michael J. Ryan  -  tracker1[*at*]theroughnecks.com
Roughneck BBS: http://www.theroughnecks.net  telnet://theroughnecks.net
===
Y!: aztracker1 - aim: azTracker1 - icq: 4935386 - msn: see email
One program for aim/icq/yahoo/msn/irc  -  http://www.trillian.cc/


"Richard Lynch" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> >In public key cryptography, it is the *keys*, not the digital
> >certificate that encrypt/decrypt the communication.
>
> Okay.
>
> I break into his co-lo, I walk off with his computer, and I break into his
> office, I walk off with his computers, I kill the guy, and I kidnap his
> wife.
>
> I have everything.
>
> I have his Certs, his keys, his server, his domain, *EVERYTHING*.
>
> This is not *IMPOSSIBLE*, no matter how "unlikely" it is painted.
>
> But let me paint a more-likely scenario.
>
> Some guy sets up a tiny on-line retail shop on his $20/month ISP.
> Whoo-Hooo!
>
> He gets hacked, never even notices, and his Certs and keys are all stolen.
> Meanwhile, the guy good enough to do that is also good enough to routinely
> hijack his domain name for short periods of time.
>
> Game Over.
>
> How about another, even *easier* scenario.
>
> I set up a nice little retail shop that specializes in hard-to-find items.
> I scour the 'net for things people can't seem to find anywhere else, not
> even eBay.  Nothing big or really expensive, just odd parts and pieces of
> things.
>
> I build a nice big web-site catalog shopping cart.
>
> I buy a Cert for a whopping $119.
>
> I collect the credit cards for a day or two, I charge them nine ways to
> Sunday, and I take off.
>
> Game Over.
>
> How about an even *easier* scenario:
>
> I find a web-site that is storing the credit-card numbers in their database,
> and rip them off.
>
> Game Over.
>
> >that issued his certificate, he may as well let you run your rogue site
> >off of his server; it's the same difference.
>
> Exactly!
>
> Or, he may as well be the criminal and *GET* a C&A signed certificate for
> his criminal web-site.
>
> I do not trust that a C&A Signed Cert is worth the bits its stored in.
>
> If you trust Microsoft with Security, shop away.
>
> >Think of it this way. Let's use https://www.amazon.com/ as an example.
> >Do you trust doing business with them? I sure do; at least I trust 100%
> >that my HTTP requests are going to get to the www.amazon.com server
> >safely. If someone stole their SSL certificate:
>
> Forget amazon.com.
>
> Real-world example from *MY* personal life:  Stick with unknowncompany.com
> -- a site you do *NOT* know, you do *NOT* trust, but they are the only ones
> that have the power-supply you need to run your laptop.
>
> You can:
> A) Throw away your laptop.
> B) Risk the fact that an unknown site with a "C&A Signed Certificate"
> (Ooh I'm impressed (not)) is the only one who can sell you the part you
> need to power the laptop.
> C) Try (and fail miserably) to find the part in "real" stores, and go back
> to A or B.
>
> Yes, this really happened to me.
>
> Yes, I really bought the thing on-line.
>
> No, I had no trust that they weren't crooks or at least incompetents.
>
> Yes, that's why the current system is insufficient.
>
> Yes, that's why I think it is ridiculous that people have essentially been
> trained to trust that little lock icon in the browser, no matter how naive
> that is, and how untrustworthy it is.
>
> >Now, on to "stealing" their domain name. All of a sudden, Amazon is
> >getting no traffic. Think they won't notice?
>
> Again, forget Amazon.
>
> There *ARE* on-line retailers who don't get any traffic, whose ISP's are so
> crappy their site is down all the time.
>
> Think they would notice?
>
> How quickly?
>
> What's their response?  Call up the ISP and complain, and the ISP says
> "Hmmm, it's working okay now.  Probably just a network outage"
>
> >Think it matters since the
> >HTTP requests you'll be receiving can't be decrypted by you anyway?
>
> Assume I've also stolen their Cert and keys and whatever else it takes to
> steal your credit card number.
>
> Yes, there are fewer sites where that's possible, but is it 0?  No.  Is it
> growing, as more and more mom-n-pop on-line stores are built on $20/month
> hosts with crappy Security?
>
> Are you telling me you've never walked in t

Re: [PHP] HTTPS vs. HTTP ?

[Justin French]

on 08/07/02 10:48 AM, Mark Charette ([EMAIL PROTECTED]) wrote:

> Or, even easier and "no tech", I get a low-paying job in some convenience
> store, and make copies of the credit card receipts.
> 
> Game Over.
> 
> Using a credit card anywhere involves trust. Period. End of story.

Couldn't agree more.  Went out for lunch yesterday, and the waiter had my
card for at least 5 minutes.  Worse still, they've probably got 5 years of
receipts and cc#'s (with signatures!!) stored in  a cardboard box in their
office.

I think the only difference (I guess) between the offline and online worlds
is that 1000's of CC#'s stored online in a digital format (eg database) is a
lot more enticing than 1000's of cc#'s stored on little bits of paper.

I guess to a "hacker" the thought of breaking a password is a little more
enticing than breaking a window too!


Justin French


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] HTTPS vs. HTTP ?

[Chris Shiflett]

I think I'm going to forget trying to explain the technical details, 
because somehow this conversation is completely missing the point now. :)

SSL allows you to be sure that your credit card number is getting safely 
and securely to the Web site identified by a certain domain name. That's 
all it does, but that is not something trivial. Are you trusting a 
domain name by trusting SSL? No, not exactly. You are trusting the 
system that I explained in great detail to ensure that your 
communication is reaching that domain name securely (not just 
encrypted). This is a significant thing, and it is a system that I have 
great respect for.

Everything else is no different than using your credit card at a 
physical establishment, so it's not really helpful to debate those 
points anyway.

Chris

P.S. - CA means Certificate Authority. C&A means Certification and 
Accreditation. The two cannot be used interchangeably.


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] HTTPS vs. HTTP ?

[Mark Charette]

Or, even easier and "no tech", I get a low-paying job in some convenience
store, and make copies of the credit card receipts.

Game Over.

Using a credit card anywhere involves trust. Period. End of story.

-Original Message-
From: Richard Lynch [mailto:[EMAIL PROTECTED]]

How about an even *easier* scenario:

I find a web-site that is storing the credit-card numbers in their database,
and rip them off.

Game Over.


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] HTTPS vs. HTTP ?

[Richard Lynch]

>In public key cryptography, it is the *keys*, not the digital 
>certificate that encrypt/decrypt the communication.

Okay.

I break into his co-lo, I walk off with his computer, and I break into his
office, I walk off with his computers, I kill the guy, and I kidnap his
wife.

I have everything.

I have his Certs, his keys, his server, his domain, *EVERYTHING*.

This is not *IMPOSSIBLE*, no matter how "unlikely" it is painted.

But let me paint a more-likely scenario.

Some guy sets up a tiny on-line retail shop on his $20/month ISP. 
Whoo-Hooo!

He gets hacked, never even notices, and his Certs and keys are all stolen. 
Meanwhile, the guy good enough to do that is also good enough to routinely
hijack his domain name for short periods of time.

Game Over.

How about another, even *easier* scenario.

I set up a nice little retail shop that specializes in hard-to-find items. 
I scour the 'net for things people can't seem to find anywhere else, not
even eBay.  Nothing big or really expensive, just odd parts and pieces of
things.

I build a nice big web-site catalog shopping cart.

I buy a Cert for a whopping $119.

I collect the credit cards for a day or two, I charge them nine ways to
Sunday, and I take off.

Game Over.

How about an even *easier* scenario:

I find a web-site that is storing the credit-card numbers in their database,
and rip them off.

Game Over.

>that issued his certificate, he may as well let you run your rogue site 
>off of his server; it's the same difference.

Exactly!

Or, he may as well be the criminal and *GET* a C&A signed certificate for
his criminal web-site.

I do not trust that a C&A Signed Cert is worth the bits its stored in.

If you trust Microsoft with Security, shop away.

>Think of it this way. Let's use https://www.amazon.com/ as an example. 
>Do you trust doing business with them? I sure do; at least I trust 100% 
>that my HTTP requests are going to get to the www.amazon.com server 
>safely. If someone stole their SSL certificate:

Forget amazon.com.

Real-world example from *MY* personal life:  Stick with unknowncompany.com
-- a site you do *NOT* know, you do *NOT* trust, but they are the only ones
that have the power-supply you need to run your laptop.

You can:
A) Throw away your laptop.
B) Risk the fact that an unknown site with a "C&A Signed Certificate"
(Ooh I'm impressed (not)) is the only one who can sell you the part you
need to power the laptop.
C) Try (and fail miserably) to find the part in "real" stores, and go back
to A or B.

Yes, this really happened to me.

Yes, I really bought the thing on-line.

No, I had no trust that they weren't crooks or at least incompetents.

Yes, that's why the current system is insufficient.

Yes, that's why I think it is ridiculous that people have essentially been
trained to trust that little lock icon in the browser, no matter how naive
that is, and how untrustworthy it is.

>Now, on to "stealing" their domain name. All of a sudden, Amazon is 
>getting no traffic. Think they won't notice?

Again, forget Amazon.

There *ARE* on-line retailers who don't get any traffic, whose ISP's are so
crappy their site is down all the time.

Think they would notice?

How quickly?

What's their response?  Call up the ISP and complain, and the ISP says
"Hmmm, it's working okay now.  Probably just a network outage"

>Think it matters since the 
>HTTP requests you'll be receiving can't be decrypted by you anyway?

Assume I've also stolen their Cert and keys and whatever else it takes to
steal your credit card number.

Yes, there are fewer sites where that's possible, but is it 0?  No.  Is it
growing, as more and more mom-n-pop on-line stores are built on $20/month
hosts with crappy Security?

Are you telling me you've never walked in to an eCommerce site to find
major, huge, gaping holes in their security?

Are you telling me those sites don't exist?

Actually, assume the other way around -- I've hacked his server, stolen his
Certs and private keys, and now...

Can I *sometimes* hijack his domain name, for brief periods of time?  Say, a
few minutes?  Just long enough to steal a few CC numbers, and then "blip!"
un-steal it?

Okay, *I* can't do it, but aren't there a fair number of hackers "out there"
that can?

Who's gonna notice that?  Some orders go missing?  The site is mysteriously
"down" or "off" the net for a few minutes, or maybe even *less* than a
minute.  A couple customer complaints.  Maybe even a customer swears up and
down that we must have "lost" his CC # because it's the only place he used
it.  *MAYBE* a good company will catch on.  I bet against.

But let's even assume our site-owner *NOTICES* his stolen domain name, and
maybe even knows he got hacked and the Certs and keys all got stolen.

Let's even give them the benefit of the doubt and assume they reported the
hack within, oh 24 hours, to their C&A and they get a shiny new Certificate.

I, Richard Lynch, do *NOT* trust the C&A Signers (Microsoft, et al) to
correctly re

Re: [PHP] HTTPS vs. HTTP ?

[Miguel Cruz]

On Sat, 6 Jul 2002, Richard Lynch wrote:
> I think we both agree that any old certificate is secure from snooping,
> right?

I would disagree with that.

In order to snoop on a connection, you need to have some access to the 
link.

This may be by being in the same building with one of the endpoints, or by 
being in the same building as one of the ISPs involved, or by having 
remotely compromised a machine in one of the above locations.

If you have this access, then you can divert packets. You can move wires
around, or you can outrace a router and take over a connection as it's 
being initiated.

Therefore you can present a certificate which is indistinguishable to the 
client from the "real" server's self-signed certificate, effectively 
hijacking the session.

> Yes, a C&A signed certificate is nominally "better" than a non-signed one,
> since you know that at some point, somebody paid somebody at least $119
> (US), and that the certificate has the same domain name as the domain name
> of the computer you are now surfing to.
> 
> You don't know it's the same computer, though, right?  It could easily be a
> stolen Cert and hijacked domain.
> 
> For that matter, you don't know that a CRIMINAL purchased the C&A signed
> Certificate in the first place.

No, but the chances of each of these other things happening are 
progressively less.

A certificate signed by a known certificate authority tells you that the 
server you're talking with has a unique token provided to the entity 
named. That's better than not knowing that. 

miguel


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] HTTPS vs. HTTP ?

[Chris Shiflett]

I just explained this all in great detail, so please read that. I don't 
just think you are confused; I am positive you are.

However, I did notice that you are the same person who gives many good 
answers to other peoples' questions. This giving of your time to be 
helpful is commendable, and I apologize for mistaking you for a troll. I 
just honestly don't understand the confusion.

I'll only correct a couple of points that you seem to keep bringing up 
that are incorrect. I believe these might be the root of all confusion.

Richard Lynch wrote:

>Work with me here, okay?
>
>I steal his SSL certificate.
>I steal his domain name.
>I put them on my own web-server.
>
>When/how do the C&A people catch this?
>

In public key cryptography, it is the *keys*, not the digital 
certificate that encrypt/decrypt the communication.

In your example above, how do you propose stealing "his" private key? It 
is in his Web server, right? You have his digital certificate, but that 
only guarantees that his pulic key is associated with his domain name. 
Even if you can "steal" his domain name and somehow get traffic going to 
you, you can't decrypt the communication without the private key. This 
is why I tried to explain the necessity of generating the request for a 
digital certificate from the Web server that it will be installed on. If 
you steal his entire server as well and he doesn't report it to the CA 
that issued his certificate, he may as well let you run your rogue site 
off of his server; it's the same difference.

Think of it this way. Let's use https://www.amazon.com/ as an example. 
Do you trust doing business with them? I sure do; at least I trust 100% 
that my HTTP requests are going to get to the www.amazon.com server 
safely. If someone stole their SSL certificate:

1. They wouldn't be able to install it on any other Web server anyway 
(your item 3 above is invalid)
2. It only guarantees that Amazon's public key really belongs to 
www.amazon.com - we knew that already

So, you've done nothing.

Now, on to "stealing" their domain name. All of a sudden, Amazon is 
getting no traffic. Think they won't notice? Think it matters since the 
HTTP requests you'll be receiving can't be decrypted by you anyway?

>If I *really* trust the person who owns a domain name, they are going to
>take care of any hijack/theft just as quickly with an unsigned cert as they
>are with a signed cert.  I don't trust the C&A people to facilitate that
>process any faster or better than somebody I actually *DO* trust in the
>first place -- The person I personally know who owns that domain name who is
>going to make damn sure they catch and rectify any hijacking with or without
>a signed Cert as fast as possible.  I trust that person because I know them,
>not the C&A people I don't know personally, and who have *PROVEN* themselves
>untrustworthy.  I trust people, not corporations, not technology, and
>*CERTAINLY* not the C&A Signers.
>

This is the other major misunderstanding. How is your friend supposed to 
"take care of any hijack/theft" exactly? If someone "hijacks" all of his 
traffic, sure, he might notice a lack of traffic. However, what if only 
a small audience is targetted? A few people mistakenly go to the wrong 
www.friend.org site and do business. If there was no SSL warning letting 
them know that something was wrong, they would happily do business.

Your friend may be the best Web surfer in the world, but I doubt he can 
keep up with every Web site on the Web at all times to make sure that no 
one else is impersonating him. He has to rely on the technology, and 
that technology is SSL.

That's all for me. I'm going to start charging you for more information 
about SSL. :) I still strongly suggest you read a book. I even suggested 
a single 50 page chapter that will probably clarify everything for you. 
You seem to think you have a grasp about what is going on, but I can 
assure you that you don't.

I don't know how much clearer I can get. I've got other work to do.

Cheers.

Chris


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] HTTPS vs. HTTP ? - the weakest link

[B.C. Lance]

sorry to barge in. but the weakest link ain't in ssl. doesn't really 
matter how secure vs insecure it is. you can come up with the most 
secure technology in the whole world that no one can break into. the 
weakest link lies on the user/customer themselves.

you just need a trojan horse in their computer and there goes the 
neighbourhood. they can by all means send their credit card information 
over to amazon.com. but this piece of information will still be open to 
the person who plant the horse in the machine.

so i suppose the debate over here should really be: is ecommerce safe?
and not: http vs https


just my 2 cents
b.c. lance


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] HTTPS vs. HTTP ?

[Chris Shiflett]

Alberto Serra wrote:

> ðÒÉ×ÅÔ! 


I've always wondered what this is exactly. I'm going to assume it's a 
friendly greeting. :)

> Chris Shiflett wrote:
>
>> Richard,
>>
>>> Do you really believe that for $200 (or $119, or $500) that they 
>>> "proven"
>>> themselves trustworthy?
>>
>
> LOL no, I don't. As a matter of fact crooks usually have more money in 
> their pockets than honest people do, so it's highly possible that a 
> crook will pay the money while the innocent will save his last cent :)) 


Please watch the attribution here. I never posed that question (Do you 
really believe ...), as it is very misleading and would indicate that I 
have very little knowledge about PKI systems, which is not the case. I 
know that the purchase of a certificate from a trusted Certificate 
Authority is a very important part of the security that SSL provides, 
and I would not pose a rhetorical question in a weak attempt at 
trivializing this.

>> Now you've changed from "secure" to "secure from snooping." Notice 
>> the difference? It is significant. Like I said before, encrypting the 
>> transmission is useless by itself. To put it plainly:
>>
>> encryption != security
>>
>> What if you trust your friend who owns safeplace.org, and you want to 
>> do business with him? Maybe you visit his site and enter a credit 
>> card number somewhere. Thankfully, you notice that the lock icon is 
>> showing, and that he is using SSL. With this warped idea of SSL where 
>> encryption is all that counts, what if you find out that you're not 
>> really on safeplace.org? You're really at evilcriminal.org, and he 
>> has a virtual domain setup for safeplace.org. Also, he generated his 
>> own certificate for safeplace.org using his own CA (good thing there 
>> was not C&A process to undergo). So you have now sent the evil 
>> criminal your credit card number because you trusted his domain name. 
>> Good thing it's secure, right?
>
>
> So, let's see if I got you right:
>
>   1) SSL just says we our packets are difficult to open, that is,
>  they are encrypted. Nothing more 


NO! :)

That's what some other guy was trying to say. He is wrong.

SSL does much more than encrypt the communication. Part of my response 
was a bit satirical in a weak attempt at pointing out how ridiculous a 
notion this is. I guess it didn't help very much. :)

Note the use of the phrase, "With this warped idea of SSL where 
encryption is all that counts"

I apologize for adding to the confusion there. I was trying to point out 
how insecure this model would be if encryption were all that SSL 
provided and the only trust involved was the trust of a domain name.

>   2) Our packets are difficult to open but they are totally open
>  to Uncle Sam's control software, as the RSA thingy cannot
>  shield them from "governmental inspection", which makes sense
>  if you are writing software for an american citizen but
>  it's pretty annoying if your customer is from somewhere else.


No government, as far as I know, can break the public key cryptography 
currently being used by most SSL-enabled sites (using the strong 
security - 128 bit certificates). This includes the United States.

Now, SSL only encrypts your communication in transit, of course. I'm 
sure your local government could find a way to make the entity you are 
communicating with release the information in the communication to them. 
This is, of course, outside the scope of SSL.

>   3) A key is nothing more than a negotiation token, a mere building
>  brick that is used to fire the process.


A key, when spoken of as one entity, is a key pair. It contains both the 
public and private keys. The use of these in cryptography is called 
asymmetric cryptography. To understand asymmetric cryptography, it is 
helpful to first explain what symmetric cryptography is.

Symmetric cryptography is basically the use of a single key for the 
encryption and decryption. Most two-way encryption algorithms you are 
probably familiar with use this approach. For two people to effectively 
encrypt their communication with this approach, it is necessary for both 
parties to have the same key. To submit this key over the Internet would 
be a poor idea, because it could be intercepted, right? Ironically, most 
keys for use with symmetric cryptography are distributed over the 
Internet using asymmetric crptography. :) Others use some sort of 
physical transfer, like meeting each other on a dark street corner with 
a briefcase. :)

The problem with trying to use this type of approach to encrypt 
communication between a Web client and a Web server is pretty clear. If 
your customers can be anyone, then anyone must have access to the key. 
Thus, all of your customers would be able to decrypt communication from 
all of your other customers. Otherwise, if each client's communication 
was encrypted using a different key, you would have to have a separate 
key for each client, *plus* you would have to hav

Re: [PHP] HTTPS vs. HTTP ?

[Richard Lynch]

>Honestly, I think you need to just buy on book on this. I think I 
>explained things pretty clearly, and your confusion now seems to be 
>based more on a lack of trusting my explanation more than anything. I 
>can't imagine how you could still be this confused.

What I can't imagine is how confused you must think I am -- Since I'm not AT
ALL confused.

>I will try to explain once more for the benefit of readers who may be 
>wondering if anything you said is true.

A great deal, nay all, of what I said was true.

Unfortunately, what you understood of it, was not true -- But that's not
what I typed.

>>No, the *TRANSMISSION* is just as secure from snooping.  It's the
>>*RECIPIENT* whom you trust, or not.  Maybe they've hijacked DNS records and
>>are masquereding.  Maybe they just didn't pay the $200.  Maybe they paid
>>$200 and are crooks.
>>
>>Do you really believe that for $200 (or $119, or $500) that they "proven"
>>themselves trustworthy?
>>
>
>Now you've changed from "secure" to "secure from snooping." Notice the 
>difference? It is significant. Like I said before, encrypting the 
>transmission is useless by itself. To put it plainly:

Notice how I first said *IN* *TRANSMISSION*.

Now, apparently, to *YOU* that wasn't sufficient to indicate:  "while the
packets are travelling from your browser to their destination".

When I first said "in transmission":

I did not mean "reaching the right destination"

I did not mean "the destination was worthy of trust"

I did not mean "reaching any destination at all"

I just meant "while the packets are travelling from your browser to their
destination" (whatever that destination might be).

Somehow, you read that as "Definitely reaching the intended party, and the
intended party being trusted"

Thus, I intentionally *ADDED* "secure from snooping" in my later post to
clarify what *I* mean when I say "in transmission".  I just mean "in
transmission".  Not reaching any particularly good nor bad end-point for
that transmission.

I think we both agree that any old certificate is secure from snooping,
right?

Now, since the only way I can see for it to be transmitted to the wrong
party at all would be for the evil-doer to hijack the domain name as well as
the SSL cert, I kinda figured it was a foregone conclusion the it was not
the "transmission" at issue -- It's the *DESTINATION* at risk.

Apparently I should have spelled that out from the beginning, since you
obviously misunderstood (and *still* misunderstand) my point.

>encryption != security

Obviously, since they aren't spelled the same way.

C&A SSL != security

either.

"More" secure than just encryption?  I suppose...  But not really enough
more to inspire any real confidence in a C&A Signed Certificate.

>What if you trust your friend who owns safeplace.org, and you want to do 
>business with him? Maybe you visit his site and enter a credit card 
>number somewhere. Thankfully, you notice that the lock icon is showing, 
>and that he is using SSL. With this warped idea of SSL where encryption 
>is all that counts, what if you find out that you're not really on 
>safeplace.org? You're really at evilcriminal.org, and he has a virtual 
>domain setup for safeplace.org. Also, he generated his own certificate 
>for safeplace.org using his own CA (good thing there was not C&A process 
>to undergo). So you have now sent the evil criminal your credit card 
>number because you trusted his domain name. Good thing it's secure, right?

What if evilcriminal.org *STOLE* the C&A signed certificate from
safeplace.org as well as hijacked their domain name?

What if evilcriminal.org set up safeplace.org and just *PAID* friggin'
Microsoft for a C&A signed certificate in the *FIRST* place.

Yes, a C&A signed certificate is nominally "better" than a non-signed one,
since you know that at some point, somebody paid somebody at least $119
(US), and that the certificate has the same domain name as the domain name
of the computer you are now surfing to.

You don't know it's the same computer, though, right?  It could easily be a
stolen Cert and hijacked domain.

For that matter, you don't know that a CRIMINAL purchased the C&A signed
Certificate in the first place.

I say again -- Do you *REALLY* believe that for $119, or even $500, that a
complete background check is run on the people running all those web-sites
with perfectly valid SSL Certificates that make the pretty lock icon close? 
I sure don't.

I consider a C&A Signed Certificate not significantly more reliable,
trustworthy, nor "safe" than an unsigned one.

I don't trust the signers.

I don't trust that the people on the other end are who they say they are.

I have a low trust factor all around.

>Hopefully it is clear that the trust in SSL relies on the trust of the 
>certificate which relies on the trust of the root CA that issued that 
>certificate. Trusting a domain name makes absolutely no sense.

Sigh.

I'll say it again:

I don't trust a domain name.

I have an *EQUAL* di

Re: [PHP] HTTPS vs. HTTP ?

[Alberto Serra]

ðÒÉ×ÅÔ!

Chris Shiflett wrote:
> Richard,
>> Do you really believe that for $200 (or $119, or $500) that they "proven"
>> themselves trustworthy?

LOL no, I don't. As a matter of fact crooks usually have more money in 
their pockets than honest people do, so it's highly possible that a 
crook will pay the money while the innocent will save his last cent :))

> Now you've changed from "secure" to "secure from snooping." Notice the 
> difference? It is significant. Like I said before, encrypting the 
> transmission is useless by itself. To put it plainly:
> 
> encryption != security
> 
> What if you trust your friend who owns safeplace.org, and you want to do 
> business with him? Maybe you visit his site and enter a credit card 
> number somewhere. Thankfully, you notice that the lock icon is showing, 
> and that he is using SSL. With this warped idea of SSL where encryption 
> is all that counts, what if you find out that you're not really on 
> safeplace.org? You're really at evilcriminal.org, and he has a virtual 
> domain setup for safeplace.org. Also, he generated his own certificate 
> for safeplace.org using his own CA (good thing there was not C&A process 
> to undergo). So you have now sent the evil criminal your credit card 
> number because you trusted his domain name. Good thing it's secure, right?

So, let's see if I got you right:

   1) SSL just says we our packets are difficult to open, that is,
  they are encrypted. Nothing more

   2) Our packets are difficult to open but they are totally open
  to Uncle Sam's control software, as the RSA thingy cannot
  shield them from "governmental inspection", which makes sense
  if you are writing software for an american citizen but
  it's pretty annoying if your customer is from somewhere else.

   3) A key is nothing more than a negotiation token, a mere building
  brick that is used to fire the process.

   4) the "trust" you buy is something like a fixed IP number, that is
  the guys in the major do certify that you *are* who you pretend
  to be.

   5) If the one I am pretending to be is a criminal, being trusted by
  Verisign (or whoever in their place) won't make any difference.
  Their "license" just means that you are really dealing with those
  you think you are dealing with and that they do bear legal
  responsibility for whatever will happen in the transaction.
  Again, legal action will eventually have different
  results depending on where the trusted company is based, since
  not all countries have the same normative set. But that has
  nothing to do with the SSL protocol in itself.

Now, there's a question regarding point 4). What if someone from 
www.goodguys.com
gets the certified key pair and hands it over to some crook outside the 
company? I hope this is not just as easy as it sounds (the key pairs 
will probably check something in the environment before starting to 
shout "YEAAAH!! IT'S MEEE!!!") but still...

As for point 2), please get me right. I have my own political opinions 
as anybody
else, but my concern here is a professional one, since my customers are 99%
not americans. Small-mid sized companies (including mine) usually do not 
give a
damn about having their messages read by american eyes (we are simply 
not worth the trouble of looking in our archives) but large companies 
and Govt. organizations are *much* less indifferent to the subject, and 
I guess it's understandable, they want their privacy to be for real.

ÐÏËÁ
áÌØÂÅÒÔÏ
ëÉÅ×

-- 


@-_=}{=_-@-_=}{=_-@-_=}{=_-@-_=}{=_-@-_=}{=_-@-_=}{=_-@-_=}{=_-@

LoRd, CaN yOu HeAr Me, LiKe I'm HeArInG yOu?
lOrD i'M sHiNiNg...
YoU kNoW I AlMoSt LoSt My MiNd, BuT nOw I'm HoMe AnD fReE
tHe TeSt, YeS iT iS
ThE tEsT, yEs It Is
tHe TeSt, YeS iT iS
ThE tEsT, yEs It Is...


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] HTTPS vs. HTTP ?

[Chris Shiflett]

Richard,

Honestly, I think you need to just buy on book on this. I think I 
explained things pretty clearly, and your confusion now seems to be 
based more on a lack of trusting my explanation more than anything. I 
can't imagine how you could still be this confused.

I will try to explain once more for the benefit of readers who may be 
wondering if anything you said is true.

Richard Lynch wrote:

>No, the *TRANSMISSION* is just as secure from snooping.  It's the
>*RECIPIENT* whom you trust, or not.  Maybe they've hijacked DNS records and
>are masquereding.  Maybe they just didn't pay the $200.  Maybe they paid
>$200 and are crooks.
>
>Do you really believe that for $200 (or $119, or $500) that they "proven"
>themselves trustworthy?
>

Now you've changed from "secure" to "secure from snooping." Notice the 
difference? It is significant. Like I said before, encrypting the 
transmission is useless by itself. To put it plainly:

encryption != security

What if you trust your friend who owns safeplace.org, and you want to do 
business with him? Maybe you visit his site and enter a credit card 
number somewhere. Thankfully, you notice that the lock icon is showing, 
and that he is using SSL. With this warped idea of SSL where encryption 
is all that counts, what if you find out that you're not really on 
safeplace.org? You're really at evilcriminal.org, and he has a virtual 
domain setup for safeplace.org. Also, he generated his own certificate 
for safeplace.org using his own CA (good thing there was not C&A process 
to undergo). So you have now sent the evil criminal your credit card 
number because you trusted his domain name. Good thing it's secure, right?

Hopefully it is clear that the trust in SSL relies on the trust of the 
certificate which relies on the trust of the root CA that issued that 
certificate. Trusting a domain name makes absolutely no sense.

>>>Yes, the basic model for the security of all eCommerce is:
>>>
>>>"You pay some large corporation $200, and they trust you."
>>>
>>>  
>>>
>>No, you pay some large corporation money, because the majority of 
>>browsers currently in use trust certificates issued by that corporation. 
>>They've had to undergo extensive C&A processes to ensure the integrity 
>>of their operation, and they've also had to shell out some big money to 
>>Microsoft and Netscape to have their root certificates installed and 
>>trusted into their browsers.
>>
>>
>
>And for the $200, they do a background check on everybody, or what?
>
>What's to stop a criminal from getting a $200 certificate?  Nothing.
>
>How do you *KNOW* that web-site isn't run by a criminal?  How do you know
>they aren't collecting credit-card numbers?  How do you *KNOW* they aren't
>storing them insecurely?
>
>Fact is:  All you *KNOW* is that they paid Thawte, Microsoft, or some other
>large corporation $200.  You don't know *anything* else about them.
>

This, I believe, is where your largest confusion lies. Read my first 
response to this again (quoted above). Did you read it? Read it again.

The C&A process is what someone like VeriSign undergoes, not the guy 
buying a certificate for evilcriminal.org.

>>The browser *should* issue a warning when the identity of the Web server 
>>it is about to communicate with cannot be guaranteed. You seem to be 
>>confused about where the trust lies. If I trust the Web site 
>>http://www.mybuddy.org/ (hypothetical best friend's Web site), does that 
>>mean I should trust any certificate that is issued to www.mybuddy.org? 
>>What if the certificate's root CA was a criminal's PC? Are you *sure* 
>>that's your friend's Web site that you are communicating with?
>>
>>
>
>If I *TRUST* mybuddy.org, the I *TRUST* them not to install a Certificate
>from a criminal's PC !!!
>
>I *TRUST* them not to have non-repudiated Certificates floating around out
>there.
>
>Conversely, if I don't know squat about mybuddy.org, all I know is they paid
>somebody else I don't trust $200.
>
>Maybe you just trust big corporations more than I do.  I dunno.
>
>All I know is, the "Trust Model" *IS*
>
>Somebody I don't trust pays somebody else I don't trust $200.  Period.
>
>Doesn't instill a lot of faith in the system for *ME*.  Might be enough for
>you to have Faith, but not me.
>

Alright, I'm starting to think you're trolling now. That might be funny 
on Slashdot, but it doesn't belong on this mailing list. I will clarify 
for those who need this information.

Here you are trusting a domain name again. That's a risky business, and 
luckily you didn't create a security model that anyone would implement 
on the Web. The same question arises yet again. How do you know that's 
the real mybuddy.org? Because it has a certificate from a CA that is not 
from a criminal's PC, right? How can you tell the difference between a 
CA from a criminal's PC and one from a place like VeriSign? Do you think 
it's just name recognition? Surely not. When you click past the warning 
that you seem to 

Re: [PHP] HTTPS vs. HTTP ?

[Richard Lynch]

>>But unless you paid the $200 to get it from a CA, surfers will see a nasty
>>(and totally inaccurate/misleading) warning about how insecure it is.
>>
>
>They should. To do otherwise would be inaccurate and misleading.
>
>>The transmission is no less secure -- It's that the web-server on the other
>>end was too cheap to pay the $200 for a CA key.
>>
>
>No, the transmission is much less secure. You cannot be guaranteed the 
>identity of the Web server you're communicating with. You think just 
>because the HTTP transaction is encrypted that it is secure? What if 
>you're encrypted transaction is taking place with some criminal? You 
>still feel secure?

No, the *TRANSMISSION* is just as secure from snooping.  It's the
*RECIPIENT* whom you trust, or not.  Maybe they've hijacked DNS records and
are masquereding.  Maybe they just didn't pay the $200.  Maybe they paid
$200 and are crooks.

Do you really believe that for $200 (or $119, or $500) that they "proven"
themselves trustworthy?

>>Yes, the basic model for the security of all eCommerce is:
>>
>>"You pay some large corporation $200, and they trust you."
>>
>
>No, you pay some large corporation money, because the majority of 
>browsers currently in use trust certificates issued by that corporation. 
>They've had to undergo extensive C&A processes to ensure the integrity 
>of their operation, and they've also had to shell out some big money to 
>Microsoft and Netscape to have their root certificates installed and 
>trusted into their browsers.

And for the $200, they do a background check on everybody, or what?

What's to stop a criminal from getting a $200 certificate?  Nothing.

How do you *KNOW* that web-site isn't run by a criminal?  How do you know
they aren't collecting credit-card numbers?  How do you *KNOW* they aren't
storing them insecurely?

Fact is:  All you *KNOW* is that they paid Thawte, Microsoft, or some other
large corporation $200.  You don't know *anything* else about them.

>>Alas, the *BROWSER* makes it sound like the whole thing is very shady, when,
>>in reality, if you trust the web-site (certainly more than I trust
>>Microsoft!) then it's just as secure.
>>
>
>The browser *should* issue a warning when the identity of the Web server 
>it is about to communicate with cannot be guaranteed. You seem to be 
>confused about where the trust lies. If I trust the Web site 
>http://www.mybuddy.org/ (hypothetical best friend's Web site), does that 
>mean I should trust any certificate that is issued to www.mybuddy.org? 
>What if the certificate's root CA was a criminal's PC? Are you *sure* 
>that's your friend's Web site that you are communicating with?

If I *TRUST* mybuddy.org, the I *TRUST* them not to install a Certificate
from a criminal's PC !!!

I *TRUST* them not to have non-repudiated Certificates floating around out
there.

Conversely, if I don't know squat about mybuddy.org, all I know is they paid
somebody else I don't trust $200.

Maybe you just trust big corporations more than I do.  I dunno.

All I know is, the "Trust Model" *IS*

Somebody I don't trust pays somebody else I don't trust $200.  Period.

Doesn't instill a lot of faith in the system for *ME*.  Might be enough for
you to have Faith, but not me.

>However, if you do trust a certain CA (perhaps your own), you can import 
>your root certificate into your browser and check some boxes to trust 
>it. Luckily, browsers don't even allow a method for you to "trust" a 
>domain name.
>
>It is quite trivial to generate a certificate for www.amazon.com. It 
>isn't too terribly difficult to make someone's computer think 
>www.amazon.com is your Web site. Here come the encrypted credit card 
>numbers. Good thing they're secure. :)
>
>The point is, PKI isn't about encryption alone. In fact, the "textbook" 
>answer to the question of what services PKI provides is:
>
>1. Identification
>2. Authentication
>3. Authorization
>4. Integrity
>5. Confidentiality
>6. Non-Repudiation
>
>If it only provided confidentiality, quite honestly, PKI would be 
>useless as it is implemented today.

Do *YOU* trust the CA people to have thoroughly researched joesbotique.com
when you give them your credit card?

How do you know it's not a scam?

How do you know their certificate hasn't been stolen, and they haven't even
figured it out yet?  How do you know they were trustworthy people in the
first place?

You only *KNOW* that somebody, somewhere, at some time, paid $200 for that
"Certificate" and that nobody has noticed something skanky about it -- at
least not yet.

The more I think about this, the more I agree with people who just won't do
eCommerce at all...

-- 
Like Music?  http://l-i-e.com/artists.htm


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] HTTPS vs. HTTP ?

[Richard Lynch]

>On Fri, 5 Jul 2002, Richard Lynch wrote:
>> But unless you paid the $200 to get it from a CA, surfers will see a nasty
>> (and totally inaccurate/misleading) warning about how insecure it is.
>
>It is easy to launch a man-the-middle attack against a session being
>initiated between a client and a server with a self-signed certificate.  
>You just send the client a self-signed certificate of your own, and it
>can't tell it apart from the real one - same error message shows up.

"Easy" is relative.

What's more likely to occur:

A slime-ball with $200 makes a web-site to rip people off with a signed
certificate.
A hard-core hacker intercepts an HTTP connection.

Neither is a desired outcome.

The current Certificate Authority system works okay against the second one,
but doesn't really address the first.

-- 
Like Music?  http://l-i-e.com/artists.htm


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] HTTPS vs. HTTP ?

[Chris Shiflett]

Richard Lynch wrote:

>In the HTTPS exchange, however, extra key-pairs are generated on the fly,
>and the private half of the new pair are exchanged, encrypted with the
>public halfs of the old pairs, so that the server and the browser are using
>a UNIQUE public/private pair so that nobody can snoop on them...
>
>Or, at least, it works something like that...  I'm telling you, you really
>don't need to understand this stuff if it gives you a headache as bad as it
>gives me :-)
>

If you want a basic understanding of PKI, how it works, what problems it 
solves, etc., I highly recommend a single chapter in a single book that 
will give you enough of a foundation to "get it" (esr style).

_PKI:_Implementing_and_Managing_E-Security_ from RSA Press, Chapter 2 
(50 pages - very clear and not too technical).

Happy hacking.

Chris



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] HTTPS vs. HTTP ?

[Chris Shiflett]

Richard Lynch wrote:

>You can create your own SSL key pair very, very, very easily...
>
>But unless you paid the $200 to get it from a CA, surfers will see a nasty
>(and totally inaccurate/misleading) warning about how insecure it is.
>

They should. To do otherwise would be inaccurate and misleading.

>The transmission is no less secure -- It's that the web-server on the other
>end was too cheap to pay the $200 for a CA key.
>

No, the transmission is much less secure. You cannot be guaranteed the 
identity of the Web server you're communicating with. You think just 
because the HTTP transaction is encrypted that it is secure? What if 
you're encrypted transaction is taking place with some criminal? You 
still feel secure?

>Yes, the basic model for the security of all eCommerce is:
>
>"You pay some large corporation $200, and they trust you."
>

No, you pay some large corporation money, because the majority of 
browsers currently in use trust certificates issued by that corporation. 
They've had to undergo extensive C&A processes to ensure the integrity 
of their operation, and they've also had to shell out some big money to 
Microsoft and Netscape to have their root certificates installed and 
trusted into their browsers.

>Alas, the *BROWSER* makes it sound like the whole thing is very shady, when,
>in reality, if you trust the web-site (certainly more than I trust
>Microsoft!) then it's just as secure.
>

The browser *should* issue a warning when the identity of the Web server 
it is about to communicate with cannot be guaranteed. You seem to be 
confused about where the trust lies. If I trust the Web site 
http://www.mybuddy.org/ (hypothetical best friend's Web site), does that 
mean I should trust any certificate that is issued to www.mybuddy.org? 
What if the certificate's root CA was a criminal's PC? Are you *sure* 
that's your friend's Web site that you are communicating with?

However, if you do trust a certain CA (perhaps your own), you can import 
your root certificate into your browser and check some boxes to trust 
it. Luckily, browsers don't even allow a method for you to "trust" a 
domain name.

It is quite trivial to generate a certificate for www.amazon.com. It 
isn't too terribly difficult to make someone's computer think 
www.amazon.com is your Web site. Here come the encrypted credit card 
numbers. Good thing they're secure. :)

The point is, PKI isn't about encryption alone. In fact, the "textbook" 
answer to the question of what services PKI provides is:

1. Identification
2. Authentication
3. Authorization
4. Integrity
5. Confidentiality
6. Non-Repudiation

If it only provided confidentiality, quite honestly, PKI would be 
useless as it is implemented today.

Happy hacking.

Chris



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] HTTPS vs. HTTP ?

[Miguel Cruz]

On Fri, 5 Jul 2002, Richard Lynch wrote:
> But unless you paid the $200 to get it from a CA, surfers will see a nasty
> (and totally inaccurate/misleading) warning about how insecure it is.

It is easy to launch a man-the-middle attack against a session being
initiated between a client and a server with a self-signed certificate.  
You just send the client a self-signed certificate of your own, and it
can't tell it apart from the real one - same error message shows up.

miguel


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] HTTPS vs. HTTP ?

[Richard Lynch]

>For Miguel Cruz posting back there.  If I understand correctly, the private
>key are inside the public key.  Is this correct?

If you have an SSL (or SSH, or whatever) key thingie, it always comes as a
"pair"

The private half, and the public half.

You never, ever, ever, ever give the private half to anybody, anywhere, any
time.

You give the public half to, well, everybody.

Neither the public half nor the private half ever include the other.

A message encrypted with either half can only be decrypted with the other
half.

In the HTTPS exchange, however, extra key-pairs are generated on the fly,
and the private half of the new pair are exchanged, encrypted with the
public halfs of the old pairs, so that the server and the browser are using
a UNIQUE public/private pair so that nobody can snoop on them...

Or, at least, it works something like that...  I'm telling you, you really
don't need to understand this stuff if it gives you a headache as bad as it
gives me :-)

-- 
Like Music?  http://l-i-e.com/artists.htm


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] HTTPS vs. HTTP ?

[Richard Lynch]

>I saw that Microsoft has a Certificate Authority server package that allows
>you to create your own key.  Is there a way to do this in linux?  In this
>particular instance, it's me accessing my own web site.  I'd like to encrypt
>the session and I'm don't need someone to confirm anything.

You can create your own SSL key pair very, very, very easily...

But unless you paid the $200 to get it from a CA, surfers will see a nasty
(and totally inaccurate/misleading) warning about how insecure it is.

The transmission is no less secure -- It's that the web-server on the other
end was too cheap to pay the $200 for a CA key.

Yes, the basic model for the security of all eCommerce is:

"You pay some large corporation $200, and they trust you."

What kinda trust is worth $200, I don't know. :-^

Alas, the *BROWSER* makes it sound like the whole thing is very shady, when,
in reality, if you trust the web-site (certainly more than I trust
Microsoft!) then it's just as secure.

-- 
Like Music?  http://l-i-e.com/artists.htm


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] HTTPS vs. HTTP ?

[Richard Lynch]

>On Fri, 5 Jul 2002, Jerome Houston wrote:
>> if the browser is making a request, and it sees an https:// at the beginning 
>> of the request URL, it will :
>> 1.  get the domain's public key from a public key server
>> 2.  encrypt the whole request with the domain's public key
>> 3.  submit it to the web server.
>
>We have public key servers?

I know (think?) you're joking, but for any other readers... :-)

A "public key server" should not be confused with the public key on an SSL
(HTTPS) web-server.

A "public key server" lets any yahoo on the planet upload the "public" half
of the key-pair which is supposed to uniquely identify themselves.  Alas,
all too many people don't even understand how important it is to keep the
PRIVATE half of their key private, so public key servers aren't all that
useful.

The SSL Certificate you paid $200 (or more) for has a public half in it,
which, in the course of the browser/server conversation about how to get the
stuff transmitted securely, is exchanged with the browser.

That does not mean your web-server is a public key server, of course.

The SSL Certificate also has a private half.  People you do not trust should
*NOT* ever be allowed access to that.

>Sort of. The server's key is used to encrypt the exchange of a new key
>which lasts only for the lifetime of the transaction. This ephemeral key
>is what's used to encrypt the actual data. But this nuance is probably not
>very important to understanding the practical issues of working with PHP 
>and HTTPs.

To be honest, none of this stuff is all that useful for the practical issues
:-)

You use URLs that start with HTTPS when you want stuff to be secure.

Everything that gets sent "to" an HTTPS from the browser is encrypted, and
everything the browser sends back from the HTTPS is encrypted.

You can safely ignore all the details of exactly how the HTTPS stuff is done
internally, unless you need to install/build your own SSL server.

>> Now, one of the things that many people are confused about is that they
>> think there must be a lock icon at the bottom of the browser when they
>> are entering sensitive info (like credit card numbers).  Nope.  The only
>> important thing is that the form which takes the sensitive data SUBMITS
>> to an https:// URL.  Because (as above) it will encrypt the request
>> (which includes the sensitive data) BEFORE it submits it over the
>> internet.  But most people don't know how to check that a form submits
>> to an to an https:// URL.
>
>Yup. You'd think that the browser developers would come up with a way to 
>indicate this (mouse pointer turning to a lock when hovering over a submit 
>button, etc.).

No, they're too busy adding more useless features and releasing incredibly
unstable code with little or no QA :-)

-- 
Like Music?  http://l-i-e.com/artists.htm


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] HTTPS vs. HTTP ?

[Miguel Cruz]

On Sat, 6 Jul 2002, Alberto Serra wrote:
> yes, but in that case your Apache is running just ONE web site. Most 
> people buy VirtualDomains which are namebased and not IP based. And they 
> cannot share an IP number with other sites with SSL, AFAIK. Or am I 
> misunderstanding the docs?

You're right, one IP number per HTTPs hostname. This is because the server 
sends its certificate - which contains the hostname - to the browser 
before the browser has told the server which hostname it is trying to 
reach.

miguel


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] HTTPS vs. HTTP ?

[Alberto Serra]

ðÒÉ×ÅÔ!

yes, but in that case your Apache is running just ONE web site. Most 
people buy VirtualDomains which are namebased and not IP based. And they 
cannot share an IP number with other sites with SSL, AFAIK. Or am I 
misunderstanding the docs?

ÐÏËÁ
áÌØÂÅÒÔÏ
ëÉÅ×

Jonathan Rosenberg wrote:
>  -Original Message-
> 
>>From: Alberto Serra [mailto:[EMAIL PROTECTED]]
>>Sent: Friday, July 05, 2002 8:54 PM
>>Cc: [EMAIL PROTECTED]
>>Subject: Re: [PHP] HTTPS vs. HTTP ?
> 
> 
>>Besides, using an HTTPS server implies
>>(correct me if I am wrong) consuming an IP number,
>>. . .
> 
> 
> Ok ... you're wrong.  HTTPS just uses a different port, same IP
> address.
> 
> 
>>ÐÏËÁ
>>áÌØÂÅÒÔÏ
>>ëÉÅ×
> 
> 
> --
> JR
> 
> 
> 



-- 


@-_=}{=_-@-_=}{=_-@-_=}{=_-@-_=}{=_-@-_=}{=_-@-_=}{=_-@-_=}{=_-@

LoRd, CaN yOu HeAr Me, LiKe I'm HeArInG yOu?
lOrD i'M sHiNiNg...
YoU kNoW I AlMoSt LoSt My MiNd, BuT nOw I'm HoMe AnD fReE
tHe TeSt, YeS iT iS
ThE tEsT, yEs It Is
tHe TeSt, YeS iT iS
ThE tEsT, yEs It Is...


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] HTTPS vs. HTTP ?

[Miguel Cruz]

On Fri, 5 Jul 2002, Scott Fletcher wrote:
> For Miguel Cruz posting back there.  If I understand correctly, the private
> key are inside the public key.  Is this correct?

I'm not completely sure I understand your question. When you visit a site 
using HTTPS, here's basically what happens:

1. Your browser initiates the connection and sends the server information 
about which key types it supports. 

2. The server sends you its certificate, which is the server's public key 
signed with a certificate authority's private key. It also sends a 
response to the client's list of supported key types, so that they can 
find some common ground.

3. Your browser verifies the certificate using the certificate authority's 
public key, which was distributed with the browser.

4. Based on its capabilities (as sent in step 1) and the server's 
capabilities (as received in step 2), the browser generates a new key to 
be used for this session. It's a symmetric key, no public or private 
stuff. The browser sends this to the server.

5. From here on, the browser and server use a key derived from this 
symmetric key to encode the data they send back and forth.

It's possible you were just asking whether, as a general matter, private
keys are contained within public keys. No, with public-key cryptography as
I understand it, that's not the case. They are related to each other but 
neither contains the other.

First, you need an algorithm which is relatively easy to operate in one 
direction, but is next to impossible in the other direction. As a silly 
example, "adding 5 to the number" is a bad algorithm for this application 
since it's easy to reverse - just subtract 5 instead. 

A pretty common algorithm involves the product of two very large prime 
numbers and depends on the difficulty of guessing, from the product, what 
those two primes were. I'll spare you the math, but for a trivial example, 
see if you can figure out the two factors of 31,622,417 are (hint: they're 
both 4-digit numbers). The problem gets substantially harder as the 
numbers grow.

The public and private key are derived from the product and its prime
factors. Either of these keys can be combined with arbitrary data to
produce encoded data that can easily be decoded with the use of the other
key. However, going the other way - for instance, arriving at the private
key given the public key and encoded data - is next to impossible because
the algorithm is difficult to reverse. Just like it was really easy for me
to multiply those two prime numbers to get 31622417 but it'll take you a
much longer time to figure out what they were, even though it's not a very
big number and there's only a single right answer.

miguel


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] HTTPS vs. HTTP ?

[Miguel Cruz]

On Fri, 5 Jul 2002, Lazor, Ed wrote:
> I saw that Microsoft has a Certificate Authority server package that allows
> you to create your own key.  Is there a way to do this in linux?  In this
> particular instance, it's me accessing my own web site.  I'd like to encrypt
> the session and I'm don't need someone to confirm anything.

Sure. OpenSSL comes with all the tools you need to become your own 
certificate authority.

http://www.openssl.org/

miguel


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php