Re: The real problem that https has conspicuously failed to fix
-- On 11 Jun 2003 at 16:11, Jeffrey I. Schiller wrote: > Oh, and btw, the form posting URL in my message wasn't even > https, it was just http. So all the futzing in the world with > https wouldn't help! If https provided an adequate substitute for shared secrets, it would help. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG B9cEiIa9s5fvgr0BsmE3D3+BgvAXXvyF1/xSIi0k 4m1RrAexqkSii4X39kqfzefd2laQEwFD0bhYHaELv - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The real problem that https has conspicuously failed to fix
Yep, I deployed such a PKI here at MIT back in 1996. Today every student and most faculty and staff have certificates. It really does work, but unfortunately the support for them in the common browsers is quirky enough that we have our support fun! I can understand why commercial sites shy away. I have also been involved in efforts to get U.S. Higher Education to start deploying client certificates. The big problem there is that public key encryption appears to require more then the amount of clue that most computer administrators seem to have, so education is a real problem. -Jeff Nomen Nescio wrote: Jeffrey I. Schiller writes: Oh, and btw, the form posting URL in my message wasn't even https, it was just http. So all the futzing in the world with https wouldn't help! Of course it would help. Have you been following this discussion at all? The idea is to eliminate passwords as being of any value in getting access to PayPal or other ecommerce sites, by replacing them with client certificates. This implies using https or something cryptographically similar. pgp0.pgp Description: PGP signature
Re: The real problem that https has conspicuously failed to fix
At 08:20 PM 6/11/2003 -0700, James A. Donald wrote: I think you have put your finger right on the problem. Certificates, https, and the entire PKI structure were designed for an accountless world, but the problem is accounts. or slightly more accurately doing authentication for accounts. the other is frequently confusing identification with authentication. the internet registries (both domain and ip-address) haven't been doing authentication ... but just some simple identification. there are situations where identification may quite orthogonal to whether or not you are the owner of the account in question. also, identification also tends to open up the whole can of worms around protecting privacy. as periodically stated (in reference to x9.59) thick blanket of encryption protecting privacy information is good, the information not being there at all is even better. -- Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The real problem that https has conspicuously failed to fix
Jeffrey I. Schiller writes: > Oh, and btw, the form posting URL in my message wasn't even https, it > was just http. So all the futzing in the world with https wouldn't help! Of course it would help. Have you been following this discussion at all? The idea is to eliminate passwords as being of any value in getting access to PayPal or other ecommerce sites, by replacing them with client certificates. This implies using https or something cryptographically similar. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The real problem that https has conspicuously failed to fix
-- On 10 Jun 2003 at 23:26, Anonymous wrote: > In short, if Palladium comes with the ability to download > site-specific DLLs that can act as NCAs, it should allow for > solving the spoofed-site problem once and for all. When you > login to paypal or e-gold, you would authenticate yourself > using a cert that only those sites could see. This can be > done in the framework of standard SSL, but would require a > Palladium-aware browser. Well, this would work just great provided the browser was made palladium aware in such a way as to be useful to the user, rather than to verisign. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG VBdyipPLv5JzjJ0eIFxxeMDsO30Us9Mvs7lmm2ka 4R5+YjVhKptjgGIVZsjTfX5nDogjTf2G8x7fRhKmN - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The real problem that https has conspicuously failed to fix
-- On 10 Jun 2003 at 21:33, Anne & Lynn Wheeler wrote: > certificates were originated to address a specific issue with > key distribution and trust involving parties that 1) had no > prior business relation, 2) were unlikely to have any future > business relationship, and 3) didn't have online access to > trusted 3rd party. however, it is actually much more natural > in a standard business process setting that public key is > registered in lieu of shared-secret authentication material > when parties are involved that have established business > relationship (aka for example a person with some sort of an > account, especially in any sort of online paradigm). A > trivial examples is certificateless operation with > public/private keys for radius, kerbers pk-init or x9.59 > standard for all retail payment transactions (internet, > non-internet, point-of-sale, debit, credit, ach, > stored-value, etc). I think you have put your finger right on the problem. Certificates, https, and the entire PKI structure were designed for an accountless world, but the problem is accounts. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG DxVY4Z01oFU7xvn07JDMoJBGMxVLt61s4VcQTMLB 4v46MbB1PtOjOaOcNvexHiyB1LzfD0RJ+CIPtD7RD - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The real problem that https has conspicuously failed to fix
Oh, and btw, the form posting URL in my message wasn't even https, it was just http. So all the futzing in the world with https wouldn't help! -Jeff Pete Chown wrote: John R. Levine wrote: Crypto lets someone say "Hi! I absolutely definitely have a name somewhat like the name of a large familiar organization, and I'd like to steal your data!" ... It might help if browsers displayed some details of the certificate without being asked. For example, instead of a padlock, the browser could have an SSL toolbar. This would show the verified name and address of the site you are connected to. The bar could also show the server name for unverified connections. This would avoid the attacks that use URLs like http://www.microsoft.com:[EMAIL PROTECTED] . pgp0.pgp Description: PGP signature
Re: The real problem that https has conspicuously failed to fix
Folks, this isn't an https (or even http) problem. It is a tough user interface issue. Note: The form posting goes to www.pos2life.biz, which doesn't remotely look like paypal.com! To make matters worse, there are plenty of businesses that send you leg imitate email that comes from a "random" looking place. Just today I received one from MIT's Alumni Association, but the actual source was something like m0.email-foobar.com (or something). Obviously the Alumni Association outsources the sending of the mail to some third party company. So even if we came up with some fancy was of saying "This form doesn't post to the same place this page came from [never mind that the original of an e-mail form is ill defined]" won't help. I also received this scam mail. There were only two hints of badness (besides the obvious request for personal info that paypal shouldn't need) one was the form posting and the other was the "Received-by" line which my mail system put on the message which showed its original at a suspicious place (I believe in Japan, but I may have remembered wrong, it didn't look right at the time). This is a social problem. Technical measures can help, but won't solve it, I am afraid. -Jeff Roy M.Silvernail wrote: On Sunday 08 June 2003 06:11 pm, martin f krafft wrote: also sprach James A. Donald <[EMAIL PROTECTED]> [2003.06.08.2243 +0200]: (When you hit the submit button, guess what happens) How many people actually read dialog boxes before hitting Yes or OK? It's slightly more subtle. The action tag of a form submission isn't usually visible to the user like links are. In the scam copy I received, all the links save one pointed to legitimate PayPal documents. Only the - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: The real problem that https has conspicuously failed to fix
Anonymous wrote: The solution to this [key theft by malware] is Palladium (NGSCB). You could achieve the same protection on any system with decent mandatory access controls. SELinux would be fine, for example. You could have a program like ssh-agent which performs the public key operations; you then deny everything else access to the key store. -- Pete - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The real problem that https has conspicuously failed to fix
Pete Chown wrote [ at 10:14 AM 6/10/2003 +0100 ]: The bar could also show the server name for unverified connections. This would avoid the attacks that use URLs like http://www.microsoft.com:[EMAIL PROTECTED] . Opera 7.x, by default, warns you whenever you are attempting to connect to a URL containing a username, like above. Udhay -- ((Udhay Shankar N)) ((udhay @ pobox.com)) ((www.digeratus.com)) - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The real problem that https has conspicuously failed to fix
At 11:26 PM 6/10/2003 +0200, Anonymous wrote: The problem to be solved is this. Spoofed sites can acquire user credentials, especially passwords, and then use those to impersonate the user on the real sites. With paypal and e-gold, this allows stealing real money. Using client certificates to authenticate would solve this, because even if the user got fooled and authenticated to the spoofed site, the attacker wouldn't learn the client cert secret key and so would not be able to masquerade as the user. The problem (among others) is that this allows a virus to steal the client cert. If it is protected by a password, the malware must hang around long enough for the user to unlock the cert (perhaps because the malware sent a spoofed email calling for the user to visit the site, even the real site!). It can then read the user's keystrokes and acquire the password. Now it has the cert and password and can impersonate the user at will. slight nit the solution is non-shared secret in conjunction with something you have authentication implementing, digital signatures, public/private keys where the private key is never divulged even to the owner (the private key housing can be hardware token ... or something embedded in the computer). it seems that certificates sometimes are considered synonymous with public/private key and digital signatures. however, certificates were originated to address a specific issue with key distribution and trust involving parties that 1) had no prior business relation, 2) were unlikely to have any future business relationship, and 3) didn't have online access to trusted 3rd party. however, it is actually much more natural in a standard business process setting that public key is registered in lieu of shared-secret authentication material when parties are involved that have established business relationship (aka for example a person with some sort of an account, especially in any sort of online paradigm). A trivial examples is certificateless operation with public/private keys for radius, kerbers pk-init or x9.59 standard for all retail payment transactions (internet, non-internet, point-of-sale, debit, credit, ach, stored-value, etc). Also note, a certificate tends to only contain the owners public key and some other information about the owner (and nominally is assumed to be freely distributable, somewhat in the same way the PGP keyserver information is published). The certificate doesn't contain the private key ... which tends to be either in a software encrypted file or an external hardware token. for the various possible types of social engineering & virus exploits, eliminating shared secrets is only a partial solution (although shared secrets have a number of vulnerabilities and exploits, so eliminating shared secrets is not a bad thing)., if the individual has direct access to the private key in anyway, then it is possible to compromise that access. That is where some flavor of "something you have" authentication comes in with hardware that houses the private key and there is no way to divulge the private key, even to the owner. EU finread (financial reader) has an external reader with its own display and pin-pad. This addresses the issue (even with something you have hardware token) where a viirus can 1) display one value on the screen and send another value to the token for signing and 2) spoof keystroke entry with the correct PIN (perform fraudulent transactions w/o the owners knowledge). If the 1) private key can never be directly physically accessed, 2) the digital signature is taken to represent a form of something you have authentication. 3) the display can be trusted to always display what will be signed 4) the keypad can't be spoofed and actually requires the person to hit the keys 5) hardware token never signs anything unless there has been (human) keypad entry then the remaining types of fraud will tend to be no different than the phone scams, mail scams and the people coming to your door scams effectively no different than the types of fraud that has been going on for hundreds/thousands of years. -- Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The real problem that https has conspicuously failed to fix
The problem to be solved is this. Spoofed sites can acquire user credentials, especially passwords, and then use those to impersonate the user on the real sites. With paypal and e-gold, this allows stealing real money. Using client certificates to authenticate would solve this, because even if the user got fooled and authenticated to the spoofed site, the attacker wouldn't learn the client cert secret key and so would not be able to masquerade as the user. The problem (among others) is that this allows a virus to steal the client cert. If it is protected by a password, the malware must hang around long enough for the user to unlock the cert (perhaps because the malware sent a spoofed email calling for the user to visit the site, even the real site!). It can then read the user's keystrokes and acquire the password. Now it has the cert and password and can impersonate the user at will. The solution to this is Palladium (NGSCB). You'd want each ecommerce site to download a Nexus Computing Agent into the client. This should be no more difficult than downloading an Active-X control or some other DLL. The NCA has a manifest file associated with it that contains the ecommerce site's signing key. This allows the NCA to be effectively locked to that key. The user's site-specific client certificate would be sealed to this NCA. That means that no other NCA could get access to the client cert for that site, nor could any legacy software. All this is protected by the Palladium hardware and software. If a password is used for further security, to unlock the client cert (in addition to the NCA-specific encryption), it can use a secure channel to the NCA so that no keystroke loggers can steal the password. (However, as mentioned in a previous mail, this may not stop rogue NCA's from fooling the user by pretending to be the ecommerce site's NCA and picking up the password. It's not clear that adding a password really increases security. Fortunately the NCA security itself is already vastly stronger than anything available on a PC today.) In short, if Palladium comes with the ability to download site-specific DLLs that can act as NCAs, it should allow for solving the spoofed-site problem once and for all. When you login to paypal or e-gold, you would authenticate yourself using a cert that only those sites could see. This can be done in the framework of standard SSL, but would require a Palladium-aware browser. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The real problem that https has conspicuously failed to fix
-- James A. Donald: > > I keep posting "you cannot do this using https", and people > > keep replying "yes you can" On 10 Jun 2003 at 1:52, John R. Levine wrote: > I think there's two separate problems here. One is domain > squatting. I've seen lots of phishes from domains like > paypal-confirm.com (which is registered to someone in > Pakistan.) It is truly pitiful that with all of the > anti-squatting nonsense involved with ICANN and their UDRP, > and despite the cases cases we've read about with trademark > owners suing everyone who registers "bigcorp-sucks.com", > people still register deliberately confusing domain names in > bad faith for fraudulent purposes and get away with it. The example I posted did not rely on a misleading name, though most such scams do, and a misleading name greatly facilitates such scams. > The other issue, as someone else noted, is that html, like > just about everything else on the net, wasn't designed to be > secure and unless you're going to go reading the source code > of every form you use, you can't tell where your information > is going. If https made it possible to log on to a site without sending the site a shared secret, that would help, because then end users would be surprised and suspicious on being asked to send a shared secret. And when I say "possible" I do not mean "possible if you send a hundred dollars per customer to verisign and your administrator spends an hour talking face to face with each customer and fiddling with each customer's computer", > I can't see that either of those issues can be addressed by > cryptography The problem is shared secrets. Abolish shared secrets, nothing for the scam sites to steal. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG rx/Z2qIPQ5/w2m19Glalp9TuC97A9A0sAFlrm0JN 4o44QKfLOBAAqjFsl04PeQ/0B05CLW3gCaS/b7lWq - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The real problem that https has conspicuously failed to fix
Pete Chown wrote: > It might help if browsers displayed some details of the certificate > without being asked. For example, instead of a padlock, the browser > could have an SSL toolbar. This would show the verified name and > address of the site you are connected to. or just show the verified name in the status bar *BUT* use a specific font that makes vaguely similar characters wildly different - use an ornate script font for numbers, with a sans font for letters, and symbols in a "grey" halftone bold. as long as 1 can't look like i or l and 0 is wildly different from O, a lot of "fake" sites will stand out beautifully - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The real problem that https has conspicuously failed to fix
hi ( 03.06.10 01:52 - ) John R. Levine: > Crypto lets someone say "Hi! I absolutely definitely have a name > somewhat like the name of a large familiar organization, and I'd like > to steal your data!" and lots of users will say "OK, fine, whatever." i think this is more a problem with people than technology [crypto]. similarly, another aspect of the problem is the widespread unfamiliarity with digital credentials. again, this part could be 'solved' by teaching people instead of creating more technology. nothing is foolproof. we live in a dangerous world. -- \js - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The real problem that https has conspicuously failed to fix
John R. Levine wrote: Crypto lets someone say "Hi! I absolutely definitely have a name somewhat like the name of a large familiar organization, and I'd like to steal your data!" ... It might help if browsers displayed some details of the certificate without being asked. For example, instead of a padlock, the browser could have an SSL toolbar. This would show the verified name and address of the site you are connected to. The bar could also show the server name for unverified connections. This would avoid the attacks that use URLs like http://www.microsoft.com:[EMAIL PROTECTED] . -- Pete - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The real problem that https has conspicuously failed to fix
> I keep posting "you cannot do this using https", and people keep > replying "yes you can" I think there's two separate problems here. One is domain squatting. I've seen lots of phishes from domains like paypal-confirm.com (which is registered to someone in Pakistan.) It is truly pitiful that with all of the anti-squatting nonsense involved with ICANN and their UDRP, and despite the cases cases we've read about with trademark owners suing everyone who registers "bigcorp-sucks.com", people still register deliberately confusing domain names in bad faith for fraudulent purposes and get away with it. The other issue, as someone else noted, is that html, like just about everything else on the net, wasn't designed to be secure and unless you're going to go reading the source code of every form you use, you can't tell where your information is going. I can't see that either of those issues can be addressed by cryptography. Crypto lets someone say "Hi! I absolutely definitely have a name somewhat like the name of a large familiar organization, and I'd like to steal your data!" and lots of users will say "OK, fine, whatever." -- John R. Levine, IECC, POB 727, Trumansburg NY 14886 +1 607 330 5711 [EMAIL PROTECTED], Village Trustee and Sewer Commissioner, http://iecc.com/johnl, Member, Provisional board, Coalition Against Unsolicited Commercial E-mail - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The real problem that https has conspicuously failed to fix
Re: Martin's comments > even so, whether you do or not, taken in account that do you have your > fingerprints memorized... > > http://www.thc.org/thc-ffp/ > > > - Original Message - > From: "martin f krafft" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Sunday, June 08, 2003 3:11 PM > Subject: Re: The real problem that https has conspicuously failed to fix > - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The real problem that https has conspicuously failed to fix
On Sunday 08 June 2003 06:11 pm, martin f krafft wrote: > also sprach James A. Donald <[EMAIL PROTECTED]> [2003.06.08.2243 +0200]: > > (When you hit the submit button, guess what happens) > > How many people actually read dialog boxes before hitting Yes or OK? It's slightly more subtle. The action tag of a form submission isn't usually visible to the user like links are. In the scam copy I received, all the links save one pointed to legitimate PayPal documents. Only the
Re: The real problem that https has conspicuously failed to fix
also sprach James A. Donald <[EMAIL PROTECTED]> [2003.06.08.2243 +0200]: > (When you hit the submit button, guess what happens) How many people actually read dialog boxes before hitting Yes or OK? I know you do, and most of us, but who's the majority? -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED] keyserver problems? http://keyserver.kjsl.com/~jharris/keyserver.html get my key here: http://madduck.net/me/gpg/publickey "my experience is that as soon as people are old enough to know better, they don't know anything at all." -- oscar wilde pgp0.pgp Description: PGP signature
The real problem that https has conspicuously failed to fix
I keep posting "you cannot do this using https", and people keep replying "yes you can" No you cannot, cause if you could, paypal, e-gold, e-bay, and the rest would not be suffering from the problem illustrated by scam mails such as the following (When you hit the submit button, guess what happens) Dear PayPal Customer This e-mail is the notification of recent innovations taken by PayPal to detect inactive customers and non-functioning mailboxes. The inactive customers are subject to restriction and removal in the next 3 months. Please confirm your email address and Credit or Check Card information using the form below: Email Address: Password: First Name: Last Name: ZIP: Credit or Check Card #: Expiration Date: Month 01 02 03 04 05 06 07 08 09 10 11 12 / Year 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 ATM PIN: Information transmitted using 128bit SSL encryption. Thanks for using PayPal! This PayPal notification was sent to this email address because you are a Web Accept user and chose to receive the PayPal Periodical newsletter and Product Updates. To modify your notification preferences, go to https://www.paypal.com/PREFS-NOTI and log in to your account. Changes may take several days to be reflected in our mailings. Replies to this email will not be processed. Copyright© 2003 PayPal Inc. All rights reserved. Designated trademarks and brands are the property of their respective owners.
