RE: [PHP] HTTPS vs. HTTP ?
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 bm 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 bm 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 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
Re: [PHP] HTTPS vs. HTTP ?
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 ?
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 ?
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 ? - the weakest link
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 ? - the weakest link
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 ?
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 ?
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 ?
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 ?
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 CA 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 CA 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 ?
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 CA signed certificate for his criminal web-site. I do not trust that a CA 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 CA 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 CA and they get a shiny new Certificate. I, Richard Lynch, do *NOT* trust the CA Signers (Microsoft, et al) to correctly respond to a security problem. I know
RE: [PHP] HTTPS vs. HTTP ?
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 ?
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. CA 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 ?
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 ?
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 CA signed certificate for his criminal web-site. I do not trust that a CA 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 CA 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
Re: [PHP] HTTPS vs. HTTP ?
ðÒÉ×ÅÔ! 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 CA (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* the tech factor. That part is okay. But is a
Re: [PHP] HTTPS vs. HTTP ?
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 CA (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 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 public anyway (just like the key). The private key is the
Re: [PHP] HTTPS vs. HTTP ?
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 ?
ðÒÉ×ÅÔ!
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 ?
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 ?
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 ?
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 ?
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 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 CA 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 ?
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 ?
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 ?
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 CA 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, 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 CA 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 CA 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 CA 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 think shouldn't be there, do you check the fingerprint of the root CA first? If you do, and you trust
Re: [PHP] HTTPS vs. HTTP ?
ðÒÉ×ÅÔ!
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 CA 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 ?
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. CA SSL != security either. More secure than just encryption? I suppose... But not really enough more to inspire any real confidence in a CA 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 CA 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 CA 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 CA signed certificate in the *FIRST* place. Yes, a CA 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 CA 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 CA 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* distrust of a CA signed certificate alleged to go with a domain name. It's not
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 ?
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 CA 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 CA 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 CA people I don't know personally, and who have *PROVEN* themselves untrustworthy. I trust people, not corporations, not technology, and *CERTAINLY* not the CA 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 ?
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 it via a FORM tag or HEADER(Location: ...) This may sound like a stupid question -- but it was never explained to me, so... I have my users fill out (for example) FORM A -- this form has basic non-secure info. Then they press SUBMIT, now on FORM B, I want them to fill out their payment information. Now, I notice that when I go to web sites and fill out payment information, I see the little lock icon at the bottom of my browser, and the https://yadadada in the URL field... however, I'm unclear about something... If I call FORM B with HTTPS will my blank FORM B transmit to the user encrypted, and will I have to call HTTPS again for my PHP CC Processing App? In other words, what's taking place when I call a form or page with HTTPS? Is it that the data only gets encrypted on a SUBMIT ? Dunno if my question makes much sense .. but I guess I'd like to know if it's even required for me to call FORM B in a secure state (for the users CC data to be SENT encrypted), but instead just call the process attached to the FORM (submit button) on FORM B in HTTPS ?? Does that make sense? Jason Miguel Cruz [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... On Thu, 4 Jul 2002, Jason Caldwell wrote: Is there a way I can programmatically switch between HTTPS and HTTP... I use a lot of INCLUDE's instead of HEADER(Location: ...); Can I use HEADER in another way (without redirecting) to activate HTTPS or HTTP for any given page? Nope. The protocol is determined by the client when it makes its request. Once your code is running, it's too late. At that point you can only redirect to a https:// URL, which leads the client to generate a new request. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTTPS vs. HTTP ?
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 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. If the web server sees that this is an encrypted request, it will : 1. decrypt the request with it's private key 2. process it and generate a response (usually in the form of html) 3. encrypt the response with it's private key 4. send it back to the browser When the browser gets the response, it: 1. decrypts it with the public key 2. displays the html to the client user 3. ***shows a lock icon at the bottom of the browser 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. So, the standard practice is to have the page containing the form which takes the sensitive data ALSO be an https:// URL, so that the lock icon is already there when the client user is entering that oh-so-prized sensitive data, even though there's nothing really to protect in that HTTP request/response pair. PHP is, in a way, completely separate from the HTTP/HTTPS layer. When PHP is started up by the web server, regardless of the encryption (or lack thereof) of the original request, PHP gets the non-encrypted (or already decrypted) request. When it sends its response output to the webserver to be sent to the client, it sends that output unencrypted. It's completely up to the web server to either encrypt the response, then send it out, or to just send it with no modification. I hope that helps your understanding of what's going on with all this HTTP/HTTPS stuff. I also hope that i've been clear about it. It's kind of easy to get lost in terms. Jerome _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTTPS vs. HTTP ?
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? Around these parts the client and server use a self-contained process to handle the key exchange. The server's key has been signed by a certificate authority (Verisign, etc.) whose public key is already stored in the browser... or not, in which case the client alerts the user and generally continues nevertheless. If the web server sees that this is an encrypted request, it will : 1. decrypt the request with it's private key 2. process it and generate a response (usually in the form of html) 3. encrypt the response with it's private key 4. send it back to the browser 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. 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.). miguel -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTTPS vs. HTTP ?
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 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? Around these parts the client and server use a self-contained process to handle the key exchange. The server's key has been signed by a certificate authority (Verisign, etc.) whose public key is already stored in the browser... or not, in which case the client alerts the user and generally continues nevertheless. If the web server sees that this is an encrypted request, it will : 1. decrypt the request with it's private key 2. process it and generate a response (usually in the form of html) 3. encrypt the response with it's private key 4. send it back to the browser 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. 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.). miguel -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] HTTPS vs. HTTP ?
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. -Original Message- Around these parts the client and server use a self-contained process to handle the key exchange. The server's key has been signed by a certificate authority (Verisign, etc.) This message is intended for the sole use of the individual and entity to whom it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended addressee, nor authorized to receive for the intended addressee, you are hereby notified that you may not use, copy, disclose or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete the message. Thank you very much. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTTPS vs. HTTP ?
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 [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... 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. -Original Message- Around these parts the client and server use a self-contained process to handle the key exchange. The server's key has been signed by a certificate authority (Verisign, etc.) This message is intended for the sole use of the individual and entity to whom it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended addressee, nor authorized to receive for the intended addressee, you are hereby notified that you may not use, copy, disclose or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete the message. Thank you very much. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] HTTPS vs. HTTP ?
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. This message is intended for the sole use of the individual and entity to whom it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended addressee, nor authorized to receive for the intended addressee, you are hereby notified that you may not use, copy, disclose or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete the message. Thank you very much. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTTPS vs. HTTP ?
:-) 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 on Linux. But the web browser will give a warning message stating that the certificate is not issued by the certificate authority. This message is intended for the sole use of the individual and entity to whom it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended addressee, nor authorized to receive for the intended addressee, you are hereby notified that you may not use, copy, disclose or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete the message. Thank you very much. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] HTTPS vs. HTTP ?
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 the individual and entity to whom it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended addressee, nor authorized to receive for the intended addressee, you are hereby notified that you may not use, copy, disclose or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete the message. Thank you very much. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTTPS vs. HTTP ?
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. I saw you've already received a couple of responses, but here's a suggestion. Check out Ralph Engelschall's Web site (http://www.engelschall.com/). I seem to recall him having some good documentation on creating your own CA, issuing certificates, etc. He's the creator of a great deal of the software involved. Of course, you've been able to do this under Linux for a long time. I think Microsoft finally started offering this capability in Win2k? Also, since you are the only user, it would be worth your time to go ahead and import the root certificate of your CA into your browser and click the boxes to trust it. This will make certificates issued by you be trusted by your browser, which will save you the hassle of even having to click past the warning every session. 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 ?
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.
-Original Message-
Around these parts the client and server use a self-contained process to
handle the key exchange. The server's key has been signed by a certificate
authority (Verisign, etc.)
ðÒÉ×ÅÔ!
just install the OpenSSL server. It's part of the installation
procedures. watch here:
http://www.delouw.ch/linux/Apache-Compile-HOWTO/html/index.html
ÐÏËÁ
áÌØÂÅÒÔÏ
ëÉÅ×
--
-_=}{=_-@-_=}{=_--_=}{=_-@-_=}{=_--_=}{=_-@-_=}{=_--_=}{=_-
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 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). Besides, using an HTTPS server implies
(correct me if I am wrong) consuming an IP number, which is why site
owner pays extra money for the service, while having the address masked
withinh a form would make it possible to use addresses such as
HTTPS:www.providersite/com/namevirtualsite without loosing commercial
image. And saving quite a lot of IP numbers from being spent just for a
matter of commercial image.
We might just start putting on our sites some sort of lock button
defined by CSS. If many of do it, maybe the idea will pass thru.
ÐÏËÁ
áÌØÂÅÒÔÏ
ëÉÅ×
--
-_=}{=_-@-_=}{=_--_=}{=_-@-_=}{=_--_=}{=_-@-_=}{=_--_=}{=_-
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 ?
-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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] HTTPS vs. HTTP ?
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
Re: [PHP] HTTPS vs. HTTP ?
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 ?
ðÒÉ×ÅÔ!
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 ?
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
