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
x27;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: [EM
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
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 opera
>>>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
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
n 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
>>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 abou
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
ðÒÉ×ÅÔ!
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 (
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 ac
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
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.
ðÒÉ×ÅÔ!
>> 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 jud
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
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
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 i
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 eve
>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.
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 endpoin
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 a
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
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
>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 confus
ðÒÉ×ÅÔ!
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
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 m
>>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 othe
>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
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 sno
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 mislea
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 serve
>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 ha
>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 ca
>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
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 r
:
> -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 w
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. You
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
-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,
>
Miguel Cruz wrote:
> 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.).
>
ðÒÉ×ÅÔ!
Yes, it's a GREAT idea! would make our HTTPS processing traffic much
better (that is, quicker
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 conf
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
Well... production with myself as the only client =) I want to encrypt my
webmail.
-Original Message-
:-) Don't tell me if you're gonna use it for production!!!
This message is intended for the sole use of t
:-) Don't tell me if you're gonna use it for production!!!
"Ed Lazor" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> I can always click passed the warning instead of paying $119 for the cert
> *grin*
>
> -Original Message-
> You can do this in OpenSSL
I can always click passed the warning instead of paying $119 for the cert
*grin*
-Original Message-
You can do this in OpenSSL on Linux. But the web browser will give a
warning message stating that the certificate is not issued by the
certificate authority.
You can do this in OpenSSL on Linux. But the web browser will give a
warning message stating that the certificate is not issued by the
certificate authority.
For Miguel Cruz posting back there. If I understand correctly, the private
key are inside the public key. Is this correct?
"Ed Lazor" <
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.
-Origi
Ah, miguel
good to have you back.
I missed your lovingly superior painstaking attention to detail :-)
jerome
>From: Miguel Cruz <[EMAIL PROTECTED]>
> > 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 pu
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 w
If I could elaborate on colin's explanation
Mainly so that there is a fairly recent one of these in the archives
(not that anybody searches them :-)
Like miguel said encryption in an HTTP request/response pair is determined
by your browser.
if the browser is making a request, and it sees an
I'll try to explain:
If you have a form at a http URL and the action of the form is to a
https URL, then the data from the form is submitted to the new URL in an
encrypted format.
hope that helps,
colin
Jason Caldwell wrote:
> I'm a little confused about how HTTPS actually works when you call
51 matches
Mail list logo
