Re: New toy: SSLbar

2003-07-02 Thread mister_lee
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

2003-07-02 Thread James A. Donald

--
 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

2003-07-02 Thread Barney Wolff
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

2003-06-30 Thread Adam Fields
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

2003-06-26 Thread Mister Lee
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

2003-06-25 Thread Pete Chown
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

2003-06-25 Thread Ian Grigg
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

2003-06-25 Thread Steven M. Bellovin
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

2003-06-25 Thread Andy Isaacson
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]


Re: New toy: SSLbar

2003-06-24 Thread Steven M. Bellovin

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]