Re: phishing web sites using self-signed certs
Peter Gutmann wrote: cdr <[EMAIL PROTECTED]> writes: If this was to be done, it would quickly become the best known example of simple-minded, ill suited for real world "I-know-best" attitude on the part of programmer. We know users have choice, and the net result, I predict, would be their migration to other browsers. So the ideal browser for users would be one that ignores security issues entirely and just connects without any notification to save them having to bother to click "OK" on the "Connect anyway" dialog? Peter. No, I readily agree it wouldn't. As I suggested elsewhere in this thread, I believe the ideal browser would support two complementary protocols, one based on TTP, the other on KCM, with the user being aware which one is s/he operating under. cdr p.s.: isn't this what your above-mentioned [RFC_duckling.txt] points towards? (Now that you referenced it in a public mail-list, I fully intend to use it as the evidence that even P.G. thinks this is how the browsers should operate. :) ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: phishing web sites using self-signed certs
Wan-Teh Chang <[EMAIL PROTECTED]> writes: >Here is a recent paper related to Key Continuity: >http://www.simson.net/ref/2005/johnny2_usenixsecurity05_submited.pdf There's also my I-really-should-finish-this BCP draft, available at http://www.cs.auckland.ac.nz/~pgut001/pubs/RFC_duckling.txt. Comments on that are welcome... maybe then I'll get around to finishing it :-). Peter. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: phishing web sites using self-signed certs
cdr <[EMAIL PROTECTED]> writes: >Peter Gutmann wrote: >> Treat it as an unrecoverable error... >> ...in the same format as [...] a "Server not found"-type message. >If only it was so simple... >If this was to be done, it would quickly become the best known >example of simple-minded, ill suited for real world "I-know-best" >attitude on the part of programmer. We know users have choice, >and the net result, I predict, would be their migration to other >browsers. So the ideal browser for users would be one that ignores security issues entirely and just connects without any notification to save them having to bother to click "OK" on the "Connect anyway" dialog? Peter. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: phishing web sites using self-signed certs
Anne & Lynn Wheeler <[EMAIL PROTECTED]> writes: > some number of the PKI afficionados were claiming that credit card > transactions could be modernized by upgrading the transactions with > PKI (adding a digital certificate to every credit card transaction). the other thing going on in this period ... in addition to the flailing around attempting to do something about all our harping about payment card industry had proven something like 30 yrs earlier that CRLs didn't scale (although most of the effort seemed misdirected in attempting to still preserve the PKI offline credential paradigm w/o having to really move into real modern online transactions) was the EU data privacy directive standard (EU-DPD). i was one of the co-authors of the more recent x9 financial industry privacy standard and took into account some amount of the EU-DPD. some minor reference can be seen here with respect to the privacy merged taxonomy and glossary (in support of the x9.99 work) http://www.garlic.com/~lynn/index.html#glosnote in any case, there were various statements that electronic retail payments needed to be anonomous as cash. one practical implication was that names would have to come off the payment cards and identification procedures be eliminated from point-of-sale operation (hopefully substituting stronger forms of authentication). applying that to e-commerce implied that you had to avoid getting bollixed up with x.509 identity certificates and continually digging yourself into the hole of confusing authentication and identification. this frequent confusing of authentication and identification was constantly compromising the ability to achieve any reasonable privacy objectives. a few past posts on eu-dpd and retail payments w/o identification http://www.garlic.com/~lynn/aadsm12.htm#27 Employee Certificates - Security Issues http://www.garlic.com/~lynn/aadsm17.htm#21 Identity (was PKI International Consortium) http://www.garlic.com/~lynn/2000g.html#33 does CA need the proof of acceptance of key binding ? -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: phishing web sites using self-signed certs
there are periodic comments that OCSP fixes the offline characteristics of digital certificate credentials. some recent postings related to the subject: http://www.garlic.com/~lynn/2005i.html#0 More Phishing scams, still no SSL being used http://www.garlic.com/~lynn/2005l.html#1 The Worth of Verisign's Brand http://www.garlic.com/~lynn/2005l.html#31 More Phishing scams, still no SSL being used http://www.garlic.com/~lynn/2005l.html#32 More Phishing scams, still no SSL being used basically around the time we were involved with this small client/server startup that wanted to do payments and had this technology called SSL ... http://www.garlic.com/~lynn/subpubkey.html#sslcert some number of the PKI afficionados were claiming that credit card transactions could be modernized by upgrading the transactions with PKI (adding a digital certificate to every credit card transaction). our somewhat off-hand response was that would involved setting the credit card transactions back 20-30 years. in the 60s, credit card transactions had offline credentials and revokation lists ... monthly booklets that were sent out to every merchant once a month. as credit cards became more widely adapted ... the booklets got larger (since the number of cards in play was dramatically increasing), the number sent out dramatically increased (since the number of merchants were increasing), and they were being sent out more frequently (since the absolute number of invalid cards was reaching a risk threshold faster ... even if the percentage remained constant). the approach was on its way to having to distribute tens of millions of booklets with hundreds of thousands of entries, every couple hrs. the introduction of online, electronic in the 70s allowed that untenable paradigm to be eliminated. in theory, the online, electronic approach could have taken the OCSP approach, preserving the offline credential paradigm and simply upgrading the revokation business process with a indication of whether the offline credential was still valid or not. however, they actually transitioned to a real online, electronic paradigm ... but changing the paradigm from offline credential to an online transaction that actually told the merchant whether they would get paid or not. so everytime somebody would make the claim that PKI would make credit card transactions more modern, we would started the refrain that PKI would represent a 20-30 year regression in the business process. when OCSP was introduced (could somewhat be considered as the result of our heckling the revokation list process), we also heckled OCSP as going to all the trouble of doing an online transactions ... but didn't actually leverage the possible business process benefits of doing online transactions ... but continued to preserve the offline credential paradigm of PKI. part of the issue was confusing the digital signature technology with the PKI business process. While digital signature technology for transaction authentication would represent a modernization effort, reverting to an offline credential paradigm represented by the offline PKI model would be a 20-30 year regression in the business model and doing real online transactions. This was also during the period that you found PKI aficionados making statements about modernization driver's licenses with the PKI model. However, in this period ... most infrastructure operations that made serious reference to a driver's license was also migrating to real online transactions; aka going to all the trouble of having a real online transaction wasn't going to be crippled by following the OCSP model and just checking to see simply whether the credential was still valid or not ... if you are going to the trouble of doing a real online transaction ... lets make it worth the trouble and respond with all facts that might be of interest related to the official doing their business. While driver's licenses can still work as an offline credential ... they are more & more being used as part of a real online transactions ... as opposed to trivially checking as to whether the offline credential is still valid or not. the other story from the period of possibly some interest with regard to modernizing online, real-time credit card by appending stale, static digital certificates ... was that even relying-party-only digital certificates from the period http://www.garlic.com/~lynn/subpubkey.html#rpo could represent a 4k-12k byte payload burden. the nominal iso8583 payment transaction is on the order of 60-80 bytes. the appending of a redudant and superfluous, stale, static digital certificate to a payment transaction represents an enormous payload bloat on the order of two orders of magnitude ... serving no useful purpose. now in the x9 financial standards body, the x9a10 working group was given the task of preserving the integrity of the financial infrastructure for all retail payments. the result was x9.59 standard http://www.garlic.com/~lynn/i
Re: phishing web sites using self-signed certs
Arshad Noor wrote: > It is my belief that what is needed is a new trust model, where > only the digital certificates of CA's of a federal entity of a > nation [snip] > The Federal CA in turn, will issue the CA certificates of the > states that are part of that federal entity (the 50 US states, > for example), who in turn will issue the CA certificate for the > office of the Secretary of State in each state. For smaller > nations, the Federal CA might issue the certificate to the > agency that incorporates/licenses business entities, directly. That's not a new trust model at all. It's the original model of X.500 and X.509. In that model, there is one global hierarchy of Directory Servers, with each country having one Directory, with subordinate directories (servers) for states, which in turn have subordinate directories for localities, etc. For each of these directories, there would be one cert issuer who was authorized to issue certs for that directory's scope, and hence was the certificate authority for that subspace of the directory name space. Certificate authorities and their subordinate registration authorities would also be organized as a hierarchy which more-or-less matched the directory hierarchy. Certificates would be accessible from the related directory servers. That's why cert subject and issuer names are directory names. The scheme is a single global hierarchy. For each region served, there is one authoritative service, which is a monopoly for that region. The standards body that produced X.50x was the body that sets the international telephony standards, and they imagined that this service would be run by each country's postal or telephone service agency. Given the ubiquity of postal and telephony services, I think that hierarchical model might have worked well, better than the existing alternative ad-hoc set of authorities has worked. In its absence, we are beset with a mostly non-authoritative set of cert issuers; a few cert issuers that make a sincere effort to verify what they certify, an increasing number of issuers whose certification doesn't mean much, and with a plethora of self-issued certs. -- Nelson B ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: phishing web sites using self-signed certs
Ka-Ping Yee wrote: On Thu, 3 Nov 2005, Julien Pierre wrote: Ka-Ping Yee wrote: On Wed, 2 Nov 2005, Julien Pierre wrote: The account (or other relationship) you previously established at the website you wanted -- the "one truly intended" as you put it. The phisher wants to fool you into believing you are participating in that relationship when in reality you are dealing with an impostor. By keeping note of the certificate information, your browser can tell you reliably whether you are dealing with the same site and not an impostor. No. A party is allowed to use more than one certificate, for reasons such as renewal, or many other. There is nothing in X.509 or SSL that says one party only has one cert, quite the contrary. The fact that the certificate has changed since your last communication does not tell you that you aren't dealing still with the same site . But that is not under control of the phisher. Only the legitimate party can produce the correct certificate, and that is what matters. When you are phished, someone is trying to make you believe that you are at the SAME site when in reality you are at a DIFFERENT site. The situation you're describing is not phishing; it's backwards (you think you are at a different site when you are at the same site), and it can only occur with consent of the legitimate site. The point I was trying to make is that there is not one unique correct certificate. The fact that the certificate changed or didn't change tells you nothing about its validity. In fact the certificate could be the same both times, but it could have been revoked by the CA between the two communications, eg. for reason of key compromise, and you could in fact be dealing with a phisher the second time . The fact is that the information about which certificate was used in a previous communication is not relevant to the problem of authenticating the site the 2nd time around. To provide security, the certificate needs to be fully verified and validated again. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: phishing web sites using self-signed certs
On Thu, 3 Nov 2005, Julien Pierre wrote: > Ka-Ping Yee wrote: > > On Wed, 2 Nov 2005, Julien Pierre wrote: > > > The account (or other relationship) you previously established at the > > website you wanted -- the "one truly intended" as you put it. The > > phisher wants to fool you into believing you are participating in that > > relationship when in reality you are dealing with an impostor. By > > keeping note of the certificate information, your browser can tell you > > reliably whether you are dealing with the same site and not an impostor. > > No. A party is allowed to use more than one certificate, for reasons > such as renewal, or many other. There is nothing in X.509 or SSL that > says one party only has one cert, quite the contrary. The fact that > the certificate has changed since your last communication does not > tell you that you aren't dealing still with the same site . But that is not under control of the phisher. Only the legitimate party can produce the correct certificate, and that is what matters. When you are phished, someone is trying to make you believe that you are at the SAME site when in reality you are at a DIFFERENT site. The situation you're describing is not phishing; it's backwards (you think you are at a different site when you are at the same site), and it can only occur with consent of the legitimate site. -- ?!ng ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: phishing web sites using self-signed certs
Julien Pierre wrote: Ka-Ping Yee wrote: On Wed, 2 Nov 2005, Julien Pierre wrote: The account (or other relationship) you previously established at the website you wanted -- the "one truly intended" as you put it. The phisher wants to fool you into believing you are participating in that relationship when in reality you are dealing with an impostor. By keeping note of the certificate information, your browser can tell you reliably whether you are dealing with the same site and not an impostor. No. A party is allowed to use more than one certificate, for reasons such as renewal, or many other. There is nothing in X.509 or SSL that says one party only has one cert, quite the contrary. The fact that the certificate has changed since your last communication does not tell you that you aren't dealing still with the same site . Authentication by Key Continuity is not textbook PKI. It is based on the observation that it is very hard for an impostor to deceive you multiple times, so the more successful interactions you have had with the *same* entity, the more trust you have in it. (I don't remember how Key Continuity deals with an eavesdropping man in the middle.) With Key Continuity, you don't need to get the trust from a CA; the certificates can be self signed. You build up the trust in a certificate as you have more and more successful interactions with that *same* entity. Here is a recent paper related to Key Continuity: http://www.simson.net/ref/2005/johnny2_usenixsecurity05_submited.pdf Wan-Teh ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: phishing web sites using self-signed certs
Arshad Noor wrote: > While third-party verification is not the real issue, the issue > is: can the third-party itself be trusted? Who remembers the > Verisign debacle from a few years ago with the Class-3 digital > certificates issued through a social engineering attack, in the > name of Microsoft? > > http://news.com.com/2100-1001-254586.html?legacy=cnet > http://www.eweek.com/article2/0,1895,1243314,00.asp there is actually several separate issues, some of which are * who is doing certification * what process are they using for certification * are they willing to accept liability associated with their certification * how is the certification represented using a taxonomy that clearly delineates the difference between certification of information from using digital certificates for representing that certification process ... somewhat shows up some of the fallicy of self-signed digital certificates part of this is sometimes people seem to be confusing the existance of a digital certificate as having some magical certification quality all by itself ... rather than as a representation of some certification process. PKIs and digital certificates are a business process to address the letters of credit paradigm from the sailing ship days for offline certification representation ... i.e. the relying party has no mechanism for doing real-time and/or online checking the validity of the information. furthremore, current generation of certification authorities have tended to be independent 3rd parties who are checking with various authoritative agencies as to the validitity of some information and then issuing certificates that represent that such a checking process has been done. they typically haven't been the authoritative agency actually responsible for the verified information. as the online world with the internet becoming more pervasive ... some of the authoritative agencies actually responsible for various kinds of information being verified have looked at providing online, real-time verification services associated with the information in question (as opposed to the stale, static certificate model that was designed to meet the needs of relying parties that had no direct way of actually contacting the authoritative agency for directly verifying the information). to some extent, as the online, internet world has become more pervasive ... the target offline market for digital certificates has shrunk and there has been some migration to the no-value market segment. rather than the relying party being unable to directly contact the authoritative agency responsible for the information, the no-value market has the relying party doing operations where there is insufficient value justification for directly contacting the authoritative agency (aka no-value operations). even this market segment is shrinking as the internet is not only providing pervasive world-wide online connectivity but also drastically reducing the cost of that online connectivity world-wide. a couple related posts on the subject: http://www.garlic.com/~lynn/2005s.html#43 P2P Authentication http://www.garlic.com/~lynn/aadsm21.htm#20 Some thoughts on high-assurance certificates http://www.garlic.com/~lynn/aadsm21.htm#21 Some thoughts on high-assurance certificates misc. collected past posts on ssl domain name server certificates http://www.garlic.com/~lynn/subpubkey.html#sslcert misc. collected past posts on certification enviornments that can be done w/o requiring digital certificates for representing that certification http://www.garlic.com/~lynn/subpubkey.html#certless ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: phishing web sites using self-signed certs
Ka-Ping Yee wrote: On Wed, 2 Nov 2005, Julien Pierre wrote: The account (or other relationship) you previously established at the website you wanted -- the "one truly intended" as you put it. The phisher wants to fool you into believing you are participating in that relationship when in reality you are dealing with an impostor. By keeping note of the certificate information, your browser can tell you reliably whether you are dealing with the same site and not an impostor. No. A party is allowed to use more than one certificate, for reasons such as renewal, or many other. There is nothing in X.509 or SSL that says one party only has one cert, quite the contrary. The fact that the certificate has changed since your last communication does not tell you that you aren't dealing still with the same site . If you used that logic, and you were fooled the first time into accepting the cert, you will be fooled again the second time and be talking with the same impostor. Assuming your IM protocol is encrypted, somehow when your IM client talks to an IM server, or to an IM peer, it needs to verify the identity of that server or peer before logging in. Encryption buys you nothing if your client encrypts to the wrong party. Your buddy list should record the key that was used last time and identify the other party by the fact that it is using the same key this time. That assumes you weren't fooled the first time, and the peer always uses the same key. Some protocols might have the later attribute, but you would still need to solve the first problem of the initial verification. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: phishing web sites using self-signed certs
On Wed, 2 Nov 2005, Julien Pierre wrote: > Ka-Ping Yee wrote: > >>What other way does the average non-technical user have to know that the > >>secure website is the one truly intended and not a fake, except than to > >>rely upon a third party to do the verification for them ? Self-signed > >>certs certainly don't provide any of that type of assurance. > > > > What matters is that the certificate represents the *same* organization > > you created the account with, not that the certificate was purchased > > from a particular company. > > What account or you talking about ? The account (or other relationship) you previously established at the website you wanted -- the "one truly intended" as you put it. The phisher wants to fool you into believing you are participating in that relationship when in reality you are dealing with an impostor. By keeping note of the certificate information, your browser can tell you reliably whether you are dealing with the same site and not an impostor. > Assuming your IM protocol is encrypted, somehow when your IM client > talks to an IM server, or to an IM peer, it needs to verify the identity > of that server or peer before logging in. Encryption buys you nothing if > your client encrypts to the wrong party. Your buddy list should record the key that was used last time and identify the other party by the fact that it is using the same key this time. -- ?!ng ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: phishing web sites using self-signed certs
On Thu, 3 Nov 2005, Duane wrote: > Ka-Ping Yee wrote: > > Using a petname field to label a website is really no different than > > assigning names to your IM buddies, which people already do. Why doesn't > > impersonation work on IM? [*] Because your buddy list keeps track of who > > you know. It can be the same way, and just as easy, with Web browsers. > > The difference being that you form a close relationship with IM buddies, > the same can't be said for a shop you go online to purchase from you > found on pricewatch.com... Let's make sure we're talking about the same problem here. When we're talking about phishing, i assume this means a scam where someone tries to impersonate a website you already have a relationship with -- for example, they're trying to get your online banking password. A petname (or buddy-list-like) mechanism can protect you from that type of attack. Were you thinking of a different attack? -- ?!ng ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: phishing web sites using self-signed certs
Ka-Ping, Ka-Ping Yee wrote: What other way does the average non-technical user have to know that the secure website is the one truly intended and not a fake, except than to rely upon a third party to do the verification for them ? Self-signed certs certainly don't provide any of that type of assurance. What matters is that the certificate represents the *same* organization you created the account with, not that the certificate was purchased from a particular company. What account or you talking about ? Using a petname field to label a website is really no different than assigning names to your IM buddies, which people already do. Why doesn't impersonation work on IM? [*] Because your buddy list keeps track of who you know. It can be the same way, and just as easy, with Web browsers. -- ?!ng [*] If your IM protocol is not encrypted, you are vulnerable. Compare apples to apples, though: the analogy is between encrypted IM and browsing the Web with SSL. Assuming your IM protocol is encrypted, somehow when your IM client talks to an IM server, or to an IM peer, it needs to verify the identity of that server or peer before logging in. Encryption buys you nothing if your client encrypts to the wrong party. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: phishing web sites using self-signed certs
Ka-Ping Yee wrote: Using a petname field to label a website is really no different than assigning names to your IM buddies, which people already do. Why doesn't impersonation work on IM? [*] Because your buddy list keeps track of who you know. It can be the same way, and just as easy, with Web browsers. The difference being that you form a close relationship with IM buddies, the same can't be said for a shop you go online to purchase from you found on pricewatch.com... -- Best regards, Duane http://www.cacert.org - Free Security Certificates http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://happysnapper.com.au - Sell your photos over the net! http://e164.org - Using Enum.164 to interconnect asterisk servers "In the long run the pessimist may be proved right, but the optimist has a better time on the trip." ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: phishing web sites using self-signed certs
On Tue, 1 Nov 2005, Julien Pierre wrote: > Ka-Ping Yee wrote: > > What fraction of the 30 to 50 root CAs on your root CA list do you > > know or have ever heard of? Do you know their policies? Do you know > > their management? Why should you trust them? > > > > What makes a website legitimate is the fact that it is the website > > you truly intended, not the fact that it happens to have paid a member > > of the CA extortion ring. > > What other way does the average non-technical user have to know that the > secure website is the one truly intended and not a fake, except than to > rely upon a third party to do the verification for them ? Self-signed > certs certainly don't provide any of that type of assurance. What matters is that the certificate represents the *same* organization you created the account with, not that the certificate was purchased from a particular company. Browsers should help users keep track of these identities, using mechanisms such as the petname toolbar, instead of showing more warning dialogs or making warnings more severe. Using a petname field to label a website is really no different than assigning names to your IM buddies, which people already do. Why doesn't impersonation work on IM? [*] Because your buddy list keeps track of who you know. It can be the same way, and just as easy, with Web browsers. -- ?!ng [*] If your IM protocol is not encrypted, you are vulnerable. Compare apples to apples, though: the analogy is between encrypted IM and browsing the Web with SSL. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: phishing web sites using self-signed certs
Arshad Noor wrote: The ICANN analogy is not appropriate in this context, because You missed the point I was making, the internet is global, not geographically localised in the case of issuing business names, this is compounded by the fact that .com/net/org is literally a free for all rather then forcing people to register under country code TLDs. This may be ok *IF* and it's a big if the browsers honoured some of the RFCs with respect to scope of allocations, but this isn't the case at present. So if all countries fronted up with a root certificate or one for each state which is the case in both the US and Australia, and then started issuing certificates for "*" suddenly the any government can be snooping all your encrypted traffic because they browsers never track certificate fingerprints. Further more do you trust EVERY SINGLE government out there to take proper safe guards of their private keys? What happens if a corrupt government sells a private key to scammers and they start issuing certificates for scam sites? Nice idea in theory, but then again everything works in theory... -- Best regards, Duane http://www.cacert.org - Free Security Certificates http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://happysnapper.com.au - Sell your photos over the net! http://e164.org - Using Enum.164 to interconnect asterisk servers "In the long run the pessimist may be proved right, but the optimist has a better time on the trip." ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: phishing web sites using self-signed certs
Ka-Ping Yee <[EMAIL PROTECTED]> writes: > Refusing to accept self-signed certificates is *not* the right thing > to do. That would only further the notion that buying a certificate > from one of dozens of approved CAs is what makes a website legitimate, > which is false. Not necessairly. It will shift the focus from certificate warnings to the installation of additional root CAs. The problems will remain the same, however the users will suffer as some websites won't be accessible for them. Hendrik ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: phishing web sites using self-signed certs
No, I'm afraid you got that wrong. Any site is free to do what they want. Consumers are also free to do what they want. However, the outlined scheme provides for a uniform way for a consumer to trust a company's digital certificate, based on the laws of the jurisdiction that established that company in the real world. As a consumer, I still get to choose whether I trust that company or not - but the legitimacy of the company or its digital certificate is not in question. There is a corollary benefit to the outlined scheme: today, as long as your credit card is good, you can get a server SSL certificate from most CA's in the browser, regardless of who you are. Thus, the existing scheme, benefits attackers. The outlined scheme has an underlying paper-trail by default, potentially leading to officers of the business entity who can be held responsible for illegal activities. Arshad Noor StrongAuth, Inc. cdr wrote: Did I get that right...? Do you seriously propose that only government-sanctioned sites should be capable of conducting secure transactions? cdr ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: phishing web sites using self-signed certs
The reality is that we have no choice, but to trust the government for its process to establish legitimate business entities - we, the people, made it the law as part of our civil code. Funnily, it does work. Every jurisdiction is responsible for legitimizing the creation, or existence, of a real business entity, following its own rules. It is the disjointed trust model created by private CA's, that introduces the cracks in the model. This is not to say that the government can be trusted to do the right thing - but they already have the authority (by law), the infra- structure (people and process) and the information (the database of all legitimate businesses in their jurisdiction) to make the trust model more uniform. The ICANN analogy is not appropriate in this context, because ICANN - even though a private non-profit entity - is beholden to the US Dept. of Commerce by contract - the MOU they signed many years ago requires them to meet goals established by this US agency, thus allowing the US to influence what it does, however small that influence might be: (http://www.ntia.doc.gov/ntiahome/congress/2004/ICANNhearing_09302004.htm). On the other hand, the scheme outlined in my e-mail allows every country to retain its own rules and processes for legitimizing businesses, simply extending that model to now include the self-signed CA's of the authorized businesses. No US control over anything other than that businesses incorporated in the US would have to work through their local Secretary of State office to get theis self-signed CA certs validated as part of their incorporation process. Arshad Noor StrongAuth, Inc. Duane wrote: > Nice idea in theory, but everything works in theory, however the icann issue at present is the crux of the internet trust debate, other governments don't trust the US govt to screw them, and vice versa, I don't think I'd be willing to trust most governments on the matter of being CAs... or any for that matter... ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: phishing web sites using self-signed certs
Julien Pierre wrote: Regardless, it is the right thing to do. If non-technical users want to shoot themselves in the foot, they should certainly be free to do so - using another browser. And guess who your biggest users are at present, biting the hand that feeds you (or keeps you alive) isn't exactly a wise move... -- Best regards, Duane http://www.cacert.org - Free Security Certificates http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://happysnapper.com.au - Sell your photos over the net! http://e164.org - Using Enum.164 to interconnect asterisk servers "In the long run the pessimist may be proved right, but the optimist has a better time on the trip." ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: phishing web sites using self-signed certs
Arshad Noor wrote: In the real world, we trust the Secretary of State (at least, in the US) to "authenticate" businesses. They are the only ones authorized to issue "Certificates of Inforporation" that legitimizes a US business. (Similar agencies perform such functions in other countries, to the best of my knowledge). Nice idea in theory, but everything works in theory, however the icann issue at present is the crux of the internet trust debate, other governments don't trust the US govt to screw them, and vice versa, I don't think I'd be willing to trust most governments on the matter of being CAs... or any for that matter... -- Best regards, Duane http://www.cacert.org - Free Security Certificates http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://happysnapper.com.au - Sell your photos over the net! http://e164.org - Using Enum.164 to interconnect asterisk servers "In the long run the pessimist may be proved right, but the optimist has a better time on the trip." ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: phishing web sites using self-signed certs
While third-party verification is not the real issue, the issue is: can the third-party itself be trusted? Who remembers the Verisign debacle from a few years ago with the Class-3 digital certificates issued through a social engineering attack, in the name of Microsoft? http://news.com.com/2100-1001-254586.html?legacy=cnet http://www.eweek.com/article2/0,1895,1243314,00.asp In the real world, we trust the Secretary of State (at least, in the US) to "authenticate" businesses. They are the only ones authorized to issue "Certificates of Inforporation" that legitimizes a US business. (Similar agencies perform such functions in other countries, to the best of my knowledge). It is my belief that what is needed is a new trust model, where only the digital certificates of CA's of a federal entity of a nation (such as that of the Office of the President) is in the browser, and is placed in commercial browsers through a very elaborate protocol. The Federal CA in turn, will issue the CA certificates of the states that are part of that federal entity (the 50 US states, for example), who in turn will issue the CA certificate for the office of the Secretary of State in each state. For smaller nations, the Federal CA might issue the certificate to the agency that incorporates/licenses business entities, directly. The OSOS CA will accept self-signed CA certificates from any business entity, just as it accepts "self-signed" paper applications to create a new business entity. Once the paper "Certificate of Incorporation" has been issued, the Base-64 encoded self-signed certificate of the business entity is signed by an OSOS CA-issued certificate, chaining upto the Federal CA certificate in the browser, thus establishing the legal business entity on the internet. Now, when the browser sees a self-signed certificate that does not chain upto a Federal CA of some nation, it can legitimately state that the server certificate appears to be from an unknown business entity which does not appear in the directory of the local authorizing government agency. I don't know of many users who will continue to click through such a message no matter what their business need is. Third-party CA operators (including StrongAuth) should only be in the business of building and operating PKI's - not establishing trust. Until such a trust model, and a supporting protocol to use it, is created, we can expect certificate trust problems to only exacerbate. Arshad Noor StrongAuth, Inc. Julien Pierre wrote: What other way does the average non-technical user have to know that the secure website is the one truly intended and not a fake, except than to rely upon a third party to do the verification for them ? Self-signed certs certainly don't provide any of that type of assurance. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: phishing web sites using self-signed certs
Ka-Ping Yee wrote: Refusing to accept self-signed certificates is *not* the right thing to do. That would only further the notion that buying a certificate from one of dozens of approved CAs is what makes a website legitimate, which is false. What fraction of the 30 to 50 root CAs on your root CA list do you know or have ever heard of? Do you know their policies? Do you know their management? Why should you trust them? What makes a website legitimate is the fact that it is the website you truly intended, not the fact that it happens to have paid a member of the CA extortion ring. What other way does the average non-technical user have to know that the secure website is the one truly intended and not a fake, except than to rely upon a third party to do the verification for them ? Self-signed certs certainly don't provide any of that type of assurance. The only valid exception may be when you are connecting to your own hosts over a very controlled private network. In this case no third party verification is necessary. But most non-technical users don't do that. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: phishing web sites using self-signed certs
On Tue, 1 Nov 2005, Julien Pierre wrote: > Regardless, it is the right thing to do. If non-technical users want to > shoot themselves in the foot, they should certainly be free to do so - > using another browser. Refusing to accept self-signed certificates is *not* the right thing to do. That would only further the notion that buying a certificate from one of dozens of approved CAs is what makes a website legitimate, which is false. What fraction of the 30 to 50 root CAs on your root CA list do you know or have ever heard of? Do you know their policies? Do you know their management? Why should you trust them? What makes a website legitimate is the fact that it is the website you truly intended, not the fact that it happens to have paid a member of the CA extortion ring. -- ?!ng ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: phishing web sites using self-signed certs
cdr wrote: Peter Gutmann wrote: Treat it as an unrecoverable error... ...in the same format as [...] a "Server not found"-type message. If only it was so simple... If this was to be done, it would quickly become the best known example of simple-minded, ill suited for real world "I-know-best" attitude on the part of programmer. We know users have choice, and the net result, I predict, would be their migration to other browsers. Regardless, it is the right thing to do. If non-technical users want to shoot themselves in the foot, they should certainly be free to do so - using another browser. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: phishing web sites using self-signed certs
Peter Gutmann wrote: Treat it as an unrecoverable error... ...in the same format as [...] a "Server not found"-type message. If only it was so simple... If this was to be done, it would quickly become the best known example of simple-minded, ill suited for real world "I-know-best" attitude on the part of programmer. We know users have choice, and the net result, I predict, would be their migration to other browsers. cdr ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: phishing web sites using self-signed certs
Nelson B <[EMAIL PROTECTED]> writes: >Peter, >Please spell out for us exactly what you mean by >> "treat a cert validation failure in the same way as a network error" >Do you mean to treat it as unrecoveragle error, with no option to override? >or ?? Treat it as an unrecoverable error. Providing non-technical users with an opt-out screen and an "I'm feeling lucky" button to click on is just security theatre, if you're serious about security then make it a nonrecoverable error in the same format as [tabs across to Firefox to check what it says] a "Server not found"-type message. If the user is expecting to talk to a server in a secure manner and the security fails, then it's a fatal error, not a one-click speedbump to annoy them. Peter. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: phishing web sites using self-signed certs
Peter Gutmann wrote: > Nelson B <[EMAIL PROTECTED]> writes: > >>As reported in >>http://www.informationweek.com/shared/printableArticle.jhtml?articleID=171200010 >>phishers are now using self-signed certs on their phony web sites, to make >>the lock icons appear for their web sites, to give the victims a false sense >>of security. > >>Of course, the victims must first dismiss a large warnign dialog about >>the cert coming from an unknown issuer. But according to the article, >>many users dismiss that dialog without any understanding of what it means. > > No-one's ever done a rigorous study of this, but there is plenty of anecdotal > evidence (e.g. the site that had a large red cross and "Invalid Certificate" > on it that users had to click past before making multi-thousand-dollar > payments, the bank site with an invalid cert that didn't stop 299 of 300 > users, etc etc) that cert warnings are almost completely ineffective in > stopping users from going to a web page that they want to visit. That's why > the best strategy for this is to treat a cert validation failure in the same > way as a network error: Users know how to handle this, and it puts pressure on > site admins to get things right. Peter, Please spell out for us exactly what you mean by > "treat a cert validation failure in the same way as a network error" Do you mean to treat it as unrecoveragle error, with no option to override? or ?? Thanks for your feedback. -- Nelson B ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: phishing web sites using self-signed certs
Nelson B <[EMAIL PROTECTED]> writes: >As reported in >http://www.informationweek.com/shared/printableArticle.jhtml?articleID=171200010 >phishers are now using self-signed certs on their phony web sites, to make >the lock icons appear for their web sites, to give the victims a false sense >of security. >Of course, the victims must first dismiss a large warnign dialog about >the cert coming from an unknown issuer. But according to the article, >many users dismiss that dialog without any understanding of what it means. No-one's ever done a rigorous study of this, but there is plenty of anecdotal evidence (e.g. the site that had a large red cross and "Invalid Certificate" on it that users had to click past before making multi-thousand-dollar payments, the bank site with an invalid cert that didn't stop 299 of 300 users, etc etc) that cert warnings are almost completely ineffective in stopping users from going to a web page that they want to visit. That's why the best strategy for this is to treat a cert validation failure in the same way as a network error: Users know how to handle this, and it puts pressure on site admins to get things right. Peter. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: phishing web sites using self-signed certs
Nelson B <[EMAIL PROTECTED]> writes: > I think this is further evidence that basic (not "advanced") users should > not be able to override such cert validity errors. Won't help much. The Phishers will start to use domain-validated certs and I guess they won't run short of credit card numbers. Hendrik ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
