Re: Another entry in the internet security hall of shame....
Paul Hoffman wrote: In many deployments of SSL first, then authenticate the user with a password, the site consists of two or more machines. Many or most high-traffic secure sites use SSL front-end systems to terminate the SSL connection, then pass the raw HTTP back to one or more web servers inside the network. The reason I bring this up is that the SSL server generally does not have access to the users' credentials. It could, of course, but in today's environments, it doesn't. Changing to TLS-PSK involves not only changing all the client SSL software and server SSL software, but also the what the SSL server's role in the transaction is. this is relatively straight-forward on the server side ... most webservers have stub-code for client authentication. frequently you see places writing roll-your-own code for accessing a password flat file (and comparing passwords for authentication). another approach is to have the webserver client authentication stub-code call kerberos or radius interface http://www.garlic.com/~lynn/subpubkey.html#kerberos http://www.garlic.com/~lynn/subpubkey.html#radius where the clients credentials are managed and administrated ... including authentication, authorizations and also potentially accounting information. the original pk-init draft for kerberos had public keys registered in lieu of passwords ... and kerberos doing digital signature verification with the on-file public key. similar implementations have existed for radius. http://www.garlic.com/~lynn/subtopic.html#certless basically use the extensive real-time administrative and operational support for integrated authentication, authorization and even accounting across the whole infrastructure. ISPs and/or corporations that currently use something like radius for their boundary authentication in places like dial-in routers ... could use the same exact administrative and operational facilities for providing client authentication, authorization and accounting for any webhosted services they might provide (aka ... the integrated administrative and operational support could include very dynamic and fine-grain authorization information ... like which set of servers during what portions of the day). the other advantage of the integrated real-time business, administrative, and operational of a radius type approach is that it can select the authentication technology used on a client-by-client basis ... it doesn't have to be a total system-wide conversion. the radius/kerberos solution could be rolled out on all the servers ... and then technology selectively rolled on a client-by-client basis ... continueing to use the same exact integrated business, admnistrative, and management real-time characteristics with large co-existance of different client technologies (for instance ... when clients setup their dial-in PPP connection to their server ... they may be offered a number of different authentication options ... a server-side radius operation can concurrently support all possible authentication technologies ... appropriantly specified technology on a client by client basis. kerbersos and radius are extensively used for doing real-time integrated administrative and management of authentication, authorization and even accounting information. registering public keys in lieu of passwords is a straight-forward technology operation upgraded ... preserving the existing business, management, and administrative real-time integrated characteristics. it wouldn't introduce new business, management, and/or administrative operations ... like frequently occurs with pki-based operations. with the use of the appropriate business, management, and administrative real-time infrastructure ... straight-forward new technology roll-outs addressing various authentication, authorization, and/or accounting requirements doesn't have to be a syncronized, serialized, system-wide change-out ... all the servers could be upgraded to a real-time business, management, and administrative infrastructure that is relatively technology agnostic as to the specific technology used by any specific client. then the specific technology used by any client then becomes an individual client decision coupled with possible infrastructure overall risk management requirements for that specific client when doing specific operations. one could imagine a wide-variety of clients ... all accessing the same identical infrastructure ... possibly concurrently using password, challenge/response, digital signature with and w/o hardware token protected private keys. specific authorization features might only be made available when the digital signature is believe to have originated from a private key that has been certified to exist in a hardware token with certified integrity charactistics (keys generated on the token, private key never leaves the token, token evaluated at EAL5, etc). Certain fine-grain entitlement permissions might conceivably even require options
Re: Another entry in the internet security hall of shame....
Read in an email from a website: You'll need to send us your CC information via regular email or fax. I would suggest splitting up your CC info if you send it to us via email in two separate emails for security. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
James A. Donald wrote: For PKI to have all these wonderful benefits, everyone needs his own certificate. But the masses have not come to the party, in part because of the rather Orwellian requirements. Obviously I cannot get a certificate testifying that I am the one true James Donald, because I probably am not. So I have to get a certificate saying I am the one true James Donald SS xxx-xx- - the number of the beast. the real issue in the early 90s ... was that the real authoritative agencies weren't certifying one true identity ... and issuing certificates representing such one true identity ... in part because there was some liability issues if somebody depended on the information ... and it turned out to be wrong. there was talk in the early 90s of independent 3rd party trust organizations scene and claimed that they would check with the official bodies as to the validity of the information ... and then certify that they had done that checking ... and issue a public key certificate indicating that they had done such checking (they weren't actually certifying the validaty of the information ... they were certifying that they had checked with somebody else regarding the validaty of the information). the issue of these independent 3rd party trust organizations was that they wan'ted to make money off of certifying that they had checked with the real organizations as to the validaty of the information ... and they way they were going to make this money was by selling public key digital certificates indicating that they had done such checking. the issue then came up was what sort of information would be of value to relying parties ... that should be checked on and included in a digital certificate as having been checked. It started to appear that the more personal information that was included ... the more value it would be to relying parties ... not just your name ... but name, ancestry, address, and loads of other characteristics (the time of stuff that relying parties might get if they did a real-time check with credit agency). one of the characteristics of the public key side of these digital certificates ... was that they could be freely distributed and published all over the world. by the mid-90s, institutions were starting to realize that such public key digital certificates ... freely published and distributed all over the world with enormous amounts of personal information represented significant privacy and liability issues. you can also consider that if there was such enormous amounts of personal information ... the certificate was no longer being used for just authenticating the person ... but was, in fact, identifying the person (another way of viewing the significant privacy and liability issues). as a result, you started seeing institutions issuing relying-party-only certificates in this time frame http://www.garlic.com/~lynn/subpubkey.html#rpo which contained just a public key and some sort of database or account lookup value ... where all the real information of interest to the institution was kept. the public key technology ... in the form of digital signature verification, would be used to authenticate the entity ... and the account lookup would establish association with all the necessary real-time information of interest to the institution. this had the beneficial side-effect of reverting public key operations to purely authentication operations ... as opposed to straying into the horrible privacy and liability issues related to constantly identifying the entity. however, it became trivial to prove that relying-party-only certificates are redundant and superfluos ... with all the real-time information of interest for the instittution on file (including the public key) ... and the entity digitally signing some sort of transaction which already included the database/account lookup value ... there was no useful additional information represented by the relying-party-only certificate ... that the relying party didn't already have (by definition, the public key was registered with the relying party as prelude to issuing any digital certificate ... but if the public key had to already be registered, then the issuing of the digital certificate became redundant and superfluous). this was also in the era where the EU data privacy directive was pushing that names be removed from various payment card instruments doing online electronic fund transactions. If the payment card is purely a something you have piece of authentication ... then it should be possible to perform a transactions w/o also requiring identification. as to the 2nd part ... passwords are a shared-secret, based, intrenched institutional-centric technology. it requires lot less technology infrastructure to support a shared-secret password based operation. this was ok back in the mar, 1970 ... when i got my first permanent home terminal with userid/password login to the office computer ... and i only had
Re: Another entry in the internet security hall of shame....
Stephan Neuhaus wrote: James A. Donald wrote: [...] That's because PSKs (as I have understood them) have storage and management issues that CA certificates don't have, [...] that the issue of how to exchange PSKs securely in the first place is left as an exercise for the reader (good luck!) See http://www.connotech.com/sakem_index.htm. Incidentally, TLS-PSK protocol standardization proposals has been around in the IETF for some time, and it is the mobile telephony development momentum made it pass the standardization process (e.g. drafts by Nokia). In the mobile telephony world, the physical distribution of subscriber identity mudules (i.e. integrated circuits with secret/private keying material) is physically distributed to subscribers. [...] ( [...] for the secure exchange of PSKs, which is IMHO unresolvable without changes to the business workflow). [...] But the server side? There are many more server applications than there are different Web browsers, and each one would have to be changed. At the very least, they'd need an administrative interface to enter and delete PSKs. That means that supporting PSKs is going to cost the businesses money (both to change their code and to change their workflow), money that they'd rather not spend on something that they probably perceive as the customer's (i.e., not their) problem, namely phishing. The incremental operating cost can be resaonable only for organizations that already incur the *authorization* management overhead. Fun, Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
Stephan Neuhaus [EMAIL PROTECTED] writes: I think you're talking about me here, Oh no, I wasn't focusing on any one person, it was a characterisation of the general response from security people when this sort of thing is mentioned. Long before the discussion on this list, there were already missionaries coming to the ietf-tls list to enlighten the heathens who dared to mention PSK and remind them of their duty to support PKI in all its infinite perfection, and not to take any false gods before it. I also didn't say that passwords didn't *work*, I said that they had *storage and management issues* that certificates did not have and that their deployment would be problematic because of that, and I stand by that. Sure, but those issues have already been addressed by pretty much every site that needs to use passwords or user authentication for any reason. That's the point I was trying to make, that the standard response to use of passwords (or PSKs) is they don't work, they don't scale, you can't handle revocation, distribution is a problem, etc etc etc. However, despite all of these issues, all the sites that need to authenticate users are using passwords, and they seem to be doing OK with that. Rather, it is my impression that a switch to TLS-PSK would not just be a client-side thing, but that server code would have to be changed also, and that it is this issue which will prevent widespread deployment of TLS-PSK. Sure, that will be an issue. I think it depends on how much pain banks and merchants are willing to endure due to phishing attacks. The problem with current authentication methods is that the authenticated is in completely the wrong direction to prevent phishing, and the phishing industry has developed in response to the fact that TLS server cert-based auth is useless against it. TLS-PSK addresses this problem. Not only does it authenticate the server, but it authenticates it in a manner that proves the server has direct knowledge of the client, not merely that they've shelled out all of $7 for a server cert. So in other words I could be directed by phishers to dozens of sites all claiming to be XYZ Bank, some even with TLS certs proving this, but only one will be able to authenticate itself to me as my bank. If you look at this in terms of attack surface reduction, it's gone from: The software I use will hand my password over (in plaintext) to anything claiming to be my bank. to: An attacker will have to get to me during the enrolment phase, or compromise the bank's server to steal the passwords. This is an *enormous* reduction in attack surface. Compromising the enrolment phase would typically require a huge spoofing effort or powerful MITM, much more than the spam out a plausible password-renewal request type of attack that's been so successful against the current way of doing things. If I were a phisher, I'd set up a web site having normal text boxes for username and password. On it, I'd put a link why isn't the URL bar blue? and use some technical mumbo-jumbo about how for technical reasons, the feature needed to be disabled in the browser, Yeah, that's still a possibility, although I think you can probably train most users to not do this. I only know about NZ banking practices here, but every one of them provides a best-practices way to do things (don't do banking from an Internet cafe, check for the padlock, when logging on check that the last- logon time display was when you actually logged on, etc etc). Drilling it into people that if they don't see the blue flashy bits there's a problem shouldn't be that hard. Sure, there'll be some margin-of-error group who still won't get the message, but these same people would also hand out their credit card details over the phone to someone claiming to be from their bank. The thing is, TLS-PSK provides major attack surface reduction, and that's a big win in the fight against phishing. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
Alaric Dailey [EMAIL PROTECTED] writes: While I admit that PKI is flawed, I don't see anyway that PSK could used effectively. How are PSKs going to be shared in a secure way? are we talking about generating a new key for every connection? if so how do you validate the key? if not, how do you validate that the key hasn't been compromised by someone who put up a phishing site? Gosh, I don't know. How about the way we've already been doing it for the past decade or so on every single passworded web site in existence, and for another decade before that with ATM PINs. In my opinion, PSK has the same problems as all symmetric encryption, its great if you can share the secret securely, but distribution to the masses makes it infeasible. Exactly, PSK's are infeasible, and all those thousands of web sites that have successfully employed them for a decade or more are all just figments of our imagination. By extension, ATMs are also infeasible. Sarcasm aside for a minute, several people have responded to the PSK thread with the standard passwords don't work, whine moan complain response that security people are expected to give whenever passwords are mentioned. It's all the user's fault, they should learn how to use PKI. Well we've had ten years of that and it seems to be making bugger-all difference in protecting users, based on the universal success of phishing attacks. What's happened is that security people have said Here's our perfect solution, PKI, and we're not budging an inch on that, the masses have said We can't manage anything beyond usernames and passwords and we're not budging an inch on that, and the phishers have leaped in and filled the gap between the two while both sides are sitting there holding their breath to see whose face goes blue first. The failing is in the security community. Security practitioners (by which I mean people who build secure systems, not ones who merely go out and pontificate about them) have 30 years of research in authentication mechanisms to fall back on, and yet the state-of-the-art in use today is to hand out the plaintext password to anyone who asks for it: Hi, I'm your bank, or Paypal, or something, please give me your password. Instead of using a decent (and trivial to implement) challenge-response mutual-authentication mechanism, we're using the worst possible one there is, the one that every security textbook warns against, while sitting back and waiting for PKI to start working. My mother (to use my favourite canonical non-technical user) has figured out how to use a username and password to authenticate herself. She hasn't, and never will, figure out PKI, and nor will most of the rest of humanity. The users have amply demonstrated to us what they're capable of handling. It is the failing of the security community to not use that effectively - password- based authentication is bad because the security community (or at least security application developers) have made it bad, not because it's inherently poor. Here's my proposal for an unmistakable TLS-PSK based authentication mechanism for a browser: When connecting to a TLS-PSK protected site, the URL bar (or something else very obvious, say the top border of the page) is set to a colour like blue, matching what Mozilla currently does with its yellow for SSL sites. The blue bar then zooms out into a blue-marked dialog box asking for the username and password (I'm assuming here that you can't spoof this sort of thing in Javascript). Once the mutual auth of client and server has occurred, the blue-marked dialog box zooms back to the blue-marked web page, providing a clear connection between all stages of authentication and secure display. All that users have to learn is to never enter their password on a non-blue-marked site. It doesn't solve *all* phishing problems, but it's a darn sight better than the mess we're in now. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
Peter Gutmann wrote: Alaric Dailey [EMAIL PROTECTED] writes: While I admit that PKI is flawed, I don't see anyway that PSK could used effectively. How are PSKs going to be shared in a secure way? are we talking about generating a new key for every connection? if so how do you validate the key? if not, how do you validate that the key hasn't been compromised by someone who put up a phishing site? Gosh, I don't know. How about the way we've already been doing it for the past decade or so on every single passworded web site in existence, and for another decade before that with ATM PINs. In my opinion, PSK has the same problems as all symmetric encryption, its great if you can share the secret securely, but distribution to the masses makes it infeasible. Exactly, PSK's are infeasible, and all those thousands of web sites that have successfully employed them for a decade or more are all just figments of our imagination. Show me one sight that uses PSKs to secure its connection to the masses. By extension, ATMs are also infeasible. ATMs would be infeasible if they were not a 2 factor authentication system, and every day we see more cracks in the way that system is implemented. Starting with the way the PSKs are shared. http://news.bbc.co.uk/1/hi/technology/4183330.stm Sarcasm aside for a minute, several people have responded to the PSK thread with the standard passwords don't work, whine moan complain response that security people are expected to give whenever passwords are mentioned. It's all the user's fault, they should learn how to use PKI. Well we've had ten years of that and it seems to be making bugger-all difference in protecting users, based on the universal success of phishing attacks. What's happened is that security people have said Here's our perfect solution, PKI, and we're not budging an inch on that, the masses have said We can't manage anything beyond usernames and passwords and we're not budging an inch on that, and the phishers have leaped in and filled the gap between the two while both sides are sitting there holding their breath to see whose face goes blue first. The failing is in the security community. Security practitioners (by which I mean people who build secure systems, not ones who merely go out and pontificate about them) have 30 years of research in authentication mechanisms to fall back on, and yet the state-of-the-art in use today is to hand out the plaintext password to anyone who asks for it: Hi, I'm your bank, or Paypal, or something, please give me your password. Instead of using a decent (and trivial to implement) challenge-response mutual-authentication mechanism, we're using the worst possible one there is, the one that every security textbook warns against, while sitting back and waiting for PKI to start working. My mother (to use my favourite canonical non-technical user) has figured out how to use a username and password to authenticate herself. She hasn't, and never will, figure out PKI, and nor will most of the rest of humanity. The users have amply demonstrated to us what they're capable of handling. It is the failing of the security community to not use that effectively - password- based authentication is bad because the security community (or at least security application developers) have made it bad, not because it's inherently poor. Here's my proposal for an unmistakable TLS-PSK based authentication mechanism for a browser: When connecting to a TLS-PSK protected site, the URL bar (or something else very obvious, say the top border of the page) is set to a colour like blue, matching what Mozilla currently does with its yellow for SSL sites. The blue bar then zooms out into a blue-marked dialog box asking for the username and password (I'm assuming here that you can't spoof this sort of thing in Javascript). Once the mutual auth of client and server has occurred, the blue-marked dialog box zooms back to the blue-marked web page, providing a clear connection between all stages of authentication and secure display. All that users have to learn is to never enter their password on a non-blue-marked site. It doesn't solve *all* phishing problems, but it's a darn sight better than the mess we're in now. Peter. Your solution doesn't cover any of the problems with phishing, come on, if all we have is a preshared key, how is a user who can't even verify the details of a cert going to know if the site they have connected to is legitimate, all those wonderful AOL users will be easily duped into putting in their 1 weak password of love, sex, god or money and the phisher will have their info. And we won't even get into the fact that easy to guess PSKs are the one real weakness symmetric encryption systems that actually can keep the secret of their PSK. I also wont start on a rant about how all those wonderful AOL users won't be able to keep track of all those PSKs if they are unique
Re: Another entry in the internet security hall of shame....
Peter Gutmann wrote: Alaric Dailey [EMAIL PROTECTED] writes: In my opinion, PSK has the same problems as all symmetric encryption, its great if you can share the secret securely, but distribution to the masses makes it infeasible. Exactly, PSK's are infeasible, and all those thousands of web sites that have successfully employed them for a decade or more are all just figments of our imagination. By extension, ATMs are also infeasible. I don't know about New Zealand, but in Germany, ATM PINs (and homebanking TAN lists) are sent in special envelopes that you can't see through, even when holding them against a light. That's exactly the sort of distribution method that would be needed for PSKs to have desirable security properties and to make them feasible, and that's exactly the distribution method that Joe's Used Condoms can't use because it's too expensive. Also, it would preclude doing business with someone you don't already know. Also, phishing isn't done on all those thousands of web sites that have successfully employed [passwords] for a decade or more; it's just done on those where there's money to be had. Where it's done, it very often works. How is that a successfuly employed security model? Sarcasm aside for a minute, several people have responded to the PSK thread with the standard passwords don't work, whine moan complain response that security people are expected to give whenever passwords are mentioned. It's all the user's fault, they should learn how to use PKI. I think you're talking about me here, so I think I should clear some things up. First of all, I don't think that users should learn how to use PKI. I don't use PKI (much) because I think it's too bloody complicated, and I am certainly an educated user. I wouldn't dare foist PKI on uneducated users. (There is a great parody by Stenkelfeld, a German radio comedy show, about the difficult HBCI procedure then in use at Haspa, the largest German savings bank. It's in German, but I can get you an MP3 if you want. And there isn't even that much I in HBCI's PKI.) But I'm no expert on PKI, so I asked a question instead, namely whether PKI wasn't going to make it for the web. Second, I also didn't say that passwords didn't *work*, I said that they had *storage and management issues* that certificates did not have and that their deployment would be problematic because of that, and I stand by that. The reason for my opinion has nothing to do with any knee-jerk standard reaction in relation to passwords, except perhaps for the problem of transferring them securely; see above. (I think the problem is real under many threat models; you may disagree.) Rather, it is my impression that a switch to TLS-PSK would not just be a client-side thing, but that server code would have to be changed also, and that it is this issue which will prevent widespread deployment of TLS-PSK. This has nothing to do with what users want or can do, and it has nothing to do with the technical feasibility of passwords. The failing is in the security community. We completely agree. We have failed to produce practical and secure solutions. To repeat, I especially agree that PKI is a solution in search of a problem, and that it's not practical for web commerce. I also agree that password authentication is not inherently poor, and if we could turn the clock back ten years, that's what we should do. I also agree that passord-based authentication was trivial to implement---ten years ago! Today it's not going to be anyway near trivial. Here's my proposal for an unmistakable TLS-PSK based authentication mechanism for a browser: [...] If I were a phisher, I'd set up a web site having normal text boxes for username and password. On it, I'd put a link why isn't the URL bar blue? and use some technical mumbo-jumbo about how for technical reasons, the feature needed to be disabled in the browser, but that the passwords were of course secure (there was a posting on this list to the effect that a bank actually did this or something very similar). Or maybe that this particular browser isn't supported with TLS-PSK (DiBa doesn't support anything but IE, for example, and logins will mysteriously fail if attempted with any other browser). I bet that'd work, no matter how unspoofable the TLS-PSK password entry were. It doesn't solve *all* phishing problems, but it's a darn sight better than the mess we're in now. OK, I'm willing to concede that I probably don't understand many of the issues, technical or otherwise, and that I don't have a solution to offer myself, so I'll shut my trap (except if directly challenged, or in private email) until someone has made a decent try to get browser makers to support both TLS-PSK and to include unspoofable password entry methods. Then we'll see how merchants react to this and what the ultimate consequences are. Fun, Stephan begin:vcard fn:Stephan
Re: Another entry in the internet security hall of shame....
Alaric Dailey wrote: ATMs would be infeasible if they were not a 2 factor authentication system, and every day we see more cracks in the way that system is implemented. Starting with the way the PSKs are shared. http://news.bbc.co.uk/1/hi/technology/4183330.stm ATMs use something you have authentication ... a card with a magstripe that is sent out. There is a 2nd factor, PIN, that is also distributed ... as a countermeasure to lost/stolen cards. note that both credit cards and many debit cards can be used in non-PIN, signature mode (i.e. if the card is lost/stolen, crook may still be able to use it w/o PIN). multi-factor authentication presumes that the different factors are subject to different kinds of vulnerabilities and exploits. PINs are a form of shared-secrets ... security requirements typically mean that there is a unique shared-secret for every environment. the result is vast proliferation of PINs and passwords leading to people writting down their pins passwords (there was some study that claimed 30percent of atm cards have pins written on them). As a result, multi-factor infrastructure is undermined because of shared-secret based environments has led to scores of shared-secrets that people are required to keep track of. http://www.garlic.com/~lynn/subpubkey.html#secrets the short-coming of shared-secret environment, is that a shared-secret can be used for both origination as well as verification (the same value used for authentication can also be used for impersonation), which has led to requirement that there are large number of unique shared-secrets, which has led to the huge proliferation in the number of shared-secrets ... which has also led to underminning principle of multi-factor authentication ... having unique failure modes sorry for that ... I spent some large amount of time producing high availability systems ... where security exploit/vulnerabilities were just another kind of system failure. http://www.garlic.com/~lynn/subtopic.html#hacmp it isn't so much that the key distribution/sharing mechanism is flawed ... it is that there are flaws in shared-secret based infrastructures (including swamping nominal human factors with an impossible number of different things to memorize). The other short-coming in current ATM environment is skimming that can go on at the POS or ATM terminal ... where the attackers can record the card and pin information. This results in both 1) common vulnerability for two factor authentication ... defeating purpose of having multi-factor authentication and 2) that existing technology is quite vulnerable to replay attacks (aka creating copy of magstripe in counterfeit card and being able to reproduce the pin). So fundamental public key operation can address a number of these short-comings w/o resorting to PKI infrastructure and/or changing the key and card distribution operation. 1) upgrade magstripe to hardware token that does digital signature authentication. the digital signature is unique each time and is therefor resistant to existing replay vulnerability, threats and attacks 2) since public key is not a shared-secret based infrastructure ... it is practical to record the same public key in multiple different environments, in theory transitioning to a person-centric environment (from the existing institutional-centric environment). this also is more resistant to data breaches ... since any exposure of the recorded public key can't be used for impersonation. 3) there is still the issue of using a PIN as countermeasure to lost/stolen token ... which is a significantly lower threat compared to crooks being able to harvest tens of thousands or millions of pieces of information for purposes of account fraud (skimming recording devices at ATM POS terminals or data breaches). 4) with hardware token, the PIN can be used directly with the token for token operation ... as opposed to be transmitted and recorded in the infrastructure. That eliminates the PIN as a shared-secret. In theory a person-centric environment can use the same PIN/token with multitude of different infrastructures and/or use the same PIN with multitude of different tokens. This last becomes a trade-off between remembering lots of PINs (and threat of having them written down) vis-a-vis compromise of single PIN can expose several tokens. However, in person-centric environment, it is possible to leave such a threat trade-off decision to the individual. The issue of PKI, certificatin authorities, and digital certificates were that the original digital certificate design point was for first time communication between strangers where the relying party also had not timely, direct (possibly online) access to a trusted party. The digital certificates filled this trust void in a manner siumilar to letters of credit from the sailing ship days. In an environment where relying parties have long-standing and extensive relationship management operations keeping track of large
Re: [Anti-fraud] Re: Another entry in the internet security hall of shame....
Alaric Dailey wrote: Thus ATMs and the weak 2 factor authentication system they use are untrustworthy, I knew that already, but as I said, its better than not having the multifactor authentication. The fact that many cards may be used as credit card and you thus bypass the second factor, is a HUMAN failing, the entity accepting the cards are supposed to check the signature, against a photo id, ESPECIALLY if the card says See ID. But this overabundance of text doesn't solve my problems with the assertion that PSKs are somehow more secure than Public/Private key encryption with a trusted third party as verifier, and specifically the X.509 Certificate Authority System that is the backbone for SSL. This statement is only plausible if you consider the paper cryptography domain. When applied to the business / user world, the statement fails due to the way that real life breaks the assumptions. No one is touching on the key issues sharing of keys securely and how to validate that they haven't been comprimised. Generally, for most apps, there is already a way to share stuff. Just to look at one particular application such as online banking, the bank and the user generally communicate through post and other means such as email at a minimum so as to set up a relationship. These methods may not be secure (according to paper crypto metrics) but they are multi-factor and are uncorrelated with the threats. So they work; so the keys can be shared securely, according to some risk measure. how a user is supposed to keep track of the secure keys (kind of a side point) Software? how the validation of identity of these systems would work Shared keys validate in that they are shared; the keys themselves aren't sent over the wire in the setup, and if the other party doesn't have the key, then the setup fails. This amounts to validation of identity being measured by has a copy of my key too. Now, you'll probably think this is woefully insecure because it falls to MITM. True, but so does most every other system. online browsing fails to MITM by means of phishing in such an evidently purile fashion that heads should be hung with shame .. if not lopped off. Even if the browser were to do more here, the MITM is still possible within the ivory tower of the CA, which have't exactly inspired of late given that they now sell lots and lots of domain-certs for bargain basement prices. ($7 was the latest I saw!) So, in a business context, PSK does identity validation more or less as well as anything else, at least on paper (coz it hasn't been tried yet!). Unless the issues I pointed out are addressed , PSK is a much WORSE solution than trusting a third party for verification of the other entities identity. Especially since you profess that certs are redundant and superfluous standin for the real information, how I am to verify that a given website in Timbucktoo, is owned and operated be the entity making the claim without going there myself, with SSL we have SOME assurance that someone verified it. Not really. With SSL in the browser you have approximately zero assurance that anyone verified it. If you look at the browser, and find a padlock that gives you maybe 5% of what you need. If you go searching into the cert then you might be able to establish the CA which would perhaps give you 5-20% of what you need, but to actually work out whether a website is really the right one, you are going to have to go elsewhere for assurance. Its no different than trusting that the people at the DMV did their jobs when a drivers license was issued, but even drivers licenses aren't acceptable authoritative proof that someone is who they profess to be. Here in Nebraska we have one of the most difficult drivers licenses to forge, so what did the criminals do? they stole the machines, so they could make perfect forgeries. Sure. When it matters, expect phishers to set up SSL sites, to steal domains, to steal email confirmations, to do all sorts of things. Right now, they are dealing with low hanging fruit. Trust must lie somewhere, if you have a structure that gives some assurance of that the entities are who they say they are, that is a world better than lacking those arrurances. No, I'd challenge your underlying assumption here that the intention is to deliver trust. Trust cannot be delivered, it can't be sent, it can't lie anywhere. Trust is something that only each individual can find for themselves on their own checks. Trust never leaves a person. What the system can do is make statements and present evidence. It's up to the user to decide whether to trust those statements and whether to seek further evidence or risk it with what she has. The difference in these two approaches is immense. In your view you have to get it right; except you have no way to establish trust that actually makes sense and hence you're trapped into an ever increasing quality cycle, while the businesses selling that
Re: Another entry in the internet security hall of shame....
On Tue, 30 Aug 2005, Peter Gutmann wrote: - A non-spoofable means of password entry that only applies for TLS-PSK passwords. In other words, something where a fake site can't trick the user into revealing a TLS-PSK key. This sounds like a solution replete with all the problems that passwords have had all along: users choosing bad ones, using the same ones for different sites, never changing them, servers getting hacked (disclosing the probably-shared passwords of thousands of users), etc. ad nauseum... The last threat is particularly pertainent because it appears there is a requirement for servers to retain the PSK in cleartext. (To be fair, the draft does RECOMMENDED that implementations provide a way to generate random PSKs, but this has been recommeded for passwords in general for decades, to little effect.) Given the complete lack of good password management practice in the vast majority of websites, what will make them start doing things right with TLS-PSK? Maybe some of this could be solved with a good UI in the web browser (e.g. by treating the PSK as a key rather than a password), but arm-waving about UI refinements applies to improving certificate handling too. -d - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
James A. Donald wrote: But does not, in fact, prevent. Let me rephrase that. Are we now at a point where we must admit that PKI isn't going to happen for the Web and that we therefore must face the rewriting of an unknown (but presumably large) number of lines of code to accomodate PSKs? If that's so, I believe that PSKs will have deployment problems as large as PKI's that will prevent their widespread acceptance. That's because PSKs (as I have understood them) have storage and management issues that CA certificates don't have, four of which are that there will be a lot more PSKs than CA certificates, that you can't preinstall them in browsers, that the issue of how to exchange PSKs securely in the first place is left as an exercise for the reader (good luck!), and that there is a revocation problem. To resolve any of those issues, code will need to be written, both on the client side and on the server side (except for the secure exchange of PSKs, which is IMHO unresolvable without changes to the business workflow). The client side code is manageable, because the code will be used by many people so that it may be worthwhile to spend the effort. But the server side? There are many more server applications than there are different Web browsers, and each one would have to be changed. At the very least, they'd need an administrative interface to enter and delete PSKs. That means that supporting PSKs is going to cost the businesses money (both to change their code and to change their workflow), money that they'd rather not spend on something that they probably perceive as the customer's (i.e., not their) problem, namely phishing. Some German banks put warnings on their web pages that they'll never ask you for private information such as passwords. SaarLB (http://www.saarlb.de) even urges you to check the certificate fingerprint and provides well-written instructions on how to do that. In return, they'll assume no responsibility if someone phishes your PIN and TANs. They might, out of goodwill, reimburse you. Then again, they might not. I believe that SaarLB could win in court. So where is the incentive for SaarLB to spend the money for PSK support? Fun, Stephan begin:vcard fn:Stephan Neuhaus n:Neuhaus;Stephan org;quoted-printable:Universit=C3=A4t des Saarlandes;Department of Informatics adr;quoted-printable:;;Postfach 15 11 50;Saarbr=C3=BCcken;;66041;Germany email;internet:[EMAIL PROTECTED] title:Researcher tel;work:+49-681/302-64018 tel;fax:+49-681/302-64012 x-mozilla-html:FALSE url:http://www.st.cs.uni-sb.de/~neuhaus version:2.1 end:vcard
Re: Another entry in the internet security hall of shame....
At 9:39 AM +0200 9/1/05, Stephan Neuhaus wrote: Are we now at a point where we must admit that PKI isn't going to happen s/happen/happen in a widely useful fashion/ for the Web s/Web/Web and email/ and that we therefore must face the rewriting of an unknown (but presumably large) number of lines of code to accomodate PSKs? Self-signed certificates that are fingerprinted out-of-band are better than PSKs in some situations, worse in others. If that's so, I believe that PSKs will have deployment problems as large as PKI's that will prevent their widespread acceptance. Bingo. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
If I may inject my humble opinion(that isn't necessarily a response to this peticular email), I may not be as informed as some but While I admit that PKI is flawed, I don't see anyway that PSK could used effectively. How are PSKs going to be shared in a secure way? are we talking about generating a new key for every connection? if so how do you validate the key? if not, how do you validate that the key hasn't been compromised by someone who put up a phishing site? In my opinion, PSK has the same problems as all symmetric encryption, its great if you can share the secret securely, but distribution to the masses makes it infeasible. >From the way I see it, if site logins were done using a client certificate, like the USPS electronic postmark site allows and should enforce, then the security issues wouldn't be issues, as there would be nothing usable handed off to an attacker. Furthermore the site could be sure of the users identity, something none of the other solutions I have seen address. -- Pengdows eMail Signature Alaric Dailey Everyone deserves privacy. Thawte Web of Trust Notary CAcert Web of Trust Assurer Notary Public ATTENTION USERS OF MICROSOFT OUTLOOK AN MICROSOFT OUTLOOK EXPRESS: Some versions of these products have trouble replying to digitally signed emails, like this one. For more information on this error, and how to fix it please visit Mark Nobles website here. Stephan Neuhaus wrote: James A. Donald wrote: But does not, in fact, prevent. Let me rephrase that. Are we now at a point where we must admit that PKI isn't going to happen for the Web and that we therefore must face the rewriting of an unknown (but presumably large) number of lines of code to accomodate PSKs? If that's so, I believe that PSKs will have deployment problems as large as PKI's that will prevent their widespread acceptance. That's because PSKs (as I have understood them) have storage and management issues that CA certificates don't have, four of which are that there will be a lot more PSKs than CA certificates, that you can't preinstall them in browsers, that the issue of how to exchange PSKs securely in the first place is left as an exercise for the reader (good luck!), and that there is a revocation problem. To resolve any of those issues, code will need to be written, both on the client side and on the server side (except for the secure exchange of PSKs, which is IMHO unresolvable without changes to the business workflow). The client side code is manageable, because the code will be used by many people so that it may be worthwhile to spend the effort. But the server side? There are many more server applications than there are different Web browsers, and each one would have to be changed. At the very least, they'd need an administrative interface to enter and delete PSKs. That means that supporting PSKs is going to cost the businesses money (both to change their code and to change their workflow), money that they'd rather not spend on something that they probably perceive as the customer's (i.e., not their) problem, namely phishing. Some German banks put warnings on their web pages that they'll never ask you for private information such as passwords. SaarLB (http://www.saarlb.de) even urges you to check the certificate fingerprint and provides well-written instructions on how to do that. In return, they'll assume no responsibility if someone phishes your PIN and TANs. They might, out of goodwill, reimburse you. Then again, they might not. I believe that SaarLB could win in court. So where is the incentive for SaarLB to spend the money for PSK support? Fun, Stephan smime.p7s Description: S/MIME Cryptographic Signature
Re: Another entry in the internet security hall of shame....
Alaric Dailey wrote: If I may inject my humble opinion(that isn't necessarily a response to this peticular email), I may not be as informed as some but While I admit that PKI is flawed, I don't see anyway that PSK could used effectively. How are PSKs going to be shared in a secure way? are we talking about generating a new key for every connection? if so how do you validate the key? if not, how do you validate that the key hasn't been compromised by someone who put up a phishing site? on the business/server side ... where x.509 identity certificates represent horrible privacy and liability issues ... and they've migrated to relying-party-only certificates http://www.garlic.com/~lynn/subpubkey.html#rpo by definition, the institution needs to have already registered the clients public key ... in order to even issue a relying-party-only certificate ... they client/customers public key has been preshared (otherwise it would have been impossible for the institution to have issued the certifivate). at this point it is trivial to demonstrate that the issuing of the relying-party-only certificate is redundant and superfluous ... since by definition the institution has the PSK. so if you look at existing business process where pre-shared passwords are part of an authentication administration infrastructure that is integrated with the permissions and authorization administrative infrastructure ... say like either radius or kerberos http://www.garlic.com/~lynn/subpubkey.html#radius http://www.garlic.com/~lynn/subpubkey.html#kerberos it is possible to register public keys in place of password, retaining the existing business process and integrated administration of authentication and authorization. one of the issues when we started dealing with this small client/server startup that wanted to do payments on their server platform http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 had this new thing called SSL which were dependent on PKI, certification authorities, and digital certificates. As part of that effort, we had to do various kinds of business process and end-to-end audits of these things called certification authorities. There was a lot of discussion in these audits about certification authorities having very little to do with security and technology ... and primarily involved in a traditional service operation with loads of administrative work. One of the characteristics of businesses that have existing relationship management administrative relationship management operations ... like financial institutions with accounts or business with accounts payable and accounts billable or ISPs ... is that they have tried to provide some amount of administrative scaleup and integrity to the operation. Frequently it is possible to show a trivial toy PKI demo as an add-on w/o impacting the core authentication and authorization business processes. The big expenses quickly dawns on them when it starts to appear that PKI operation might have some impact on real business operations. At that point of time, it becomes quickly apparent that any full-scale PKI authentication infrastructure deployment will have an enormous cost duplication (especially after there has been possibly scores of years developing scaleable and integrated authentication and authorization infrastructures). At that point, the ongoing duplicate PKI operational costs totally dominate ... any trivial software technology deployment issue. Part of the issue is that the promise of having x.509 identity certificates groslly overloaded with enormous amounts of privacy information along with authorization and permissions ... has been shown to be false. That the organization isn't able to use the deployment of a X.509 PKI operation (with the digital certificates containing enormous amounts or privacy and senstive information) to eliminate their existing integrated relationship management and administrative infrastructure costs ... it possible turns out to be possibly doubling the actual business costs (in any sort of full-scale production deployment used for actual business purposes.). It may actually be worse than doubling ... the basic PKI administrative infrastructure may be replicated ... doubling the costs ... however the actual costs may be tripled if the existing production business operation and the replicated PKI administrative operation then has to be kept in sync. From a business/server standpoint ... upgrading an existing integrated authentication/authorization/permission infrastructure to use digital signature authentication with public key registration ... conforms to existing business practices and doesn't introduce duplicate and unnecessary administrative operation. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
James A. Donald wrote: -- From: [EMAIL PROTECTED] (Peter Gutmann) TLS-PSK fixes this problem by providing mutual authentication of client and server as part of the key exchange. Both sides demonstrate proof-of- possession of the password (without actually communicating the password), if either side fails to do this then the TLS handshake fails. Its only downside is that it isn't widely supported yet, it's only just been added to OpenSSL, and who knows when it'll appear in Windows/MSIE, Mozilla, Konqueror, Safari, This will take out 90% of phishing spam, when widely adopted. Having read this now [1] I wonder if it is too hopeful to expect TLS-PKS to be widely adopted in browsing. ( I've guessing that you mean that the user's password and username will be used to bootstrap the secure TLS session - notwithstanding the comment in section 8 that this is not the intention [2]. ) The issue I see here is that while the browser may have access to this data, the server doesn't necessarily have access to it. In these days and times, major websites are constructed with a plethora of methods to do authentication, and they use a lot frameworks to handle all that. In any given framework, the distance (in code and layers and backends) between the TLS code and the password code can be quite large. One artifact of this is the use of straight forms to deliver the password rather than use the inbuilt underlying unix-style password mechanism; it is far too popular to implement the password authentication of a user over the top of any framework as it is - in the application code - as the framework never quite does what is needed. Not only is there this distance, it is duplicated across all languages and all the different auth regimes and also for homegrown password auth, over every application! I'd wonder if given these barriers it will ever be possible to get change to happen? Or have I misunderstood something here? (Note that this shouldn't be interpreted as saying anything about the general utility of TLS-PSK in other environments as per [2]...) iang [1] Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-09.txt [2] However, this draft is not intended for web password authentication, but rather for other uses of TLS. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
On Wed, Aug 31, 2005 at 01:44:25PM +0100, Ian G wrote: Not only is there this distance, it is duplicated across all languages and all the different auth regimes and also for homegrown password auth, over every application! I'd wonder if given these barriers it will ever be possible to get change to happen? At least here, the front-end servers handle a plethora of authentication types including client certificate (so client password in TLS should work too) and the authentication context is then propagated via cookies to the deep stack of applications behind the perimeter servers. This said, indeed this is a challenge. Any site that can get client certs working, can handle variations on the theme, if their authentication happens deep inside the system (say AD Domain controller behind the webservers) it won't work. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
From: -- From: Stephan Neuhaus [EMAIL PROTECTED] If I have understood the draft correctly, using PSKs means that the server and the client have a shared secret that they must communicate securely beforehand, and that they use some form of ZKP to assure the other party that they know that secret without revealing it. If that's indeed so, wouldn't this have key management and storage issues that PK was designed to prevent in the first place? But does not, in fact, prevent. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG 9DcDsP364D9PAHlb9SrTA4By8bWsJWYZxs8ZH9xB 4cQSP1xXUj2reoZ2icPXcJbFjGP6wBWfZQO13feDH - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
James A. Donald [EMAIL PROTECTED] writes: From: [EMAIL PROTECTED] (Peter Gutmann) TLS-PSK fixes this problem by providing mutual authentication of client and server as part of the key exchange. Both sides demonstrate proof-of- possession of the password (without actually communicating the password), if either side fails to do this then the TLS handshake fails. Its only downside is that it isn't widely supported yet, it's only just been added to OpenSSL, and who knows when it'll appear in Windows/MSIE, Mozilla, Konqueror, Safari, This will take out 90% of phishing spam, when widely adopted. And that's it's killer feature: Although you can still be duped into handing out your password to a fake site, you simply cannot connect securely without prior mutual authentication of client and server if TLS-PSK is used. What'd be necessary in conjunction with this is two small changes to the browser UI: - Another type of secure-connect indicator (maybe light blue or light green in the URL bar instead of the current yellow) to show that it's a mutually authenticated connection, along with a Why is this green? tooltip for it. - A non-spoofable means of password entry that only applies for TLS-PSK passwords. In other words, something where a fake site can't trick the user into revealing a TLS-PSK key. Anyone know how to communicate this to the Mozilla guys? The only mechanism I'm aware of is bugzilla, which doesn't seem very useful for this kind of request. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
Peter Gutmann wrote: And that's it's killer feature: Although you can still be duped into handing out your password to a fake site, you simply cannot connect securely without prior mutual authentication of client and server if TLS-PSK is used. If I have understood the draft correctly, using PSKs means that the server and the client have a shared secret that they must communicate securely beforehand, and that they use some form of ZKP to assure the other party that they know that secret without revealing it. If that's indeed so, wouldn't this have key management and storage issues that PK was designed to prevent in the first place? Also, the prior secure exchange of secrets would seem to preclude communication between entities that don't know each other. That, however, is how many businesses (including ebay, in whose name much phishing spam is generated) operate. Additionally, I don't think that this is just a UI issue; after all, both the client and the server must somehow manage the PSKs. There are probably expiration and revocation problems: what if my computer gets stolen and I can't get at my PSK? Does this mean that I can't do business with my bank anymore? What if I suspect that someone has stolen my PSK (for example with the same javascript attack that phished my password)? And so on and so on. I'm not saying that the idea is bad, far from it; I'm just saying that there are probably many practical problems to be solved before this can be widely deployed. Or perhaps I haven't understood the draft correctly. What'd be necessary in conjunction with this is two small changes to the browser UI: ...and the PSK management code in the server and in the client. Fun, Stephan begin:vcard fn:Stephan Neuhaus n:Neuhaus;Stephan org;quoted-printable:Universit=C3=A4t des Saarlandes;Department of Informatics adr;quoted-printable:;;Postfach 15 11 50;Saarbr=C3=BCcken;;66041;Germany email;internet:[EMAIL PROTECTED] title:Researcher tel;work:+49-681/302-64018 tel;fax:+49-681/302-64012 x-mozilla-html:FALSE url:http://www.st.cs.uni-sb.de/~neuhaus version:2.1 end:vcard
Re: Another entry in the internet security hall of shame....
-- From: Dave Howe [EMAIL PROTECTED] 2) Google got into the CA business; namely, all GoogleMail owners suddenly found they could send and receive S/Mime messages from their googlemail accounts, using a certificate that just appeared and was signed by the GoogleMail master cert. Given the GoogleMail user base, this could make GoogleMail a defacto CA in days. 3) This certificate was downloaded to your GoogleTalk client on login, and NEVER cached locally Ok, from a Security Professional's POV this would be a horror - certificates all generated by the CA (with no guarantees they aren't available to third parties) but it *would* bootstrap X509 into common usage, That horse is dead. It is not going into common usage. SSL works in practice, X509 with CA certs does not work in practice. People have been bullied into using it by their browsers, but it does not give the protection intended, because people do what is necessary to avoid being nagged by browsers, not what is necessary to be secure. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG mQ0rM7wYdVTuoeMRUcrpDc1V9pUqhEgUmJMtyCZZ 469u1yKDDCKWaUWwU/LYyE/7CVNRZV7OjXCs+Kyyc - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
Dave Howe [EMAIL PROTECTED] writes: Nicolas Williams wrote: Yes, a challenge-response password authentication protocol, normally subject to off-line dictionary attacks by passive and active attackers can be strengthened by throwing in channel binding to, say, a TLS channel, such that: a) passive attacks are not possible, b) MITMs below TLS get nothing that can be attacked off-line, and c) server impersonators can be detected heuristically when the attacker can't retrieve the password in real-time (such an attack is indistinguishable from password incorrect situations, but...). Indeed. The main problem with TLS is lack of PKI support; in principle, this isn't true - TLS uses X509 certs, just like any other SSL based protocol - but in practice, everyone uses self signed certificates and nobody checks them or even caches them to see if they change. TLS-PSK fixes this problem by providing mutual authentication of client and server as part of the key exchange. Both sides demonstrate proof-of- possession of the password (without actually communicating the password), if either side fails to do this then the TLS handshake fails. Its only downside is that it isn't widely supported yet, it's only just been added to OpenSSL, and who knows when it'll appear in Windows/MSIE, Mozilla, Konqueror, Safari, ... Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
Peter Gutmann wrote: TLS-PSK fixes this problem by providing mutual authentication of client and server as part of the key exchange. Both sides demonstrate proof-of- possession of the password (without actually communicating the password), if either side fails to do this then the TLS handshake fails. Its only downside is that it isn't widely supported yet, it's only just been added to OpenSSL, and who knows when it'll appear in Windows/MSIE, Mozilla, Konqueror, Safari, So, the solution to nobody using the existing (but adequate) solution is another existing (but barely implimented and also unused) solution? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
2005/8/29, Dave Howe [EMAIL PROTECTED]: So, the solution to nobody using the existing (but adequate) solution is another existing (but barely implimented and also unused) solution? I think the good solution is the one chosen by some bank ... : http://news.netcraft.com/archives/2005/08/23/banks_shifting_logins_to_nonssl_pages.html How can they have accepted such a security flow ? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
In listening to this thread hearing all the hyperbole on both sides, I would suggest that we may need more fuel to the fire. There was a rump presentation at the recent Crypto on the use of Ceremonies (which, pardon my misstatement in advance, is claimed to be computer protocols with the humans included). The presentation states, Design a great protocol, prove it secure; add a user, it’s insecure. This specifically discusses SSL. The entire rump session is at http://www.iacr.org/conferences/crypto2005/rumpSchedule.html scroll down to Ceremonies by Carl Ellison The presentation and video http://www.iacr.org/conferences/crypto2005/r/48.ppt http://www.iacr.org/conferences/crypto2005/r/48.mov The video is about 50MB. Thanks jim On Aug 28, 2005, at 10:32 PM, James A. Donald wrote: -- From: Dave Howe [EMAIL PROTECTED] 2) Google got into the CA business; namely, all GoogleMail owners suddenly found they could send and receive S/Mime messages from their googlemail accounts, using a certificate that just appeared and was signed by the GoogleMail master cert. Given the GoogleMail user base, this could make GoogleMail a defacto CA in days. 3) This certificate was downloaded to your GoogleTalk client on login, and NEVER cached locally Ok, from a Security Professional's POV this would be a horror - certificates all generated by the CA (with no guarantees they aren't available to third parties) but it *would* bootstrap X509 into common usage, That horse is dead. It is not going into common usage. SSL works in practice, X509 with CA certs does not work in practice. People have been bullied into using it by their browsers, but it does not give the protection intended, because people do what is necessary to avoid being nagged by browsers, not what is necessary to be secure. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG mQ0rM7wYdVTuoeMRUcrpDc1V9pUqhEgUmJMtyCZZ 469u1yKDDCKWaUWwU/LYyE/7CVNRZV7OjXCs+Kyyc - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
James A. Donald wrote: SSL works in practice, X509 with CA certs does not work in practice. People have been bullied into using it by their browsers, but it does not give the protection intended, because people do what is necessary to avoid being nagged by browsers, not what is necessary to be secure. Indeed so - however, if Google makes it just work then there will be a large swathe of people out there wondering what does this DIGITAL SIGNATURE button do in gmail? plus a smaller subset who have google talk and can perform secure e2e voip using x509 certs that they don't even know they have. Its not ideal, but its not a bad thing either - a little more security, using a known method, without any individual user having to know or care how it works (and lets face facts here, no solution that requires an end user to get his finger out and do something without being forced to, no matter how trivial the task is, ever had a decent update) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
Dave Howe wrote: Indeed so - however, if Google makes it just work then there will be a large swathe of people out there wondering what does this DIGITAL SIGNATURE button do in gmail? plus a smaller subset who have google talk and can perform secure e2e voip using x509 certs that they don't even know they have. Its not ideal, but its not a bad thing either - a little more security, using a known method, without any individual user having to know or care how it works (and lets face facts here, no solution that requires an end user to get his finger out and do something without being forced to, no matter how trivial the task is, ever had a decent update) the major ISPs are already starting to provide a lot of security software to their customers. a very straight forward one would be if they provided public key software ... to (generate if necessary) and register a public key in lieu of password ... and also support the PPP radius option of having digital signature authentication in lieu of password checking http://www.garlic.com/~lynn/subpubkey.html#radius at that point your public key is now registered with your ISP ... and possibly could be used for other things as well ... and scaffolding for a certificateless trust infrastructure. in much the same way i've commented about some of the implications of the SSL certificae industry backing for having onfile public keys in the domain name infrastructure (and anybody being able to do real time retrieval of public key) ... something similar could happen with onfile public keys for general public with their ISP (and possibly allowing real time retrieval of public keys). so it would be convenient if such public keys were then integrated with various client email programs as part of the address book (automatic process for adding email addresses to address book, then possibly also automatically add public key as part of the same address book entry). you could then, at least have a button that would cross-check that the public key that came with the email was the same public key onfile with the sender's ISP. it would still be up to the recipient to provide a mapping/binding between an email address and an entity in the real world (if they so desired). the automatic add to the address book ... can work the same way automatic add to address book works today. part of the issue might be considered separating the trust infrastructure from the standard addressing infrastructure. one of the downsides (compared to some of the downsides in the domain name infrastructure onfile public keys) for the certification authority industry ... is that public keys no longer require independent certification ... they just become part of the general addressing landscape. lots lots of past postings on SSL landscape http://www.garlic.com/~lynn/subpubkey.html#sslcert - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
Anne Lynn Wheeler wrote: the major ISPs are already starting to provide a lot of security software to their customers. a very straight forward one would be if they provided public key software ... to (generate if necessary) and register a public key in lieu of password ... and also support the PPP radius option of having digital signature authentication in lieu of password checking http://www.garlic.com/~lynn/subpubkey.html#radius Right. And do the primary authentication of the key using some other mechanism that is outside the strict crypto. (IOW, Dave, your plan will work, as long as it is built from ground up with no prior baggage! IMHO!) This is such a no-brainer that when I first came across the solution over a decade ago now, I never gave a thought as to how it could be anything but the one way to do things. It just works, and very little else works anywhere as well. Yet, we are still grubbing around like cavemen in the mud. And then there is this: http://www.business2.com/b2/web/articles/print/0,17925,1096807,00.html $5M Mobile ID for Credit Card Purchases WHO: John Occhipinti, Woodside Fund, Redwood Shores, Calif. WHO HE IS: A former executive at Oracle and Netscape, Occhipinti is a managing director and security specialist, leading investments in BorderWare and Tacit. WHAT HE WANTS: Fraudproof credit card authorization via cell phones and PDAs. WHY IT'S SMART: Credit card fraud is more rampant than ever, and consumers aren't the only ones feeling the pain. Last year banks and merchants lost more than $2 billion to fraud. Most of that could be eliminated if they offered two-part authentication with credit and debit purchases -- something akin to using a SecureID code as well as a password to access e-mail. Occhipinti thinks the cell phone, packaged with the right software, presents an ideal solution. Imagine getting a text message on your phone from a merchant, prompting you for a password or code to approve the $100 purchase you just made on your home PC or at the mall. It's an extra step, but one that most consumers would be happy to take to safeguard their privacy. More important, Occhipinti says, big banks would pay dearly to be able to offer the service. It's a killer app no one's touched yet, Occhipinti says, but the technology's within reach. WHAT HE WANTS FROM YOU: A finished prototype application within eight months. I'm looking for the best technologists in security and wireless, the top 2 percent in their industry, Occhipinti says. The team would need to be working with a handful of banks and merchants ready to start trials, in hopes of licensing the technology or selling the company. SEND YOUR PLAN TO: [EMAIL PROTECTED] The funniest part of all is that even though we know how to do it in our sleep, Paypal actually built one as their original offering and threw it away... at that point your public key is now registered with your ISP ... and possibly could be used for other things as well ... and scaffolding for a certificateless trust infrastructure. Yup. But this will only work if you go back to basics and build the structure naturally around the keys. IOW, not using anything from PKI. lots lots of past postings on SSL landscape http://www.garlic.com/~lynn/subpubkey.html#sslcert Watching security thinking advance is like watching primates evolve from close distance. Either we die of old age before anything happens, or we get clubbed to death... iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
I would appreciate your thoughts on WiKID. We use asymmetric keys to encrypt PINs and one-time passcodes between a client and the server. The server talks to various network clients using protocols such as LDAP, Radius, or using our own SSL-tunneled wAuth protocol. We believe that replacing passwords is the right economic model to fund PK deployment widely to consumers. The client can then be extended to provide encryption for apps such as the credit card app described below. We have just released version of WiKID under the GPL. The GPL client uses RSA encryption. The non-GPL version uses Ntru, making it suitable for wireless clients (RSA key gen on a java cell phone is a bitch). We have set up http://www.wikidsystems.net as our open source home page and https://sourceforge.net/projects/wikid-twofactor/ is the sourceforge project page as well - which includes a white paper and documentation. Comments and contributions are much appreciated. tia, Nick Ian G wrote: Anne Lynn Wheeler wrote: the major ISPs are already starting to provide a lot of security software to their customers. a very straight forward one would be if they provided public key software ... to (generate if necessary) and register a public key in lieu of password ... and also support the PPP radius option of having digital signature authentication in lieu of password checking http://www.garlic.com/~lynn/subpubkey.html#radius Right. And do the primary authentication of the key using some other mechanism that is outside the strict crypto. (IOW, Dave, your plan will work, as long as it is built from ground up with no prior baggage! IMHO!) This is such a no-brainer that when I first came across the solution over a decade ago now, I never gave a thought as to how it could be anything but the one way to do things. It just works, and very little else works anywhere as well. Yet, we are still grubbing around like cavemen in the mud. And then there is this: http://www.business2.com/b2/web/articles/print/0,17925,1096807,00.html $5M Mobile ID for Credit Card Purchases WHO: John Occhipinti, Woodside Fund, Redwood Shores, Calif. WHO HE IS: A former executive at Oracle and Netscape, Occhipinti is a managing director and security specialist, leading investments in BorderWare and Tacit. WHAT HE WANTS: Fraudproof credit card authorization via cell phones and PDAs. WHY IT'S SMART: Credit card fraud is more rampant than ever, and consumers aren't the only ones feeling the pain. Last year banks and merchants lost more than $2 billion to fraud. Most of that could be eliminated if they offered two-part authentication with credit and debit purchases -- something akin to using a SecureID code as well as a password to access e-mail. Occhipinti thinks the cell phone, packaged with the right software, presents an ideal solution. Imagine getting a text message on your phone from a merchant, prompting you for a password or code to approve the $100 purchase you just made on your home PC or at the mall. It's an extra step, but one that most consumers would be happy to take to safeguard their privacy. More important, Occhipinti says, big banks would pay dearly to be able to offer the service. It's a killer app no one's touched yet, Occhipinti says, but the technology's within reach. WHAT HE WANTS FROM YOU: A finished prototype application within eight months. I'm looking for the best technologists in security and wireless, the top 2 percent in their industry, Occhipinti says. The team would need to be working with a handful of banks and merchants ready to start trials, in hopes of licensing the technology or selling the company. SEND YOUR PLAN TO: [EMAIL PROTECTED] The funniest part of all is that even though we know how to do it in our sleep, Paypal actually built one as their original offering and threw it away... at that point your public key is now registered with your ISP ... and possibly could be used for other things as well ... and scaffolding for a certificateless trust infrastructure. Yup. But this will only work if you go back to basics and build the structure naturally around the keys. IOW, not using anything from PKI. lots lots of past postings on SSL landscape http://www.garlic.com/~lynn/subpubkey.html#sslcert Watching security thinking advance is like watching primates evolve from close distance. Either we die of old age before anything happens, or we get clubbed to death... iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor - The Cryptography Mailing List Unsubscribe by sending
Re: Another entry in the internet security hall of shame....
-- From: [EMAIL PROTECTED] (Peter Gutmann) TLS-PSK fixes this problem by providing mutual authentication of client and server as part of the key exchange. Both sides demonstrate proof-of- possession of the password (without actually communicating the password), if either side fails to do this then the TLS handshake fails. Its only downside is that it isn't widely supported yet, it's only just been added to OpenSSL, and who knows when it'll appear in Windows/MSIE, Mozilla, Konqueror, Safari, This will take out 90% of phishing spam, when widely adopted. We also need support for measures of key persistance, like trustbar, but there seems to be lot of resistance to this, for no reason I understand. In its current incarnation, trustbar takes up too damn much real estate, and requires too much manual support. We need a less obtrusive key persistance measure. Petname is less obstrusive, and requires less manual support, but still too much. The trustbar logos are the way to go, and logos of about that size are becoming a standard feature of web pages. If it could look as cool as trustbar, while needing even less manual intervention Petname Also petnames need to be linked to favorites. When you are on a site that is on your favorites list, you should see that it is on your favorites list. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG /RwA4zRnu4D2L0mSgGcsMv2Z3UGRcRDZnsqwkzh0 4QVXdCrfQfW0WLkPqTvEk16BxjqokNWgRWZOOTahd - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
Nicolas Williams wrote: Yes, a challenge-response password authentication protocol, normally subject to off-line dictionary attacks by passive and active attackers can be strengthened by throwing in channel binding to, say, a TLS channel, such that: a) passive attacks are not possible, b) MITMs below TLS get nothing that can be attacked off-line, and c) server impersonators can be detected heuristically when the attacker can't retrieve the password in real-time (such an attack is indistinguishable from password incorrect situations, but...). Indeed. The main problem with TLS is lack of PKI support; in principle, this isn't true - TLS uses X509 certs, just like any other SSL based protocol - but in practice, everyone uses self signed certificates and nobody checks them or even caches them to see if they change. So - interesting idea time. what if 1) Talk strongly authenticated *all* connections, even p2p ones, using a GoogleMail master certificate and a Googletalk.Googlemail single-use certificate to authenticate the GoogleMail server. 2) Google got into the CA business; namely, all GoogleMail owners suddenly found they could send and receive S/Mime messages from their googlemail accounts, using a certificate that just appeared and was signed by the GoogleMail master cert. Given the GoogleMail user base, this could make GoogleMail a defacto CA in days. 3) This certificate was downloaded to your GoogleTalk client on login, and NEVER cached locally Ok, from a Security Professional's POV this would be a horror - certificates all generated by the CA (with no guarantees they aren't available to third parties) but it *would* bootstrap X509 into common usage, and takeup of s/mime certificates was always the bottleneck for getting encrypted mail to go mainstream (PGP has the same problem, but in addition has the WoT issues and up to recently actual obtaining of the software to contend with) I can only hope that if this *is* in the gameplan, that the certificates be marked autogenerated so that in the longer term a more conventional, clientside-generated certificate can be used instead. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
Dave Howe [EMAIL PROTECTED] writes: Ian G wrote: none of the above. Using SSL is the wrong tool for the job. For the one task mentioned - transmitting the username/password pair to the server - TLS is completely appropriate. However, hash based verification would seem to be more secure, require no encryption overhead on the channel at all, and really connections and crypto should be primarily P2P (and not server relayed) anyhow. Well, it's still attractive to have channel security in order to prevent hijacking. (Insert usual material about channel bindings here...) -Ekr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: e2e all the way (Re: Another entry in the internet security hall of shame....)
Steven M. Bellovin wrote: Do I support e2e crypto? Of course I do! But the cost -- not the computational cost; the management cost -- is quite high; you need to get authentic public keys for all of your correspondents. That's beyond the ability of most people. I don't think it is that hard to do e2e security. Skype does it. Fully transparently. Really? You know that the public key you're talking to corresponds to a private key held by the person to whom you're talking? Or is there a MITM at Skype which uses a per-user key of its own? yes, this is the optimisation that makes Skype work, it is (probably) vulnerable to an MITM at the center. This is a tradeoff. What it means is that the center can do an active attack. But it can't do a passive attack (this is speculation but it seems reasonable or at least achievable). That's a good deal for users, when you consider their alternative. Fantastic value for money, really, it's really very hard to criticise... Another option: I would prefer ssh style cached keys and warnings if keys later change (opportunistic encryption) to a secure channel to the UTP (MITM as part of the protocol!). Ssh-style is definitely not hard. I mean nothing is easier no doubt than slapping an SSL tunnel over the server mediated IM protocol, The evidence suggests that if you just slap an SSL tunnel in place, you end up with an ongoing mess of key management - ref - what this thread started with from google. If you do the thing properly, and build it opportunistically, with the option of upgrading to signed certs for those that really want that, you can avoid all that. But few do, for some reason, or maybe those successful cases we just never hear about because they work without fuss... When SSL is your hammer, everything gets nailed as a server. Here's the problem for a protocol designer. You want to design a protocol that will work as securely as possible, on a wide range of platforms, over a reasonably long period of time. On this I think we'd all agree. Although I'd also add that it should be economic - if it doesn't deploy then it does not good. What do you do? If you engineer only for e2e security, you end up in a serious human factors trap (cue Why Johnny Can't Encrypt and Simson Garfinkel's dissertation). Instead, I recommend engineering for a hybrid scenario -- add easy-to-use client-to-server security, which solves at least 75% of most people's threats (I suspect it's really more like 90-95%), while leaving room in the protocol for e2e security for people who need it and/or can use it, especially as operating environments change. This is precisely what Jabber has done. It's fascinating that you see this and I wish you'd share the threats you see. I see only node threats, you see only wire threats. Why is this? (I can quote reams and reams of news articles that point to merchant data losses and PC malware and virus attacks... but it would be boring. Just ask Lynn for his feed ...) My view of the p2p threat model: other party - 70% own node- 20% center - 10% To an accuracy of +/- X%. Obviously, the wire threats - that are protected by Jabber's SSL and the like - are in the noise somewhere there (but I expect them to get much more aggressive in the future). Another way of looking at this is to ask what the damage is. If your chat traffic is breached by some random threatening outsider, what does he gain? Nothing, so it doesn't take a PhD to realise nobody's interested. But if your listener is a *related* other party and has your messages, then that's a whole other story... This is why for example the most popular IM security system is the discarded nym. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
Steven M. Bellovin wrote: But this underscores one of my points: communications security is fine, but the real problem is *information* security, which includes the endpoint. (Insert here Gene Spafford's comment about the Internet, park benches, cardboard shacks, and armored cars.) *That* makes much more sense, ignore my earlier email. http://homes.cerias.purdue.edu/~spaf/quotes.html Secure web servers are the equivalent of heavy armored cars. The problem is, they are being used to transfer rolls of coins and checks written in crayon by people on park benches to merchants doing business in cardboard boxes from beneath highway bridges. Further, the roads are subject to random detours, anyone with a screwdriver can control the traffic lights, and there are no police. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
Eric Rescorla wrote: Most chat protocols (and Jabber in particular) are server-oriented protocols. So, the SSL certificate in question isn't that of your buddy but rather of your Jabber server. Adam Back [EMAIL PROTECTED] writes: Thats broken, just like the WAP GAP ... for security you want end2end security, not a secure channel to an UTP (untrusted third party)! Remember that Jabber and similar protocols also trust servers to some extent. Servers store and distribute valuable information like presence data -- it is architecturally hard to do otherwise. That means that you also want to be sure you're talking to the right server (and that the server wants to be sure it is talking to an authenticated client). I agree that you *also* want end to end, such as pgp over Jabber provides. I really wish Gaim supported the pgp over Jabber stuff the way PSI does... Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
Think end-to-end.. Even jabber has a way to encrypt messages end-to-end using user certificates (or PGP). -derek I am aware of Jabbers support for GPG/PGP, but did I miss their support for user certificates? I have seen no indication of such support, what client supports it? Alaric smime.p7s Description: S/MIME Cryptographic Signature
Re: Another entry in the internet security hall of shame....
John Kelsey [EMAIL PROTECTED] writes: Recently, Earthlink's webmail server certificate started showing up as expired. (It obviously expired a long time ago; I suspect someone must have screwed up in changing keys over or something, because the problem wasn't happening up until recently.) This is now the third time in the last few months in which invalid/expired SSL server certs have totally failed to have any effect, at least until a security person noticed that there was a problem. Maybe one of the HCI people reading the list could be persuaded to investigate whether SSL server certs have any real security value and/or what changes to the UI need to be made to make them useful. Alternatively, how long can you get away with a $19.95 cert from Honest Joe's Used Cars and Certificates that expired several years ago? Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
Adam Back wrote: Thats broken, just like the WAP GAP ... for security you want end2end security, not a secure channel to an UTP (untrusted third party)! Well, in the Jabber/XMPP world you can run your own server (just as you can in the email world). I see no harm in e2m channel encryption in that (or any other) case if you've got a client-server architecture. Granted, e2e security is also desirable. Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml smime.p7s Description: S/MIME Cryptographic Signature
Re: Another entry in the internet security hall of shame....
Alaric Dailey wrote: I am aware of Jabbers support for GPG/PGP, but did I miss their support for user certificates? I have seen no indication of such support, what client supports it? RFC 3923. But no clients support that yet to my knowledge. Peter smime.p7s Description: S/MIME Cryptographic Signature
Re: Another entry in the internet security hall of shame....
- Original Message - From: Perry E. Metzger [EMAIL PROTECTED] To: Adam Back [EMAIL PROTECTED] Cc: Peter Saint-Andre [EMAIL PROTECTED]; cryptography@metzdowd.com Sent: Friday, August 26, 2005 8:55 PM Subject: Re: Another entry in the internet security hall of shame [...] Remember that Jabber and similar protocols also trust servers to some extent. Servers store and distribute valuable information like presence data -- it is architecturally hard to do otherwise. Well, not really: the buddies on the list can be located through a Distributed Hash Table such as Kademlia, and, once their IP addresses are known, their presence can be checked by ping/pong exchange of UDP packets every few seconds. The biggest problem is represented by NATs, but there are techniques that can alleviate it (hole punching or, in stubborn cases, relaying through non-NATted nodes). I agree that you *also* want end to end, such as pgp over Jabber provides. I really wish Gaim supported the pgp over Jabber stuff the way PSI does... Why not get OTR then? http://www.cypherpunks.ca/otr/ Enzo - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
In message [EMAIL PROTECTED], Adam Back writes: Thats broken, just like the WAP GAP ... for security you want end2end security, not a secure channel to an UTP (untrusted third party)! What is security? What are you trying to protect, and against whom? I use Jabber extensively, and I utterly rely on the SSL encryption to the server. I sometimes use end-to-end GPG encryption, but only when I need to discuss something very private. In general, I don't bother, because of my threat model. The biggest threat I face, in many situations, is people eavesdropping on my wireless link, or playing ARP-spoofing games on my wired link. SSL to the server combats that nicely. (I run psi, because it's the only open-source client I've found that actually checks the server's certificate against a pre-configured list. I have no idea what the default list is, since I just replace it with my own...) I'm not particularly worried about the server end. I and most of my Jabber correspondents use one of about four different Jabber servers. I run one myself; the other three are also very tightly administered. Sure, there could be a problem with any of them; given how bad typical endpoints are today, I'd guess that the servers are actually safer. I'm not even slightly worried about eavesdropping on the backbone. I assume NSA can do that if they really want to. But I *know* that it's hard enough that they're not going to waste their time without a reason, and I doubt if my IM conversations are high enough on their list. (They're pretty boring, as a rule...) I'm much more worried about implementation bugs. A previous version of psi had the bad habit of silently falling back to unencrypted mode if it couldn't find the local crypto library, and due to some glitches in my environment this could happen fairly easily. I was forced to resort to firewalling the unencrypted port on my machines... (The implementation has since been changed to make that failure much less likely.) If you don't trust your (or your correspondents') IM servers, it may be a different situation. I haven't read Google's privacy policies for IM; if it's anything like gmail, they're using automated tools that look at your messages and add to your behavioral profile. As Peter said, though, you can always run your own server or find one that you do trust. The protocol itself is quite nice, and was designed with due attention to privacy. (Aside: the Jabber RFCs were some of the best I dealt with while I was Security AD. They were remarkably easy to read, given their length and the complexity of the protocol.) Do I support e2e crypto? Of course I do! But the cost -- not the computational cost; the management cost -- is quite high; you need to get authentic public keys for all of your correspondents. That's beyond the ability of most people. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
e2e all the way (Re: Another entry in the internet security hall of shame....)
On Fri, Aug 26, 2005 at 11:41:42AM -0400, Steven M. Bellovin wrote: In message [EMAIL PROTECTED], Adam Back writes: Thats broken, just like the WAP GAP ... for security you want end2end security, not a secure channel to an UTP (untrusted third party)! What is security? What are you trying to protect, and against whom? Well I think security in IM, as in all comms security, means security such that only my intended recipients can read the traffic. (aka e2e security). I don't think the fact that you personally don't care about the confidentiality of your IM messages should argue for not doing it. Fair enough you don't need it personally but it is still the correct security model. Some people and businesses do need e2e security. (It wasn't quite clear, you mention you advised jabber; if you advised jabber to skip e2e security because its too hard... bad call I'd say). Do I support e2e crypto? Of course I do! But the cost -- not the computational cost; the management cost -- is quite high; you need to get authentic public keys for all of your correspondents. That's beyond the ability of most people. I don't think it is that hard to do e2e security. Skype does it. Fully transparently. Another option: I would prefer ssh style cached keys and warnings if keys later change (opportunistic encryption) to a secure channel to the UTP (MITM as part of the protocol!). Ssh-style is definitely not hard. I mean nothing is easier no doubt than slapping an SSL tunnel over the server mediated IM protocol, but if the security experts are arguing for the easy way out, what hope is there. I'm more used to having to argue with application functionality focussed people that they need to do it properly -- not with crypto people. I do think we have a duty in the crypto community to be advocates for truly secure systems. We are building piecemeal the defacto privacy landscape of the future; as everything moves to the internet. Take another example... the dismal state of VOIP security. I saw similar arguments on the p2p-hackers list a few days ago about security of p2p voip: who cares about voice privacy etc. Adam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
periodically, some of the PKI related comments remind me of some stories about power production from the 70s. some of the '70s energy stories focused on the different quality of support for power generation technologies based on whether they were institutional centric (and would be able to charge for delivery) vis-a-vis individual oriented generation technologies (even when they involved identical/same/similar solar, wind, etc energy sources). one of the issues from the energy stories of the 70s was that institutional centric solutions frequently collected a lot more backing because proponents were willing to put the effort into the activity in anticipation of revenue flows. however, there are sometimes significant differences between the PKI institutional centric operations and institutional power generation operations. The power being generated (and delivered) tends to be relatively standard and individuals may view it a reasonable trade-off to have it supported by large institution rather than being responsible for their own power generation installations. There tends to be a much larger variation in the types of things which PKI relying-parties are interested in haved certified by some PKI certification authority (somewhat different from bland uniform power production operation). Furthermore, PKI relying-parties frequently may still operate a significant relationship management infrastructure of their own ... where the information being certified by a trusted 3rd-party certification authority represents a tiny fraction of the information that a production relying party will be keeping. In these situations, once a relying-party has to operate their own relationahip management infrastructure of any significance, then the benefit of any certification added value by a trusted 3rd-party certification authority becomes marginal at best. Once a relying-party is operating any significant relationship management infrastructure of their own, any certification done by some 3rd party certification authority frequently becomes redundant and superfluous. It then follows, if the certification by some 3rd party certification authority becomes redundant and superfluous, the associaed digital certificate (representing that certification operation) then also becomes redundant and superfluous. A trivial example in p2p ... is an individual doesn't necessarily know that the presentation of a John Smith x.509 identity certificate in any way corresponds to a specific John Smith that the relying-party individual is familiar with. They are frequently going to still rely on some locally maintained repository as well as additional out-of-band and/or other communication processes. Once they have done that ... then the incrmeental effort to also include the other individual's public key becomes trivial (at least from a high-level business process and information theory standpoint). This, in turn, renders any added value from a trusted 3rd party certificate authority (and their digital certificaes) marginal at best. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
On 8/26/05, Steven M. Bellovin [EMAIL PROTECTED] wrote: ... If you don't trust your (or your correspondents') IM servers, it may be a different situation. I haven't read Google's privacy policies for IM; if it's anything like gmail, they're using automated tools that look at your messages and add to your behavioral profile. As Peter said, though, you can always run your own server or find one that you do trust. Got a nice little surprise yesterday when I [ge]mailed someone, and moments later gaim beeps at me. Checking gaim, I see that suddenly these users had been added to my gaim/gtalk buddies list without my intervention. Grr Anyway, I wouldn't be the least bit surprised if somewhere down the road a folder called archived gtalk shows up in gmail where you can search through all your old conversations. CK -- GDB has a 'break' feature; why doesn't it have 'fix' too? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
Enzo Michelangeli wrote: Remember that Jabber and similar protocols also trust servers to some extent. Servers store and distribute valuable information like presence data -- it is architecturally hard to do otherwise. Well, not really: the buddies on the list can be located through a Distributed Hash Table such as Kademlia, and, once their IP addresses are known, their presence can be checked by ping/pong exchange of UDP packets every few seconds. The biggest problem is represented by NATs, but there are techniques that can alleviate it (hole punching or, in stubborn cases, relaying through non-NATted nodes). We don't expose IP addresses in XMPP, instead we use logical addresses managed by servers. That's a different approach from what you've described, but of course you're free to build an alternative presence and messaging protocol and network if you'd like. :-) I agree that you *also* want end to end, such as pgp over Jabber provides. I really wish Gaim supported the pgp over Jabber stuff the way PSI does... Why not get OTR then? http://www.cypherpunks.ca/otr/ OTR encrypts only the message text, but XMPP can be used to send all sorts of interesting XML traffic (such as SOAP, XML-RPC, etc.) in addition to simple IM. So we want to encrypt more than what in XMPP is the XML character data of the body/ child of the top-level message stanza. RFC 3923 enables XMPP implementations to encrypt the entire XML stanza, but no one has implemented that yet and it doesn't support perfect forward security etc. Another possible approach being discussed is here: http://www.jabber.org/jeps/jep-0116.html Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml smime.p7s Description: S/MIME Cryptographic Signature
Re: e2e all the way (Re: Another entry in the internet security hall of shame....)
Adam Back wrote: Well I think security in IM, as in all comms security, means security such that only my intended recipients can read the traffic. (aka e2e security). I don't think the fact that you personally don't care about the confidentiality of your IM messages should argue for not doing it. Fair enough you don't need it personally but it is still the correct security model. Some people and businesses do need e2e security. (It wasn't quite clear, you mention you advised jabber; if you advised jabber to skip e2e security because its too hard... bad call I'd say). No one advised any such thing, and e2e was a requirement addressed within the IETF by the XMPP WG, resulting in RFC 3923. Peter smime.p7s Description: S/MIME Cryptographic Signature
Re: Another entry in the internet security hall of shame....
In message [EMAIL PROTECTED], Chris Kuethe writes: On 8/26/05, Steven M. Bellovin [EMAIL PROTECTED] wrote: ... If you don't trust your (or your correspondents') IM servers, it may be a different situation. I haven't read Google's privacy policies for IM; if it's anything like gmail, they're using automated tools that look at your messages and add to your behavioral profile. As Peter said, though, you can always run your own server or find one that you do trust. Got a nice little surprise yesterday when I [ge]mailed someone, and moments later gaim beeps at me. Checking gaim, I see that suddenly these users had been added to my gaim/gtalk buddies list without my intervention. Grr Yup -- documented in the Googletalk pages. Anyway, I wouldn't be the least bit surprised if somewhere down the road a folder called archived gtalk shows up in gmail where you can search through all your old conversations. That wouldn't be a surprise at all -- a number of IM programs, including at least Gabber and Psi, keep local logs. Given Google's core competency of retaining searchable data, one would expect them to do that. But this underscores one of my points: communications security is fine, but the real problem is *information* security, which includes the endpoint. (Insert here Gene Spafford's comment about the Internet, park benches, cardboard shacks, and armored cars.) --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: e2e all the way (Re: Another entry in the internet security hall of shame....)
In message [EMAIL PROTECTED], Adam Back writes: On Fri, Aug 26, 2005 at 11:41:42AM -0400, Steven M. Bellovin wrote: In message [EMAIL PROTECTED], Adam Back writes: Thats broken, just like the WAP GAP ... for security you want end2end security, not a secure channel to an UTP (untrusted third party)! What is security? What are you trying to protect, and against whom? Well I think security in IM, as in all comms security, means security such that only my intended recipients can read the traffic. (aka e2e security). I don't think the fact that you personally don't care about the confidentiality of your IM messages should argue for not doing it. Fair enough you don't need it personally but it is still the correct security model. Some people and businesses do need e2e security. (It wasn't quite clear, you mention you advised jabber; if you advised jabber to skip e2e security because its too hard... bad call I'd say). On the contrary -- I did say that I support and use e2e security. I simply said that user-to-server security solves a lot of many -- most? -- people's security needs. Do I support e2e crypto? Of course I do! But the cost -- not the computational cost; the management cost -- is quite high; you need to get authentic public keys for all of your correspondents. That's beyond the ability of most people. I don't think it is that hard to do e2e security. Skype does it. Fully transparently. Really? You know that the public key you're talking to corresponds to a private key held by the person to whom you're talking? Or is there a MITM at Skype which uses a per-user key of its own? Another option: I would prefer ssh style cached keys and warnings if keys later change (opportunistic encryption) to a secure channel to the UTP (MITM as part of the protocol!). Ssh-style is definitely not hard. I mean nothing is easier no doubt than slapping an SSL tunnel over the server mediated IM protocol, but if the security experts are arguing for the easy way out, what hope is there. I'm more used to having to argue with application functionality focussed people that they need to do it properly -- not with crypto people. I'm not arguing for the easy way out; I'm saying that security is an engineering matter, and that there are tradeoffs, including in the human factors. People who click yes to every download aren't going to understand when to accept a key change notice. Btw, I regularly use 3 different machines when talking to my Jabber server. Is your client going to cache all 3 keys for me? Will all of my correspondents know when to click yes and when not to? My son sometimes uses AIM from public web browsers. What then? I'm sure you're itching to type that my keying material should be on a smart card of some sort, so that I could carry it with me and use the same key from any machine I choose. If so, you'd be 100% right. I'll note that for about 99.99% of people, that's just not feasible; they don't have a smart card and their OS doesn't have an interface that makes it easy to do the right thing. Heck, I don't have a smart card; I don't even know of any smart card readers that talk properly to NetBSD, my OS of choice. Here's the problem for a protocol designer. You want to design a protocol that will work as securely as possible, on a wide range of platforms, over a reasonably long period of time. What do you do? If you engineer only for e2e security, you end up in a serious human factors trap (cue Why Johnny Can't Encrypt and Simson Garfinkel's dissertation). Instead, I recommend engineering for a hybrid scenario -- add easy-to-use client-to-server security, which solves at least 75% of most people's threats (I suspect it's really more like 90-95%), while leaving room in the protocol for e2e security for people who need it and/or can use it, especially as operating environments change. This is precisely what Jabber has done. To sum it up in one sentence: design for the future *and* the present. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
Ian G wrote: none of the above. Using SSL is the wrong tool for the job. For the one task mentioned - transmitting the username/password pair to the server - TLS is completely appropriate. However, hash based verification would seem to be more secure, require no encryption overhead on the channel at all, and really connections and crypto should be primarily P2P (and not server relayed) anyhow. It's a chat message - it should be encrypted end to end, using either OpenPGP or something like OTR. And even then, you've only covered about 10% of the threat model - the server. yeah. you have a unencrypted interchange point - the server. There are aspects to that which make it both a good and bad thing, mostly bad. for example you allow interception at the server (may be a requirement for an american based company, but still bad), and you provide a single point of failure for hackers (very bad) Most of the good aspects revolve around only having to support one client cert you can embed in your own client (or make available on your website) and not an entire PKI infrastructure. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Another entry in the internet security hall of shame....
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Peter Saint-Andre Sent: Wednesday, August 24, 2005 4:56 PM To: cryptography@metzdowd.com Subject: Re: Another entry in the internet security hall of shame Tim Dierks wrote: [resending due to e-mail address / cryptography list membership issue] On 8/24/05, Ian G [EMAIL PROTECTED] wrote: Once you've configured iChat to connect to the Google Talk service, you may receive a warning message that states your username and password will be transferred insecurely. This error message is incorrect; your username and password will be safely transferred. iChat pops up the warning dialog whenever the password is sent to the server, rather than used in a hash-based authentication protocol. However, it warns even if the password is transmitted over an authenticated SSL connection. I'll leave it to you to decide if this is: - an iChat bug - a Google security problem - in need of better documentation - all of the above - none of the above It seems Google is assuming that SASL PLAIN is acceptable once you've completed STARTTLS on port 5222 (or if you've connected via SSL on the old-style port 5223). Decide for yourself if that's secure and whether the iChat warning is justified. Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml Ironically, Peter's message above kicked off warning dialogs from MS Outlook, since it was signed using a keypair signed with Peter's own self-signed root, which was not in MSO's list of trusted roots. Self-signed certs are only useful for showing that a given set of messages are from the same source - they don't provide any trustworthy information as to the binding of that source to anything. Peter Trei (not digitally signed, and not pretending to be) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
On 8/25/05, Trei, Peter [EMAIL PROTECTED] wrote: Self-signed certs are only useful for showing that a given set of messages are from the same source - they don't provide any trustworthy information as to the binding of that source to anything. Which is just fine. Pseudonymity is good. If, hypothetically, I were interested in writing and distributing cypto source code which skated right at the edge of current US export regs, I might want to let users verify that the updates came from the same source as the original, without giving them or any gov't busybodies the ability to trace the code back to me. -- There are no bad teachers, only defective children. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Another entry in the internet security hall of shame....
At 9:42 AM -0400 8/25/05, Trei, Peter wrote: Self-signed certs are only useful for showing that a given set of messages are from the same source - they don't provide any trustworthy information as to the binding of that source to anything. Oddly enough, the same could be said for a hierarchically signed certificate. ;-) Cheers, RAH -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
Trei, Peter wrote: Ironically, Peter's message above kicked off warning dialogs from MS Outlook, since it was signed using a keypair signed with Peter's own self-signed root, which was not in MSO's list of trusted roots. You may trust CAcert's root more or less than a root that is trusted by Microsoft. Personally, I find CAcert to be an interesting experiment in webs of trust. Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml smime.p7s Description: S/MIME Cryptographic Signature
Re: Another entry in the internet security hall of shame....
Trei, Peter wrote: Self-signed certs are only useful for showing that a given set of messages are from the same source - they don't provide any trustworthy information as to the binding of that source to anything. Perfectly acceptable over chat, no? That is, who else would you ask to confirm that your chatting to your buddy? iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
Tim Dierks wrote: [resending due to e-mail address / cryptography list membership issue] On 8/24/05, Ian G [EMAIL PROTECTED] wrote: Once you've configured iChat to connect to the Google Talk service, you may receive a warning message that states your username and password will be transferred insecurely. This error message is incorrect; your username and password will be safely transferred. iChat pops up the warning dialog whenever the password is sent to the server, rather than used in a hash-based authentication protocol. However, it warns even if the password is transmitted over an authenticated SSL connection. I'll leave it to you to decide if this is: - an iChat bug - a Google security problem - in need of better documentation - all of the above - none of the above none of the above. Using SSL is the wrong tool for the job. It's a chat message - it should be encrypted end to end, using either OpenPGP or something like OTR. And even then, you've only covered about 10% of the threat model - the server. But, if people do use the wrong tool for the job, they will strike these issues... iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
Ian G [EMAIL PROTECTED] writes: Trei, Peter wrote: Self-signed certs are only useful for showing that a given set of messages are from the same source - they don't provide any trustworthy information as to the binding of that source to anything. Perfectly acceptable over chat, no? That is, who else would you ask to confirm that your chatting to your buddy? Most chat protocols (and Jabber in particular) are server-oriented protocols. So, the SSL certificate in question isn't that of your buddy but rather of your Jabber server. -Ekr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
In another routine event in the adventure known as getting security to work in spite of the security, I just received this ... [fwd] When creating a google talk compatible IM personality in Apple's iChat you get the following warning on the Google Help pages: -=-=- 12. Check the boxes next to 'Connect using SSL' and 'Allow self-signed certificates.' You don't need to check the box next to 'Warn before password is sent insecurely' -- your password is always secure with Google Talk. Congratulations! You are now ready to connect to the Google Talk service using iChat. Once you've configured iChat to connect to the Google Talk service, you may receive a warning message that states your username and password will be transferred insecurely. This error message is incorrect; your username and password will be safely transferred. -=-=- hmm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
Quoting Ian G [EMAIL PROTECTED]: Once you've configured iChat to connect to the Google Talk service, you may receive a warning message that states your username and password will be transferred insecurely. This error message is incorrect; your username and password will be safely transferred. -=-=- hmm Also noted in Psi. Google's instructions for Psi say to leave Use SSL encryption and Allow Plaintext Login unchecked, but both need to be checked for me to successfully login. I'm guessing Google is counting on the SSL tunnel to protect the plaintext logins. -- Roy M. Silvernail is [EMAIL PROTECTED], and you're not It's just this little chromium switch, here. - TFT SpamAssassin-procmail-/dev/null-bliss http://www.rant-central.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
[resending due to e-mail address / cryptography list membership issue] On 8/24/05, Ian G [EMAIL PROTECTED] wrote: Once you've configured iChat to connect to the Google Talk service, you may receive a warning message that states your username and password will be transferred insecurely. This error message is incorrect; your username and password will be safely transferred. iChat pops up the warning dialog whenever the password is sent to the server, rather than used in a hash-based authentication protocol. However, it warns even if the password is transmitted over an authenticated SSL connection. I'll leave it to you to decide if this is: - an iChat bug - a Google security problem - in need of better documentation - all of the above - none of the above - Tim - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
Tim Dierks wrote: [resending due to e-mail address / cryptography list membership issue] On 8/24/05, Ian G [EMAIL PROTECTED] wrote: Once you've configured iChat to connect to the Google Talk service, you may receive a warning message that states your username and password will be transferred insecurely. This error message is incorrect; your username and password will be safely transferred. iChat pops up the warning dialog whenever the password is sent to the server, rather than used in a hash-based authentication protocol. However, it warns even if the password is transmitted over an authenticated SSL connection. I'll leave it to you to decide if this is: - an iChat bug - a Google security problem - in need of better documentation - all of the above - none of the above - Tim Judging by the log (captured using Trillian), google talk is using TLS, thus the Legacy SSL support isn't there, but plain text authentication is ok [14:23] *** Creating connection [EMAIL PROTECTED]/Trillian [14:23] *** Server supports TLS encryption... [14:23] *** Negotiating XMPP SSL connection... [14:23] *** Connection established using EDH-RSA-DES-CBC3-SHA (TLSv1/SSLv3) [14:24] *** Attempting to authenticate using PLAIN [14:24] *** Authenticated. [14:24] *** You have successfully connected to Jabber. smime.p7s Description: S/MIME Cryptographic Signature
Re: Another entry in the internet security hall of shame....
Tim Dierks wrote: [resending due to e-mail address / cryptography list membership issue] On 8/24/05, Ian G [EMAIL PROTECTED] wrote: Once you've configured iChat to connect to the Google Talk service, you may receive a warning message that states your username and password will be transferred insecurely. This error message is incorrect; your username and password will be safely transferred. iChat pops up the warning dialog whenever the password is sent to the server, rather than used in a hash-based authentication protocol. However, it warns even if the password is transmitted over an authenticated SSL connection. I'll leave it to you to decide if this is: - an iChat bug - a Google security problem - in need of better documentation - all of the above - none of the above It seems Google is assuming that SASL PLAIN is acceptable once you've completed STARTTLS on port 5222 (or if you've connected via SSL on the old-style port 5223). Decide for yourself if that's secure and whether the iChat warning is justified. Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml smime.p7s Description: S/MIME Cryptographic Signature
Another entry in the internet security hall of shame....
Guys, Recently, Earthlink's webmail server certificate started showing up as expired. (It obviously expired a long time ago; I suspect someone must have screwed up in changing keys over or something, because the problem wasn't happening up until recently.) So, I contacted Earthlink's technical support, and I got this really encouraging reply / Dear John Kelsey, Thank you for contacting us. I understand that you are having problems viewing Webmail and that it send out an error on SSL certificate. I suggest that you try lowering the security settings of your Internet Explorer. Please follow the steps below on how to lower the security settings on your Internet Explorer. 1. Open Internet Explorer. 2. On the Task panel click on Internet Options. 3. Click on the Advance Tab. 4. Scroll down and uncheck [Warn about invalid site certificates]. 5. Remember to click on Apply. 6. Click on OK. You have successfully lower your Internet Explorer settings. Should you have any other concerns, please get back to us. You will receive a prompt reply. Sincerely, Therese B. 3613 EarthLink Electronic Customer Support EarthLink, Inc. Case ID 69080634 Looking for easy access to news, stocks, sports, and your favorite links? With the EarthLink Personal Start Page you can customize everything from the background colors to your local weather. For more information please visit http://start.earthlink.net Resolve your customer service questions on-line at our Account maintenance web site. To add email mailboxes, change passwords, or update your credit card information, go to: http://myaccount.earthlink.net You can also trade real-time messages with one of our friendly Live Chat representatives: http://support.earthlink.net/chat Or email us and get a response that day: http://support.earthlink.net/email Original Message Follows: - * Presented Article: 142454 * Name: John Kelsey * Email: [EMAIL PROTECTED] * Account Type: EarthLink Experience * Issue: Spam/Internet Fraud Problem * Detailed Issue: Report an Issue * Article Title: Protecting Yourself Against Email/Internet Fraud * Message Body: The SSL certificate for webmail.earthlink.net is expired. The webmail.atl.earthlink.net certificate is fine, it's just the webmail.earthlink.net certificate. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
