ussions of online & offline trust propogation:
http://www.garlic.com/~lynn/aadsm12.htm#55 TTPs & AADS (part II)
http://www.garlic.com/~lynn/aadsm13.htm#1 OCSP and LDAP
http://www.garlic.com/~lynn/aadsm14.htm#38 An attack on paypal (trivia addenda)
http://www.garlic.com/~lynn/aadsm14.htm#42 A
Matthew Byng-Maddick wrote:
>
> On Fri, Jun 13, 2003 at 04:32:12PM -0700, Bill Stewart wrote:
> > An e-gold-specific or paypal-specific client can tell,
> > because it can remember that it's trying to see the real thing,
> > but the browser can't tell, except by bugging you about
> > "Hi, this is
On Fri, Jun 13, 2003 at 04:32:12PM -0700, Bill Stewart wrote:
> An e-gold-specific or paypal-specific client can tell,
> because it can remember that it's trying to see the real thing,
> but the browser can't tell, except by bugging you about
> "Hi, this is a new site that's giving us a new cert" p
At 02:24 PM 06/11/2003 -0700, David Honig wrote:
At 12:42 PM 6/11/03 -0600, Anne & Lynn Wheeler wrote:
>actually, if you had a properly secured DNS then you could trust DNS
>to distribute public keys bound to a domain name in the same way they
>distribute ip-addresses bound to a domain name.
.
> as in previous observations having a domain name owner register their
> public key in the internet registry (domain name infrastructure or
> ip-address registery) starts to lesson the requirement for having SSL
> domain certificates.
Yes; this is why (I think) VeriSign bought Network Sol
The problem with these stop crackers and hackers by law is that it allows
software developers to get away with leaving huge gaping security holes
unfixed. Anecodatal evidence: The classic well known Robin Hood and Friar
Tuck "hack".
These days, the bug wouldn't get fixed and the guys reporting it
> IE checks the server name against each CN's individually.
I found that by experimentation too. I have VBScript sample on how to generate
such a CSR request for IIS using the CryptoAPI.
Furthermore, IE does not care if the CNs have different domains.
e.g.
/CN=www.domain.com/CN=www.domain.net/C
--- "James A. Donald" <[EMAIL PROTECTED]> wrote:
> --
> On 11 Jun 2003 at 20:07, Steven M. Bellovin wrote:
> > Let me point folk at http://www.securityfocus.com/news/5654
> > for a related issue. To put it very briefly, *real*
> > authentication is hard.
>
> I don't think so.
>
> Verisign'
--
On 11 Jun 2003 at 20:07, Steven M. Bellovin wrote:
> Let me point folk at http://www.securityfocus.com/news/5654
> for a related issue. To put it very briefly, *real*
> authentication is hard.
I don't think so.
Verisign's authentication is notoriously worthless and full of
holes, yet ver
At 05:34 PM 6/11/2003 -0700, David Honig wrote:
When I buy $20 of gas with non-bearer credentials (ie, credit card),
the vendor does a real-time check on me. Seems fair/useful to be able
to do same on them. I suppose eBay's feedback suffices... if their
last N "feedbacks" are negative, I might go
At 03:38 PM 6/11/03 -0600, Anne & Lynn Wheeler wrote:
even before e-commerce, the real
>BBB process was that people called up the BBB and got realtime information
> i.e. it was an online, realtime process.
>
>the equiivalent for an online, internet paradigm (as opposed to something
>left ove
> "Matt Crawford" <[EMAIL PROTECTED]> writes:
> >... Netscrape ind Internet Exploder each have a hack for
> >honoring the same cert for multiple server names. Opera seems to honor at
> >least one of the two hacks, and a cert can incorporate both at once.
> >
> > /C=US/ST=Illinois/L=Batavia/O
> You can also use *.fnal.gov
Yes, we know, but our in-house CA operator (me) won't issue such a
certificate.
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Steven M. Bellovin wrote:
> Let me point folk at http://www.securityfocus.com/news/5654
> for a related issue. To put it very briefly, *real* authentication is
> hard.
It may be that real authentication is hard, but the unbelievably sloppy
practices of domain name registrars doesn't prove the cas
"Matt Crawford" <[EMAIL PROTECTED]> writes:
>True as written, but Netscrape ind Internet Exploder each have a hack for
>honoring the same cert for multiple server names. Opera seems to honor at
>least one of the two hacks, and a cert can incorporate both at once.
>
> /C=US/ST=Illinois/L=Bat
At 08:07 PM 6/11/2003 -0400, Steven M. Bellovin wrote:
Let me point folk at http://www.securityfocus.com/news/5654
for a related issue. To put it very briefly, *real* authentication is
hard.
"real" authentication is actually that hard; it is "identification" that
tends to really get sticky. one o
Let me point folk at http://www.securityfocus.com/news/5654
for a related issue. To put it very briefly, *real* authentication is
hard.
--Steve Bellovin, http://www.research.att.com/~smb (me)
http://www.wilyhacker.com (2nd edition of "Firewalls" book)
-
somewhat related to the early posting in this m.l. about distributed
computing systems conference and possible interest from security and
cryptography sections.
when my wife and I were doing ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp
we were working with two people in the following m
You need a Better Business Bureau's cert, where the BBB is financially
liable.
(This implies it checks in *meatspace* and probably implies competition too.)
we actually included that in suggestion as part of original stuff for
setting up electronic commerce and providing comfort to consumers. ho
At 12:42 PM 6/11/03 -0600, Anne & Lynn Wheeler wrote:
>At 10:56 AM 6/11/2003 -0400, Sunder wrote:
>>In either case, we wouldn't need to worry about paying Verisign or anyone
>>else if we had properly secured DNS. Then you could trust those pop-up
>>self-signed SSL cert warnings.
>
>actually, if yo
In message <[EMAIL PROTECTED]>, "Matt Crawford" writ
es:
>> The worst trouble I've had with https is that you have no way to use host
>> header names to differentiate between sites that require different SSL
>> certificates.
>
>True as written, but Netscrape ind Internet Exploder each have a hack
>
> The worst trouble I've had with https is that you have no way to use host
> header names to differentiate between sites that require different SSL
> certificates.
True as written, but Netscrape ind Internet Exploder each have a hack
for honoring the same cert for multiple server names. Opera se
At 10:56 AM 6/11/2003 -0400, Sunder wrote:
In either case, we wouldn't need to worry about paying Verisign or anyone
else if we had properly secured DNS. Then you could trust those pop-up
self-signed SSL cert warnings.
actually, if you had a properly secured DNS then you could trust DNS
to d
Sunder <[EMAIL PROTECTED]> writes:
> The worst trouble I've had with https is that you have no way to use host
> header names to differentiate between sites that require different SSL
> certificates.
>
> i.e. www.foo.com www.bar.com www.baz.com can't all live on the same IP and
> have individual s
The worst trouble I've had with https is that you have no way to use host
header names to differentiate between sites that require different SSL
certificates.
i.e. www.foo.com www.bar.com www.baz.com can't all live on the same IP and
have individual ssl certs for https. :( This is because the cer
James A. Donald wrote:
> How many attacks have there been based on automatic trust of
> verisign's feckless ID checking? Not many, possibly none.
I imagine if there exists a https://www.go1d.com/ site for purposes of
fraud, it won't be using a self-signed cert. Of course it is possible that
the a
> the lack of buffer overruns in Multics. However, in the
> Unix/Linux/PC/Mac
> world, a successor language has not yet appeared.
Work on the existing C/C++ language will have a better chance
of actually being used earlier. Not that it removes the problem
entirely, but it should catches a lot of
"James A. Donald" <[EMAIL PROTECTED]> writes:
>On 8 Jun 2003 at 14:47, tom st denis wrote:
>>I disagree. That attack is more akin to a "Hi, I'm calling
>>from {insert bank here} and we need your CC info to update
>>your file."
>>
>>That doesn't mean credit cards [nor your bank] are flawed.
>
>Actu
At 5:12 PM -0700 6/8/03, Anne & Lynn Wheeler wrote:
>somebody (else) commented (in the thread) that anybody that currently
>(still) writes code resulting in buffer overflow exploit maybe should be
>thrown in jail.
A nice essay, partially on the need to include technological protections
against hum
--
On 9 Jun 2003 at 2:09, Dave Howe wrote:
> The problem is here, we are blaming the protective device for
> not being able to protect against the deliberate use of an
> attack that bypasses, not challenges it - by exploiting the
> gullibility or tendency to take the path of least resistance
>
--
On 8 Jun 2003 at 20:00, Anne & Lynn Wheeler wrote:
> that is why we coined the term merchant "comfort"
> certificates some time ago. my wife and I having done early
> work for payment gateway with small client/server startup in
> menlo park ... that had this thing called SSL/HTTPS ... and
>
--
On 8 Jun 2003 at 14:47, tom st denis wrote:
> I disagree. That attack is more akin to a "Hi, I'm calling
> from {insert bank here} and we need your CC info to update
> your file."
>
> That doesn't mean credit cards [nor your bank] are flawed.
Actually credit cards, and your bank, are fla
Yes, >NOW< if you can load yourself into kernel space, you can do anything
and everything - Thou Art God to quote Heinlein. This is true of every
OS. Except if you add that nice little TCPA bugger which can verify the
kernel image you're running is the right and approved one. Q.E.D.
Look at the
> For example, a proposal I saw recently which
> would have the OS decorate the borders of "trusted" windows with facts or
> images that an attacker wouldn't be able to predict: the name of your
> dog, or whatever.
But if the system is rooted, then the attacker merely has to find the
"today's secr
Nomen Nescio <[EMAIL PROTECTED]> writes:
>I don't see how this is going to work. The concept seems to assume that
>there is a distinction between "trusted" and "untrusted" programs. But in the
>NGSCB architecture, Nexus Computing Agents (NCAs) can be written by anyone.
>If you've loaded a Trojan
Tim Dierks wrote:
> - Get browser makers to design better ways to communicate to users that
> UI elements can be trusted. For example, a proposal I saw recently which
> would have the OS decorate the borders of "trusted" windows with facts or
> images that an attacker wouldn't be able to predic
Amir Herzberg <[EMAIL PROTECTED]> writes:
>Ka Ping Yee, User Interface Design for Secure System, ICICS, LNCS 2513, 2002.
Ka-Ping Yee has a web page at http://zesty.ca/sid/ and a lot of interesting
things to say about secure HCI (and HCI in general), e.g. a characterisation
of safe systems vs. gen
>Yuan, Ye and Smith, Trusted Path for Browsers, 11th Usenix security symp,
>2002.
Minor nit: just Ye and Smith. (Yuan had helped with some of the spoofing)
Advertisement: we also built this into Mozilla, for Linux and Windows.
http://www.cs.dartmouth.edu/~pkilab/demos/countermeasures/
--Sean
At 18:03 08/06/2003 -0400, Tim Dierks wrote:
- Get browser makers to design better ways to communicate to users that
UI elements can be trusted. For example, a proposal I saw recently which
would have the OS decorate the borders of "trusted" windows with facts or
images that an attacker wouldn
At 02:09 AM 6/9/2003 +0100, Dave Howe wrote:
The problem is here, we are blaming the protective device for not being able
to protect against the deliberate use of an attack that bypasses, not
challenges it - by exploiting the gullibility or tendency to take the path
of least resistance of the user.
In message <[EMAIL PROTECTED]>, Anne & Lynn Whee
ler writes:
>
>at a recent cybersecurity conference, somebody made the statement that (of
>the current outsider, internet exploits, approximately 1/3rd are buffer
>overflows, 1/3rd are network traffic containing virus that infects a
>machine beca
> in a world where there are repeated human mistakes/failures
> at some point it is recognized that people aren't perfect and the design
> is changed to accommodate peoples foibles. in some respects that is what
> helmets, seat belts, and air bags have been about.
The problem is here, we are
At 11:43 PM 6/8/2003 +0100, Dave Howe wrote:
HTTPS works just fine.
The problem is - people are broken.
At the very least, verisign should say "ok so '..go1d..' is a valid server
address, but doesn't it look suspiously similar to this '..gold..' site over
here?" for https://pseudo-gold-site/ - but
James A. Donald wrote:
> Attached is a spam mail that constitutes an attack on paypal similar
> in effect and method to man in the middle.
>
> The bottom line is that https just is not working. Its broken.
HTTPS works just fine.
The problem is - people are broken.
At the very lea
"James A. Donald" <[EMAIL PROTECTED]> wrote:
>
>>Attached is a spam mail that constitutes an attack on paypal similar
>>in effect and method to man in the middle.
Yeah, I've been seeing that one for a month or
two now. I've seen several versions. Some of
At 02:55 PM 6/8/2003, James A. Donald wrote:
Attached is a spam mail that constitutes an attack on paypal similar
in effect and method to man in the middle.
The bottom line is that https just is not working. Its broken.
The fact that people keep using shared secrets is a symptom of https
not
--- "James A. Donald" <[EMAIL PROTECTED]> wrote:
> Attached is a spam mail that constitutes an attack on paypal similar
> in effect and method to man in the middle.
>
> The bottom line is that https just is not working. Its broken.
I disagree. That attack is mor
Attached is a spam mail that constitutes an attack on paypal similar
in effect and method to man in the middle.
The bottom line is that https just is not working. Its broken.
The fact that people keep using shared secrets is a symptom of https
not working.
The flaw in https is that you
48 matches
Mail list logo
