Re: New toy: SSLbar
Adam Fields said: On Fri, Jun 27, 2003 at 12:56:24AM +1000, Mister Lee wrote: Regarding the usefulness of SSLbar itself, its immediate purpose was fingerprint display, as a (theoretically) easy means of checking a cert't validity yourself, ... Maybe this is a stupid question, but exactly how are you supposed to use this information to verify a cert? I've done an informal survey of a few financial institutions whose sites use SSL, and the number of them that were able to provide me with a fingerprint over the phone was exactly zero. If you can't get/verify the fingerprint at least once via another channel, you can't use SSLbar to verify the cert. About the best you can do is ensure that you're seeing the same fingerprint every time you visit the site. Some commercial CAs (eg: Verisign) allow you to look up a cert that they issued. Say I want to verify e-gold's cert (and I trust Verisign), I can do the following: - Go to https://digitalid.verisign.com/services/server/search.htm and search for www.e-gold.com. - Click the link for e-gold's valid cert to view the details. - Annoyingly, they don't show the SHA1/MD5 fingerprints, but they do show the certificate details, so... - Go to the e-gold site, and view the cert properties via the usual click-the-little-padlock method. - Verify the name, subject, serial number etc. against what was shown on Verisign's site. - Make a note of the cert fingerprints. - Next time you visit the site you can use SSLbar to check the cert fingerprint against your records. Makes me think I should add a view cert button to SSLbar, plus maybe an option to show the serial number in addition to SHA1 and MD5 fingerprints... ML - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New toy: SSLbar
-- On 2 Jul 2003 at 6:04, [EMAIL PROTECTED] wrote: If you can't get/verify the fingerprint at least once via another channel, you can't use SSLbar to verify the cert. About the best you can do is ensure that you're seeing the same fingerprint every time you visit the site. In practice, if people were able to ensure they saw the same cert every time they hit what is purportedly the same site, this would take out most scams. Unfortunately, no one is going to memorize fingerprints. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG /3xr3PRIl9VwhL3ZVdM2Y6VIS/bUwun0l+Sxa7y8 4q6X4YQoXr6QwwvNJ6wKw/ZRgH6Ssp7tpPgQD6rW/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New toy: SSLbar
On Wed, Jul 02, 2003 at 11:05:08AM -0700, James A. Donald wrote: In practice, if people were able to ensure they saw the same cert every time they hit what is purportedly the same site, this would take out most scams. What's wrong with the ssh known-hosts approach, for this? Do sites change certs more often than sshd changes host keys? Given how much crap browsers cache already, this wouldn't seem to add much. Of course it wouldn't help when using a public client host, but anybody doing that for confidential web access is wide open anyway. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New toy: SSLbar
On Fri, Jun 27, 2003 at 12:56:24AM +1000, Mister Lee wrote: Regarding the usefulness of SSLbar itself, its immediate purpose was fingerprint display, as a (theoretically) easy means of checking a cert's validity yourself, rather than relying on a third party signing. That list of officially sanctioned CAs that comes with browsers just keeps getting longer and longer. I don't know who the hell any of those organizations are, or what their policies are... Anyway, SSLbar could be made much more useful if I were to have it (somehow) cache fingerprints or certs, and a flag to indicate whether the user has validated them. Implementing this requires further investigation however, and I've just been pointed at this list and it's archive, so I have some more reading to do :) Maybe this is a stupid question, but exactly how are you supposed to use this information to verify a cert? I've done an informal survey of a few financial institutions whose sites use SSL, and the number of them that were able to provide me with a fingerprint over the phone was exactly zero. -- - Adam - Adam Fields, Managing Partner, [EMAIL PROTECTED] Surgam, Inc. is a technology consulting firm with strong background in delivering scalable and robust enterprise web and IT applications. http://www.adamfields.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New toy: SSLbar
Steven M. Bellovin wrote: Please don't take this personally... None taken here either, and I'm the author :) From a security point of view, why should anyone download any plug-in from an unknown party? In this very specific case, why should someone download a a plug-in that by its own description is playing around in the crypto arena. They probably shouldn't. Unless they've conversed with me at length and decided that I'm nice, or they download the JAR and vet the code themselves. IMO this is just something that takes time. If I work on SSLbar (or other plugins) long enough, and they get used, I cease to be an unknown party... It'd probably help if I signed the thing, too :) How do we know it's not going to steal keys? Is the Mozilla API strong enough that it can't possibly do that? Presumably it is strong enough to stop that, but I haven't pushed it yet (you're talking about personal certs installed in Mozilla, yes?). Is it implemented well enough that we trust it? (I see that in this case, the guts of the plug-in are in Javascript. Given how often Javascript has played a starring role in assorted security flaws, that doesn't reassure me. But I do appreciate open source.) Security problems with JavaScript are directly related of the context (or lack thereof) in which the code is run. The entire UI of Mozilla is actually bolted together with JavaScript, including the existing SSL certificate properties pages. Unzip the pippki.jar file in your mozilla/chrome directory and take a look at content/pippki/viewCertDetails.js and viewCertDetails.xul - this is code for viewing certs that comes with Mozilla. As far as I am aware, you can't access any of the juicy stuff from within eg: a web page, only from within toolbars and other UI overlays. Regarding the usefulness of SSLbar itself, its immediate purpose was fingerprint display, as a (theoretically) easy means of checking a cert's validity yourself, rather than relying on a third party signing. That list of officially sanctioned CAs that comes with browsers just keeps getting longer and longer. I don't know who the hell any of those organizations are, or what their policies are... Anyway, SSLbar could be made much more useful if I were to have it (somehow) cache fingerprints or certs, and a flag to indicate whether the user has validated them. Implementing this requires further investigation however, and I've just been pointed at this list and it's archive, so I have some more reading to do :) Regards, ML - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New toy: SSLbar
Steven M. Bellovin wrote: From a security point of view, why should anyone download any plug-in from an unknown party? In this very specific case, why should someone download a a plug-in that by its own description is playing around in the crypto arena. I think this is a problem for all open source projects. Suppose I wrote a trojan open source product. Although the code is open for review, how many people actually do review it? I could list the product on Freshmeat, and if it looked like an exciting piece of technology, quite a few people might download it. Probably quite soon someone will find the back door, the story would probably be reported on sites like Slashdot, and the game would be up. However, I could have done a lot of harm in the meantime. The other approach would be to contribute trojan code to another open source product. I don't personally think that there is any of SCO's IP in the Linux kernel, but SCO's story isn't completely implausible. A rogue contributor could submit code that was SCO's copyright -- or contained a back door. In the case of the Linux kernel, I doubt a back door would work because there seems to be quite a lot of peer review. However, for other projects it might work okay. These attacks apply in the corporate world as well, but to a lesser extent. Usually you have a better idea who someone is when you pay them money; this is a deterrent because it is a crime to ship trojan software wilfully. It also takes effort to infiltrate someone into a company's programming team; contributing code from an anonymous Internet account is much easier. On the other hand, once a back door is installed in binary-only software, it is much less likely to be found. The Interbase back door was only found when the source was opened. I think there are two defences against these attacks. The first is based on developers' reputations. If you don't have a strong reputation, people are much less likely to report on your new open source product, and much less likely to download it. This means that an attack might succeed against a few people, but it would be unlikely to compromise thousands of machines. (A moderated Freshmeat would be nice here -- you could have a site where a condition of listing your project was that you reviewed a certain number of others.) The second defence is the amount of work that it takes to produce a project that someone would be interested in. If I produced a clone of Word, and put a back door in it, no doubt lots of people would download it. However, the work is not justified by the reward; there are simpler ways of compromising machines. -- Pete - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New toy: SSLbar
Steven M. Bellovin wrote: Please don't take this personally... None taken here, and I doubt that the author of the tool (who has just joined this list it seems) would take any! From a security point of view, why should anyone download any plug-in from an unknown party? In this very specific case, why should someone download a a plug-in that by its own description is playing around in the crypto arena. How do we know it's not going to steal keys? Is the Mozilla API strong enough that it can't possibly do that? Is it implemented well enough that we trust it? (I see that in this case, the guts of the plug-in are in Javascript. Given how often Javascript has played a starring role in assorted security flaws, that doesn't reassure me. But I do appreciate open source.) It's an issue. I think the answer requires the same analysis as always: someone would download this plug-in if the result were likely more security in the overall browsing experience. So, the question then arises, could this plug-in give more security than the exposure to an untrustworthy party warrants? On the one hand, the plug-in isn't likely to be terribly effective, as is fairly obvious, as has been pointed out. OTOH, one might be downloading a trojan. Well, that's possible. Is it likely? I don't think so, and here's why: If this were an attack, it would be unlikely to be effective. There is a known site (albeit with a masked identity) with a webpage, etc. So there are tracks, and angry emails to the owner of the site will incur a cost for the attacker. Few people use keys, making this an obscure approach. I suppose if the target really *was* keys, then the challenge would be to target those key users ... against which, the users of keys are likely to be more security conscious than other victims. If the person was indeed a crook, why would he use open source? And, even though Javascript may have a poor security record, that's to do with bugs in its model and code efforts and potential security breachs, not with crooks acutally inserting code to steal value. I.e., theoretical breaches of security, not actual breaches of security. Also, to impune the plug-in arrangement is to impune all plug-ins, and to impune the download from an unknown is to impune all downloads from unknowns. What is the risk of downloads being trojaned, and the risk of plug-ins being aggressive? These are unknowable risks, a priori, so we have to resort to statistics and cost-benefit to work out the probability. And here, statistics is on our side. In practice, an attack is rarely initiated via a download, or via a plug-in. I.e., download this fantastic tool which just so annoyingly includes a trojan from the person who manages the site doesn't seem to occur as a real attack with any frequency. (Partly because it takes a long time to find the right victim, and partly because it leaves the attacker static and vulnerable, I'm guessing. In comparison, it seems that attackers get much better results by using targetted mass mailings tools to deliver their EMD.) So on balance, I won't download the tool, because its effectiveness is low. But so is its risk. Other people might come to other conclusions, but I personally don't buy the argument that just because I don't know the site, it shouldn't be touched. Life is full of risks. Only by taking risks do we understand what works and what doesn't. Real-life security is like that, as in practice, we know that not all can be covered in security, as it is simply too expensive to be 100% safe. So we have to take some risks in some areas. EMD - emails of mass destruction? -- iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New toy: SSLbar
In message [EMAIL PROTECTED], Ian Grigg writes: Also, to impune the plug-in arrangement is to impune all plug-ins, and to impune the download from an unknown is to impune all downloads from unknowns. Sounds about right... ... I.e., download this fantastic tool which just so annoyingly includes a trojan from the person who manages the site doesn't seem to occur as a real attack with any frequency. In fact, the come and get it method seems to exceed the scan and 'sploit method of building botnets. That is, Trojans are a very active method of infection. (Partly because it takes a long time to find the right victim, and partly because it leaves the attacker static and vulnerable, I'm guessing. In comparison, it seems that attackers get much better results by using targetted mass mailings tools to deliver their EMD.) Botnets communicate via IRC, among many other ways. Sometimes, they even use encrypted channels --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of Firewalls book) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New toy: SSLbar
On Wed, Jun 25, 2003 at 12:02:39PM +0100, Pete Chown wrote: On the other hand, once a back door is installed in binary-only software, it is much less likely to be found. The Interbase back door was only found when the source was opened. I doubt the truth of this statement. Certainly, the back door was only published after the source was opened. But, just as Matt Blaze found out when he published his attack on pin-and-tumbler locks, fields other than computer security do not have a culture of public disclosure. In all likelihood the Interbase back door was discovered and carefully promulgated among the gray- and black-hat communities interested in that product. Closed-source is not much of a guarantee in the face of a determined attacker. Or in the face of a large number of capable, interconnected, curious hackers (in the traditional sense of the word). -andy - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
New toy: SSLbar
It's a toolbar for Mozilla (and related web browsers) that automatically displays the SHA1 or MD5 fingerprint of the SSL certificate when you visit an SSL secured web site. You could of course click the little padlock icon and dig through a couple of dialogs to see it, but it's much easier when it's right there in front of you on the toolbar. So, what's the point? If you look at the fingerprint of an SSL certificate, and compare this against a fingerprint that you obtain from the site's owner via another channel (IIP, email, PGP-signed web page, etc.) you can be absolutely certain that the certificate is legitimate, and that you are exchanging encrypted data with the persons(s) you intended to. A more engaging description of the above - as well as SSLbar itself - can be found at https://194.109.142.142:1984/redirect.php?url=http%3A%2F%2Fsslbar.metropipe.nethttp://sslbar.metropipe.net Enjoy. A Jobless Recovery is like a Breadless Sandwich. -- Steve Schear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New toy: SSLbar
It's a toolbar for Mozilla (and related web browsers) that automatically displays the SHA1 or MD5 fingerprint of the SSL certificate when you visit an SSL secured web site. You could of course click the little padlock icon and dig through a couple of dialogs to see it, but it's much easier when it's right there in front of you on the toolbar. So, what's the point? If you look at the fingerprint of an SSL certificate, and compare this against a fingerprint that you obtain from the site's owner via another channel (IIP, email, PGP-signed web page, etc.) you can be absolutely certain that the certificate is legitimate, and that you are exchanging encrypted data with the persons(s) you intended to. Please don't take this personally -- I'm speaking in general terms here, rather than casting aspersions on anyone in particular. I've deliberately deleted any personal names from this reply, to underscore that point. From a security point of view, why should anyone download any plug-in from an unknown party? In this very specific case, why should someone download a a plug-in that by its own description is playing around in the crypto arena. How do we know it's not going to steal keys? Is the Mozilla API strong enough that it can't possibly do that? Is it implemented well enough that we trust it? (I see that in this case, the guts of the plug-in are in Javascript. Given how often Javascript has played a starring role in assorted security flaws, that doesn't reassure me. But I do appreciate open source.) --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of Firewalls book) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
