Re: A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
Taral wrote: On Wed, Feb 09, 2005 at 07:41:36PM +0200, Amir Herzberg wrote: Want to protect your Mozilla/FireFox from such attacks? Install our TrustBar: http://TrustBar.Mozdev.org (this was the first time that I had a real reason to click the `I don't trust this authority` button...) Opinions? Why should I trust you? Filtering xn--* domains works for me, and doesn't require that I turn my browser over to unreviewed, possibly buggy code. Errr ... your browser _is_ unreviewed, possibly buggy code. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
On Thu, Feb 10, 2005 at 06:24:46PM -0500, Steven M. Bellovin wrote: [...] One member of this mailing list, in a private exchange, noted that he had asked his bank for their certificate's fingerprint. My response was that I was astonished he found someone who knew what he was talking about. [...] I wrote on this list, in June 2003, the last time we had this conversation (regarding a similar plugin called SSLBar): Maybe this is a stupid question, but exactly how are you supposed to use this information to verify a cert? I've done an informal survey of a few financial institutions whose sites use SSL, and the number of them that were able to provide me with a fingerprint over the phone was exactly zero. Which bank was that person you mention talking to? -- - Adam - ** My new project -- http://www.visiognomy.com/daily ** Flagship blog -- http://www.aquick.org/blog Hire me: [ http://www.adamfields.com/Adam_Fields_Resume.htm ] Links: [ http://del.icio.us/fields ] Photos: [ http://www.aquick.org/photoblog ] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
Steven M. Bellovin [EMAIL PROTECTED] writes: Is a private root key (or the equivalent signing device) an asset that can be acquired under bankruptcy proceedings? Almost certainly. Absolutely certainly. Even before Baltimore, CA's private keys had been bought and sold from/to third parties, usually as a result of bandruptcies or takeovers. You can also occasionally find lesser CA's keys left in crypto gear sold on ebay or similar surplus-disposal channels. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
Steven M. Bellovin wrote: Unusual CA? I'm not sure what a *usual* CA is. Just for fun, I opened up the CA list that came with my copy of Firefox. There are no fewer than 40 different entities listed, many of whom have more than one certificate. I personally know less than half of them to be trustworthy -- and that's assuming that, say, Thawte, Thawte Consulting, and Thawte Consulting cc are all the same company and I can count that as three different ones. I had no idea that that the U.S. Postal Service had a CA that was trusted by my browser -- and I dare say that many non-Americans wouldn't trust it at all, on the assumption that it would do whatever the U.S. government told it to do. cylink had the contract ... bea had subcontract. usps was going to do some sort of in-person verification before issuing the certificate ... along the lines of US passports. http://www.gcn.com/17_24/news/33918-1.html this dates back to the days when the CA industry was floating business cases that there was going to be $100/annum x.509 identity certificate for every person in the country (the $20b/annum gift to the CA industry story). there was some rumor that if the gov. wouldn't cough up the $20b/annum, then the financial industry was just chopping at the bit to turn over $20b/annum to certification authorities. there is a story from the period about an offer to a financial institution that if they would transmit a copy of the master account database of tens of millions of customers to the certification authority ... the certification authority would re-arrange the bits in each database entry into this magic format called a certificate and return the re-arranged magic bits to the financial institution at a mere $100/database entry (nominally overnight ... but possibly actually several days, maybe only earning the CA a measely $1b/day of work). this overlapped with the realization that identity certificates were composed at some point in the past w/o any knowledge of just what identity information any future relying parties might require as a result there was one strategy that it would be necessary to overload all identity certificate with every possibly piece of identity information so as to cover all possible requirements possibly needed by future unknown relying parties. at the same time, the financial industry was realizing that identity certificates represented huge privacy and liability exposures ... and so you started to see retrenching by various parties (particularly the financial industry) to relying-party-only certificates. misc. past posts about relying-party-only certificates: http://www.garlic.com/~lynn/subpubkey.html#rpo The problem lurking in the background is that fundamentally, the certificate design-point is an offline paradigm in a situation where the relying-party has absolutely no recourse for obtaining information about the origin of the digital signature (so is reduced to operating with a letter-of-credit paradigm from the sailing ship era). This fact was well highlighted in digitally signed payment scenario. A bank customer was issued a relying-party-only certificate by their financial institution (after registering their public key in the financial institution's account record). The customer would then create a payment authorization message, digitally sign the message and then transmit the message, the digital signature and the bank's relying-party-only certificate back to the bank. Since the bank already has the customer's public key on file, the first thing it does is discard the transmitted certificate and verifies the digital signature with the on-file public key. Another minor annoyance was that typical digital certificate was nominally two orders of magnitude (one hundred times) larger than the typical 8583 payment message. So not only were the relying-party-only certificates redundant and superfluous ... its only apparent purpose was to increase transmission payload bloat by a factor of 100 times. some past posts about browser trusted public key lists: http://www.garlic.com/~lynn/aepay4.htm#comcert14 Merchant Comfort Certificates http://www.garlic.com/~lynn/aepay4.htm#comcert16 Merchant Comfort Certificates http://www.garlic.com/~lynn/2003l.html#27 RSA vs AES - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
On Wed, Feb 09, 2005 at 09:08:45PM +, Ian G wrote: The plugin is downloadable from a MozDev site, and presumably if enough attention warrants it, Amir can go to the extent of signing it with a cert in Mozilla's code signing regime. That only authenticates that Amir wrote the code, not that the code is safe. Also, as Amir is a relatively well known name in the world of crypto I suppose you could consider his incentives to be more aligned with delivering good code than code that would do you damage. *This* is a reasonable argument, but I'd prefer a second-party review before I install anything. Then again, the only extension I have installed (FlashGot), I manually checked myself. -- Taral [EMAIL PROTECTED] This message is digitally signed. Please PGP encrypt mail to me. A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgpeCkZRPZZzq.pgp Description: PGP signature
Re: A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
Taral wrote: On Wed, Feb 09, 2005 at 07:41:36PM +0200, Amir Herzberg wrote: Want to protect your Mozilla/FireFox from such attacks? Install our TrustBar: http://TrustBar.Mozdev.org (this was the first time that I had a real reason to click the `I don't trust this authority` button...) Opinions? Why should I trust you? Filtering xn--* domains works for me, and doesn't require that I turn my browser over to unreviewed, possibly buggy code. Sorry if I was not clear: I don't propose you install TrustBar because YOU need it as a solution. Many people on this list are security/crypto experts, interested in finding good solutions (for all/many users, not just for themselves), and my message was for them. And yes, while TrustBar works fine for me and apparently quite a few others, the current code is only a research prototype (on the other hand, I had already the good fortune of seeing similar research code being adopte3d by many products... e.g. with our IP-Sec code). Best, Amir - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
Steve, my point was not the trivial fact that TrustBar would not display the homograph; suppose it did... even then, the user is _asked_ about the certificate, since it was signed by an unusual CA that the user did not specify as `to be trusted always`; this should certainly be a good warning for most users (and of course, a good situation to check for tricks such as homographs...). And even if some user allowed this CA as `always trusted`, there is still a fair chance he'll notice that the brand of CA on his bank's site has suddenly changed... which may also raise the alarm. Best, Amir Herzberg - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
Taral wrote: On Wed, Feb 09, 2005 at 09:08:45PM +, Ian G wrote: The plugin is downloadable from a MozDev site, and presumably if enough attention warrants it, Amir can go to the extent of signing it with a cert in Mozilla's code signing regime. This, of course, is up to Mozilla, not to me... We are trying to get Mozilla (and other browsers) to adopt the idea. I guess, once they do, they'll do a review and then sign, as first step towards integrating it into the browser package (you can't expect to protect all/most users, including naive, with an extension - signed or not...). That only authenticates that Amir wrote the code, not that the code is safe. Absolutely! And I didn't write the code, btw, Ahmad did. I'm just writing designs, protocols, proofs, papers... (I like programming but rarely get to it, I'm afraid). Also, as Amir is a relatively well known name in the world of crypto I suppose you could consider his incentives to be more aligned with delivering good code than code that would do you damage. thanks! *This* is a reasonable argument, but I'd prefer a second-party review before I install anything. Of course; again: by posting on this list I am exactly encouraging people to review the code (it is all script so you can just download TrustBar and read it), write their own better code, etc... Best, Amir Herzberg - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
In message [EMAIL PROTECTED], Amir Herzberg writes: Steve, my point was not the trivial fact that TrustBar would not display the homograph; suppose it did... even then, the user is _asked_ about the certificate, since it was signed by an unusual CA that the user did not specify as `to be trusted always`; this should certainly be a good warning for most users (and of course, a good situation to check for tricks such as homographs...). And even if some user allowed this CA as `always trusted`, there is still a fair chance he'll notice that the brand of CA on his bank's site has suddenly changed... which may also raise the alarm. Unusual CA? I'm not sure what a *usual* CA is. Just for fun, I opened up the CA list that came with my copy of Firefox. There are no fewer than 40 different entities listed, many of whom have more than one certificate. I personally know less than half of them to be trustworthy -- and that's assuming that, say, Thawte, Thawte Consulting, and Thawte Consulting cc are all the same company and I can count that as three different ones. I had no idea that that the U.S. Postal Service had a CA that was trusted by my browser -- and I dare say that many non-Americans wouldn't trust it at all, on the assumption that it would do whatever the U.S. government told it to do. (For such people: the relationship between the USPS and the government is complex. Let it suffice to say that they moved from .gov to .com, and they had quasi-valid reasons for doing so.) Baltimore is listed; last I heard, they were out of business. Is a private root key (or the equivalent signing device) an asset that can be acquired under bankruptcy proceedings? Almost certainly. The following text appears in the December 2004 Shareholder Circular I found at www.baltimore.com: The Company sold the last of its remaining operating businesses in 2003, and has not engaged in operating activities since that time. Since taking office in July 2004, the Company's new Board of Directors has been working to resolve all significant legacy issues, to identify a means of utilising the Company's remaining non-cash assets, toreduce costs so as to maximise the cash available for future deployment and to review appropriate business opportunities to enhance shareholder value. Paragraph 5 of Part II of this document describes, among other things, the current position relating to the utilisation of the Company's non-cash assets. Apart from the question of whether or not EvilHackerDudes.Org, a sub rosa corporation, purchased that key, the fact that this CA is out of business is certainly good cause for a bank to change its CA. Would you like to be the supervisor of customer service when people start calling about this problem their browser is complaining about? Remember that 99.99% of people have no idea what a certificate is, what a CA is, or how to judge whether or not a given CA exercises due diligence when issuing a cert. One member of this mailing list, in a private exchange, noted that he had asked his bank for their certificate's fingerprint. My response was that I was astonished he found someone who knew what he was talking about. I'm not saying your toolbar is a bad idea; in fact, I think it's a good one. But the problem of verifying certificates is a very deep one, and simple answers will not solve the phishing or MITM problem. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
Want to see a simple, working method to spoof sites, fooling Mozilla/FireFox/... , even with an SSL certificate and `lock`? http://www.shmoo.com/idn/ See also: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItemitem=3866526512 Want to protect your Mozilla/FireFox from such attacks? Install our TrustBar: http://TrustBar.Mozdev.org (this was the first time that I had a real reason to click the `I don't trust this authority` button...) Opinions? Best, Amir Herzberg - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
How can Trustbar help me if the site in question is not even SSL based. Homograph based attacks are imo a different class of its own. SK On Wed, 09 Feb 2005 19:41:36 +0200, Amir Herzberg [EMAIL PROTECTED] wrote: Want to see a simple, working method to spoof sites, fooling Mozilla/FireFox/... , even with an SSL certificate and `lock`? http://www.shmoo.com/idn/ See also: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItemitem=3866526512 Want to protect your Mozilla/FireFox from such attacks? Install our TrustBar: http://TrustBar.Mozdev.org (this was the first time that I had a real reason to click the `I don't trust this authority` button...) Opinions? Best, Amir Herzberg - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
On Wed, Feb 09, 2005 at 07:41:36PM +0200, Amir Herzberg wrote: | Want to see a simple, working method to spoof sites, fooling | Mozilla/FireFox/... , even with an SSL certificate and `lock`? | | http://www.shmoo.com/idn/ | | See also: | | http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItemitem=3866526512 | | Want to protect your Mozilla/FireFox from such attacks? Install our | TrustBar: http://TrustBar.Mozdev.org | (this was the first time that I had a real reason to click the `I don't | trust this authority` button...) | | Opinions? Just because you can demonstrate that you're pre-emptively and pro-actively blocking attacks that the beat the current system doesn't mean I can't go on. My head would explode. Have you run end-user testing to demonstrate the user-acceptability of Trustbar? Adam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
In message [EMAIL PROTECTED], Amir Herzberg writes: Want to see a simple, working method to spoof sites, fooling Mozilla/FireFox/... , even with an SSL certificate and `lock`? http://www.shmoo.com/idn/ See also: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItemitem=3866526512 Want to protect your Mozilla/FireFox from such attacks? Install our TrustBar: http://TrustBar.Mozdev.org (this was the first time that I had a real reason to click the `I don't trust this authority` button...) Actually, both Trustbar and checking the certificate are working because the code isn't right yet -- those sections of code (in Firefox) don't understand IDN yet, and they need to. Sure, they're catching a problem here, but they're catching the problem for those network users who are expecting and reading ASCII characters. But think of, say, the Japanese user who would like to see that the certificate really was issued to some string of Kanji, and instead sees the IDN encoding? That's less than helpful -- he or she would have no way whatsoever of verifying the certificate. --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
Adam Shostack wrote: Have you run end-user testing to demonstrate the user-acceptability of Trustbar? Yes, this was asked over on the cap-talk list. Below is what I posted there. I'm somewhat sympathetic as doing a real field trial which involves testing real responses to a browser attack raises all sorts of heisenberg uncertainty / experimental method issues. Off the top of my head, I think this is a really tricky problem, and if anyone knows how to test security breaches on ordinary users, shout! Ka-Ping Yee wrote: 1. TrustBar: Protecting (even Naive) Web Users from Spoofing and Phishing Attacks, Amir Herzberg and Ahmad Gbara http://www.cs.biu.ac.il/~herzbea//Papers/ecommerce/spoofing.htm I've read that paper. What they did is not a user study at all; it was merely a questionnaire. It's certainly better than nothing, but it is not a user study. For the results to be applicable, the tests should take place while users are actually interacting with a browser normally. I agree it wasn't much. But it was a bit more than just a multiple choice: The second goal of the third question was to evaluate whether the use of TrustBar is likely to improve the ability of users to discern between unprotected sites, protected sites and spoofed (fake) sites. For this purpose, we gave users a very brief explanation on the TrustBar security indicators, and then presented three additional screen shots, this time using a browser equipped with TrustBar. Again, the screen shots are presented in Appendix B, and each was presented for 10 to 15 seconds, taken using Mozilla in the Amazon web site. We leave it as a simple exercise to the reader to identify the protected, unprotected and spoofed (fake) among these three screen shots. The results provide positive indication supporting out belief that the use of TrustBar improves the ability of (naïve) web users to discern between protected, unprotected and fake sites. Specifically, the number of user that correctly identified each of the three sites essentially doubled (to 21, 22 and 29). That would rate as a simulation rather than a field trial, I guess. -- iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
Taral wrote: On Wed, Feb 09, 2005 at 07:41:36PM +0200, Amir Herzberg wrote: Why should I trust you? Filtering xn--* domains works for me, and doesn't require that I turn my browser over to unreviewed, possibly buggy code. I understand this is a theoretical question, but here is an answer: The plugin is downloadable from a MozDev site, and presumably if enough attention warrants it, Amir can go to the extent of signing it with a cert in Mozilla's code signing regime. Also, as Amir is a relatively well known name in the world of crypto I suppose you could consider his incentives to be more aligned with delivering good code than code that would do you damage. iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
On Wed, Feb 09, 2005 at 07:22:05PM +, Ian G wrote: | Adam Shostack wrote: | | Have you run end-user testing to demonstrate the user-acceptability of | Trustbar? | | | | Yes, this was asked over on the cap-talk list. | Below is what I posted there. I'm somewhat | sympathetic as doing a real field trial which | involves testing real responses to a browser | attack raises all sorts of heisenberg uncertainty / | experimental method issues. Off the top of | my head, I think this is a really tricky problem, | and if anyone knows how to test security | breaches on ordinary users, shout! There's an HCIsec group at YahooGroups: http://groups.yahoo.com/group/hcisec/ Most of the smart people who care about these issues hang out there. Adam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
