Re: Using crypto against Phishing, Spoofing and Spamming...
Ian Grigg [EMAIL PROTECTED] writes: Notwithstanding that, I would suggest that the money already lost is in excess of the amount paid out to Certificate Authorities for secure ecommerce certificates (somewhere around $100 million I guess) to date. As predicted, the CA-signed certificate missed the mark, secure browsing is not secure, and the continued resistance against revision of the browser's useless padlock display is the barrier to addressing phishing. I don't accept this argument at all. There are at least three potential kinds of attack here: (1) Completely passive capture attacks. (2) Semi-active attacks that don't involve screwing with the network infrastructure (standard phishing attacks) (3) Active attacks on the network infrastructure. SSL does a fine job of protecting against (1) and a fairly adequate job of protecting against (3). Certainly you could do a better job against (3) if either: (a) You could directly connect to sites with SSL a la https://www.expedia.com/ (b) The identities were more user-friendly as we anticipated back in the days of S-HTTP rather than being domain names, as required by SSL. It does a lousy job of protecting against (3). Now, my threat model mostly includes (1), does not really include (3), and I'm careful not to do things that leave me susceptible to (2), so SSL does in fact protect against the attacks in my threat model. I know a number of other people with similar threat models. Accordingly, I think the claim that secure browsing is not secure rather overstates the case. -Ekr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Using crypto against Phishing, Spoofing and Spamming...
But is it so harmful? How much money is lost in a typical phishing attack against a large US bank, or PayPal? A lot. According to people at the anti-phishing conference earlier this year, six-figure losses are common, and seven-figure not unknown. The kind of phishes we all see, trolling for credit card or ISP account info with spam, are the lowest level kind. The serious ones carefully choose their targets, e.g., ebay sellers with very high positive ratings, or people who live outside the US and have large US bank accounts, and are more likely to send hundreds of messages than millions. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor A book is a sneeze. - E.B. White, on the writing of Charlotte's Web - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Using crypto against Phishing, Spoofing and Spamming...
Eric Rescorla wrote: Ian Grigg [EMAIL PROTECTED] writes: Notwithstanding that, I would suggest that the money already lost is in excess of the amount paid out to Certificate Authorities for secure ecommerce certificates (somewhere around $100 million I guess) to date. As predicted, the CA-signed certificate missed the mark, secure browsing is not secure, and the continued resistance against revision of the browser's useless padlock display is the barrier to addressing phishing. I don't accept this argument at all. There are at least three potential kinds of attack here: (1) Completely passive capture attacks. (2) Semi-active attacks that don't involve screwing with the network infrastructure (standard phishing attacks) By (2) I guess you mean a bypass MITM? (3) Active attacks on the network infrastructure. By (3) I guess you mean a protocol level MITM. Then, there is: (4) Active attacks against the client. By this I mean hacking the client, installing a virus, malware, spyware or whathaveyou. (This is now real, folks.) (5) Active attacks against the server. Basically, hacking the server and stealing all the good stuff. (This has always been real, ever since there have been servers.) (6), (7) Insider attacks against client, server. Just read off the data and misuse it. (This has been real since the dawn of time...) Of course, SSL/SB doesn't protect against any of these, and many people therefore assume the thinking stops there. Sadly, no. Even though SSL doesn't protect against these attacks, the frequency cost of these attacks directly impacts on the design choices of secure browsing. SSL does a fine job of protecting against (1) and a fairly adequate job of protecting against (3). Certainly you could do a better job against (3) if either: (a) You could directly connect to sites with SSL a la https://www.expedia.com/ (b) The identities were more user-friendly as we anticipated back in the days of S-HTTP rather than being domain names, as required by SSL. It does a lousy job of protecting against (3). Sorry, I'm having trouble parsing fairly adequate versus lousy job for threat (3)... Both (a) and (b) seem to deserve some examples? I can connect directly to expedia, and https://www.paypal.com/ is friendly enough? (Hmmm... I tell a lie, there is no https://www.expedia.com/ as it redirects.) Now, my threat model mostly includes (1), does not really include (3), and I'm careful not to do things that leave me susceptible to (2), so SSL does in fact protect against the attacks in my threat model. I know a number of other people with similar threat models. Accordingly, I think the claim that secure browsing is not secure rather overstates the case. (1) OK. Now, granted, SSL protects against (1), fairly finely. It does so in all its guises, although the CA-signed variant in secure browsing does so at some additional unneeded expense, as it eliminates certain secure options, being SSCs and ADH. OTOH, this is a really rare attack - actual damage from sniffing HTTP traffic doesn't seem to be recorded anywhere as a real attack on people, so forgive me if I downgrade this one as almost not a threat. (2) Then we come to (2), what i'd call a bypass MITM. Or a phish or a spoof. (I'm not sure what semi active and infrastructure have to do with it.) This one is certainly a threat. When the browser is presented with a URL which happens to purport only to be some secure site, without really being that site, this is a spoof. Your defence is to be careful against this attack. So, your defence is nothing to do with SSL or secure browsing or anything really, literally, (2) is unprotected against by SSL and secure browsing in all their guises. You yourself provide the protection, because SSL / secure browsing does not. Of course. That is my point - secure browsing does not protect against any real present threat. (3) I don't understand at all. But you suggest that it's not your threat and it isn't protected well against. In summary - we are left with one attack that is well protected against, but isn't really seen that much, and could be done with ADH. Then, another attack that you deal with yourself, so that's not really relevant coz you're smart and experienced, and those using browsers on the average are not, and they are hit by the attack. Then there is (3). (And we haven't even begun on (4) thru (7). What then, is a threat model that only includes some threats?) So in sum, I think my argument remains unchallenged: secure browsing fails to secure. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: On `SSL considered harmful`, correct use of condoms and SSL abuse
Amir Herzberg wrote: (Amir, I replied to your other comments over on the Mozilla security forum, which is presumably where they will be more useful. That just leaves this:) So while `SSL is harmful` sounds sexy, I think it is misleading. Maybe `Stop SSL-Abuse!` Ha! I wondered when someone would take me to task over that title :-) Here's the thing: the title comes from a seminal paper called Gotos considered harmful [1] This was a highly controversial paper in the 70s or so that in no small part helped the development of structured programming. What the author of that paper was trying to say was not that the Goto was bad, but its use was substantially related to poor programming practice. And that's the point I'm making. The Goto is just a tool like any other. But, the Goto became a tool over- deployed and widely abused, as its early and liberal use by a programmer took no account of later maintenance costs that were incurred by the owner of the code. So the Goto became synonymous with bad programming and excessive costs. The same situation exists with SSL/TLS. As a protocol, it's a fine tool. It's strong, it's well reviewed, and it has corrected its deficiencies over time. But, it also comes with a wider security model. For starters, the CA-signed regime. As well as that, it comes with a variety of other baggage, which basically amounts to use SSL/TLS as it is recommended and you will be secure. Unfortunately, this is wrong, and the result is bad security practice. Yet, we do have a generation of people out there believing that because they have put huge amounts of effort into implementing SSL with its certs regime that they are secure. We can see this ludicrous situation with the email and chat variants of SSL / cert protected traffic. In those cases the result is the same: If one suggests that the correct approach is for them to use SSCs (self signed certs) or equivalent, people go all weak and wobbly at the knees and start ranting on about how those are insecure. Yet these same systems are totally open to attacks at the nodes and often to the intermediate hops, which of course is where 99% of the attacks are [2]. These programmers truly believe that in order to get security, they must deploy SSL. As the manual tells them to. They are truly wrong. In this, SSL has harmed them, because it has blinded them to the real risks that they are facing. It's not the tool that has hurt them, but as you suggest the abuse of the tool. Edsgar Dijkstra called for the abolition of Gotos as the way to address the harm he saw being done. That solution may offend, as the tool itself cannot have harmed. But, how else can we stop people deploying the tool so abusively? iang [1] Edsger W. Dijkstra, Go To Statement Considered Harmful, http://www.acm.org/classics/oct95/ [2] Jabber's use of SSL seems to mirror STARTTLS. They both protect the traffic on the wire, but not at rest on the hops. The certificate system built into mailers (name?) at least organises an end-to-end packet protection, thus leaving the two end nodes as the places at most risk, still by far the most likely place to be attacked. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: dual-use digital signature vulnerability
At 01:33 AM 7/18/2004, Amir Herzberg wrote: I don't see here any problem or attack. Indeed, there is difference between signature in the crypto sense and legally-binding signatures. The later are defined in one of two ways. One is by the `digital signature` laws in different countries/states; that approach if often problematic, since it is quite tricky to define in a general law a binding between a person or organization and a digital signature. The other way however is fine, imho: define the digital signature in a (`regular`) contract between the parties. The contract defines what the parties agree to be considered as equivalent to their (physical) signature, with well defined interpretation and restrictions. ... the digital signature laws, for the most part, defined how a certification authority went about binding the owner of a public key (or at least the entity presenting a public key and a digital signature that could be verified by that public key) and some other information ... and presenting that in a certificate. However, I don't remember seeing any of the e-sign laws a) defining a non-repudiation environment that is mandated for signature digital signing environments (indicating that the key owner has read, understood, and approves, agrees, and/or authorizes the contents of the message and b) as part of the integrity of the message, there is proof that such a non-repudiation environment was used. 1) the relying party being able to certify the integrity level of something like a hardware token for use in something you have authentication aka the relying party verifies a digital signature and that verification may used to imply something you have authentication (at this point there is absolutely nothing involving a certificate). However, in order for the relying party to be able to assume or imply what the verification of the digital signature actually means and therefor how much it can trust the verification ... it needs to know how the private key is maintained and operated. If the act of verifying a digital signature actually means or implies that it is something you have authentication ... then it needs to have some certification along the lines that the private key is used and maintained in a hardware token with specific characteristics. It has nothing at all to do with any certificate traditionally mentioned in various kinds of e-sign laws. 2) during the early '90s, the identity certificates tended to be overloaded with all sorts of identity and privacy information. this was fairly quickly realized to represent serious privacy and liability issues. this was retrenched to things like relying-only-party certificates that basically only had a public key and some sort of account identifier (which could be used by the relying-party to pull up the real information w/o having it publicly broadcast all over the world). However, there were also things like non-repudiation bits defined in certificates ... that have since been severely depreciated. During the mid-90s there were some infrastructures being proposed that if you had some data which had an appended digital signature and an appended certificate containing a non-repudiation bit then the burden of proof (in disputes) could be shifted from the relying party to the signing party. This was vulnerable to possibly two exploits a) the digital signer had believed that they had signed random data as part of an authentication protocol ... as opposed to having signed some document contents indicating agreement, approval, and/or authorization (as in real live signature aka the dual-use scenario) and/or b) since the appended certificate isn't part of the signed transaction the relying-party might be able to find a digital certificate (belonging to that key-owner for the same public key) that had the non-repudiation bit set and substitute a non-repudiation certificate for the certificate that the key-owner had actually appended (aka the certificate is not part of the integrity of the message covered under the digital signature). 3) at the NIST PKI workshop a couple months ago there were a number of infrastructure presentations where various entities in the infrastructure were a) signing random data as part of authentication protocol (where the entity performing the digital signature was given no opportunity to view the contents being signed) they were using hardware token implementation and they were assuming that the verification of the digital signature implied some sort of something you have authentication. however there was nothing in the infrastructure that provided certification and/or proof that the private key was kept and maintained in a hardware token so there was no proof as to the level of integrity and/or level of trust that the relying party could place in the verification of that digital signature b) signing authorization documents (using the same tokens that were used in the authentication
Re: Using crypto against Phishing, Spoofing and Spamming...
At 05:55 PM 7/17/2004, Eric Rescorla wrote: Now, my threat model mostly includes (1), does not really include (3), and I'm careful not to do things that leave me susceptible to (2), so SSL does in fact protect against the attacks in my threat model. I know a number of other people with similar threat models. Accordingly, I think the claim that secure browsing is not secure rather overstates the case. there sort of two parts of SSL I believe the original justification was based on perceived integrity issues with the domain name infrastructure and various kinds of hijacking attacks. the client got back a certificate, verified the integrity of the certificate (from a table of certificate authority public keys), verified that it appeared to originate from the certificate owner and then compared the certificate domain name string with the domain name used in the URL. once that was done, there was key-exchange to protect the contents of the transmission. the catch22 was that the domain name infrastructure is also the authoritative agency as to the owner of the domain name. the SSL domain name certification authorities have this horrendously, error prone and expensive problem of getting sufficient identification information from the certificate applicant and attempting to match it with the identification information carried by the domain name infrastructure as to the owner of the domain name. so the first issue is that the integrity of the domain name infrastructure could be attacked with a domain name hijack ... then the attacker applies for a certificate and the identification provided the certification authority and the identification on file with the domain name infrastructure compare ... and the attacker gets a valid certificate. so the certification authorities came up with a proposal to have domain name registers also supply a public key at the time of registration. then future communication with the domain name owner is digital signed ... which the domain name infrastructure can verify with the public key on file. this is a countermeasure against domain name hijacking (improving the integrity of the domain name infrastructure and rising the trust that certification authorities can place in the authoritative agency). the other issue is that the certification authorities can use the public key on file with the domain name infrastructure to turn an expensive, and error-prone identification process into a much simpler and KISS authentication process aka domain name certificate applicants digitally sign their requests ... which are then verified with the public key on file at the domain name infrastructure. the two issues then are that with increased domain name infrastructure trust ... 1) it should reduce the demand for domain name SSL certificates (motivated by integrity concerns about the domain name infrastructure) and 2) it could eliminate the need for domain name SSL certificates since all clients could possibly also use the public keys on file with the domain name infrastructure (in lieu of needing to get public keys from certificates). So now to the key-exchange issue protecting credit-card numbers from evesdropping and harvesting. The issue is that the crooks tend to go after the best fraud ROI (return on investment). The claim is that it is so much more profitable to harvest the merchant transaction file that until that barn door is closed the crooks have little incentive to go after credit card numbers by evesdropping packets in flight. There have been some assertions that there has been no known cases of picking up account numbers from packet evesdropping even where SSL or any other encryption is being used to protect data in-flight. Part of the issue is that evesdropping packets takes a lot more work ... and provides much less return than going after the merchant transaction file. Other scenarios have also been end-point attacks ... where password files are harvested and/or viruses are installed at end-points to harvest information as opposed to doing anything with data in-flight. So, it could be claimed that there is some question about what is cause and what is effect i.e. are the end-point attacks because everything is encrypted or are the end-point attacks occurring because they are so much more profitable and easier. Given that there are significant amounts of non-encrypted traffic ... then the claim could be made that the crooks are getting so much more from end-point attacks ... and until that is addressed ... that attacks on data in flight is somewhat academic (since there is so little evidence about fraud happening from data in flight attacks). The other argument has traditional been that 90 percent of fraud has been insiders, typically also associated with various kinds of end-point attacks (rather than any kind of outsider attack on data in flight). There was some recent
Re: Using crypto against Phishing, Spoofing and Spamming...
Enzo Michelangeli wrote: Can someone explain me how the phishermen escape identification and prosecution? Gaining online access to someone's account allows, at most, to execute wire transfers to other bank accounts: but in these days anonymous accounts are not exactly easy to get in any country, and anyway any bank large enough to be part of the SWIFT network would cooperate in the resolution of obviously criminal cases. Good question. Actually there are two questions we should consider: a) What are the procedures phishermen are using today, procedures that they manifestly *can* get away with? b) Why why why are they allowed to get away with such procedures? Here is something of an answer to question (a): http://www.esmartcorp.com/Hacker%20Articles/ar_Watch%20a%20hacker%20work%20the%20system.htm The details are a bit sketchy, and maybe not entirely to be trusted since they come from self-described crooks, but they are plausible. Still question (b) remains. The described procedures seem to be the e-commerce analog of parking your car in a bad neighborhood with the windows rolled down and the keys in the ignition. That is, I expect that most people on this list could easily think of several things the card-issuers could do that would shut down these attack-procedures, significantly raising the phishermen's work-factor and risk of arrest -- without significantly burdening legitimate merchands or cardholders. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: dual-use digital signature vulnerability
the fundamental issue is that there are infrastructures using the same public/private key pair to digital sign 1) random authentication data that signer never looks at and believe is of low value ... if they connect to anybody at all ... and are asked to digitally sign some random data for authentication purposes ... they do it. 2) contents that they supposedly have read, understood, and are indicating that they agree, approve and/or authorize. i haven't seen any definition of data arriving at the relying party where the relying party has proof of whether it was case #1 or case #2. The closest was the non-repudiation bit in a certificate. however, the non-repudiation bit in a certificate was put in there at the time the certificate was manufactured and in no way applies to the environment and conditions under which the signature in question actually occurred. there are definitions like non-repudiation services and/or the EU FINREAD definition ... which purports to specify the environment under which the signatures take place. Note however, while the EU FINREAD defines an environment where there is some indication that the signing party might have read and agreed to the contents of what is being signed there is nothing in the EU FINREAD specification that would provide proof to the relying party that a FINREAD terminal was actually used for any specific signing. Anything, like a flag ... not part of a signed message ... that might be appended to the transmission ... that makes claims about whether a FINREAD terminal was used or not ... could have originated from anywhere analogous to the example where a relying party might be able to substitute a certificate with the non-repudiation bit set in order to change the burden of proof from the relying party to the signing party (in a legal dispute ... more the mid-90s ... where non-repudiation flag in a certificate might have been thought to have some valid meaning (since the certificate wasn't covered by the signature anybody could claim any valid certificate was the certificate used for the transaction) In any case, if a signing party has ever used their private key to sign random data that they haven't read . and they are ever expected to use the same private key in legal signing operations where they are presumed to have read, understood, and approve, agree, and/or authorize the contents and there is no proof provided (or included) as part of the signed message that the signing occurred in a specified (non-repudiation) environment ... then there is no way that a relying party can prove or disprove under what conditions a digital signing actually occurred. misc. past post reference EU FINREAD: http://www.garlic.com/~lynn/aadsm9.htm#carnivore Shades of FV's Nathaniel Borenstein: Carnivore's Magic Lantern http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key http://www.garlic.com/~lynn/aadsm11.htm#4 AW: Digital signatures as proof http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm11.htm#23 Proxy PKI. Was: IBM alternative to PKI? http://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM] http://www.garlic.com/~lynn/aadsm14.htm#35 The real problem that https has conspicuously failed to fix http://www.garlic.com/~lynn/aadsm15.htm#40 FAQ: e-Signatures and Payments http://www.garlic.com/~lynn/aadsm16.htm#9 example: secure computing kernel needed http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure http://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper http://www.garlic.com/~lynn/aepay11.htm#54 FINREAD was. Authentication white paper http://www.garlic.com/~lynn/aepay11.htm#55 FINREAD ... and as an aside http://www.garlic.com/~lynn/aepay11.htm#56 FINREAD was. Authentication white paper http://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking http://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't work http://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't work http://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work http://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't work http://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe??? http://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible? http://www.garlic.com/~lynn/2001k.html#0 Are client certificates really secure? http://www.garlic.com/~lynn/2001m.html#6 Smart Card vs. Magnetic Strip Market http://www.garlic.com/~lynn/2001m.html#9 Smart Card vs. Magnetic Strip Market http://www.garlic.com/~lynn/2002c.html#10 Opinion on smartcard security requested http://www.garlic.com/~lynn/2002c.html#21 Opinion on smartcard security requested
Re: Using crypto against Phishing, Spoofing and Spamming...
Enzo Michelangeli wrote: Can someone explain me how the phishermen escape identification and prosecution? Gaining online access to someone's account allows, at most, to execute wire transfers to other bank accounts: but in these days anonymous accounts are not exactly easy to get in any country, and anyway any bank large enough to be part of the SWIFT network would cooperate in the resolution of obviously criminal cases. In practice something like this: Most of the money is wired through to some stolen account, and then moved out of the system to another system. This might be a foreign account, or it might be a non- bank such as a broker/dealer (E*Trade is being hit at the moment, it seems) or it might be a digital gold currency. From there, it is moved once or twice more, than back to the country where the phisher is. This might be the US or Russia, or anywhere else, but those two countries seem to be quite big on this (maybe we should blame Reagan :-) ) A couple of things: it is very hard, but not impossible to reverse a SWIFT style international wire. I've seen it done once, so I know it is not impossible. If the cash has gone, then reversing it doesn't make sense. Also, phishing isn't exactly a recognised and obvious criminal case. Any particular instance might be, but getting to that determination might take months. Further, opening accounts for anonymous purposes is still rather easy in many countries, the chief perpertrator of this being the USA. Finally, every attempt to make money less like money (by closing off easy accounts, for example) results in what some call unintended consequences - the money goes elsewhere. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: dual-use digital signature vulnerability
it isn't sufficient that you show there is some specific authentication protocol with unread, random data ... that has countermeasures against a dual-use attack ... but you have to exhaustively show that the private key has never, ever signed any unread random data that failed to contain dual-use countermeasure attack. Why isn't it sufficient? (Quick: when was the last time anyone on this list authenticated by signing unread random data?) The way the industry is going, user keypairs live in a desktop keystore, and are used for very few applications. I'd bet the vast majority of usages are client-side SSL, signing, and encryption. If this de facto universal usage suite contains exactly one authentication protocol that has a built-in countermeasure, then when this becomes solid, we're done. Our energy would be better spent on the real weaknesses: such as the ease of getting desktops to just cough up the private key, or to use it for client-side SSL without ever informing the user. And on the real problems: such as using the standard suite to get the trust assertions to match the way that trust really flows in the real world. --Sean - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
