Re: On Open Source
From: Henrick Hellström (henrick.hellstrm_at_telia.com)
Date: 05/24/04
- Next message: GeorgeD: "Re: Looking for Good Encrytion Software"
- Previous message: Anne & Lynn Wheeler: "Re: MITM attacks"
- Maybe in reply to: Henrick Hellström: "On Open Source"
- Next in thread: Lassi Hippeläinen: "Re: On Open Source"
- Reply: Lassi Hippeläinen: "Re: On Open Source"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sun, 23 May 2004 22:53:33 GMT
Bodo Moeller wrote:
> One thing that could have been done in the OpenSSL API to protect
> against *unintentional* use of SSL/TLS without authentication is to
> require all client applications to actively make some security
> settings (such that they'd either have to provide a list of acceptable
> root certificates, or to disable authentication), making connection
> attempts fail otherwise. This would make some sense, but
Exactly my point. OpenSSL *could* have done that, and IMHO *ought* to
have done that from the start.
> 1. it would be an incompatible change, breaking existing applications
> that either perform proper authentication (e.g. by checking the
> server certificate themselves after the SSL/TLS handshake has
> completed) or intentionally do not insist on authentication; and
Yes, that is something I find likely that the OpenSSL team might
consider to be a compelling argument against making the API more fool
proof w.r.t. certificate validation. I anticipate that OpenSSL will have
this issue for a long time to come.
> 2. other attempts to make the OpenSSL library a little more foolproof
> teach us that this measure would likely to be circumvented by some
> of the very applications that it is intended to protect (at some
> version, OpenSSL has started to try protect against use of the
> library without sufficient seeding for the pseudo-random number
> generator -- it now counts the number of bytes of "random seeding"
> provided to the library, only to see applications start using
> *fixed* seeding strings just to circumvent the security measure);
> even if the default is to insist on certificate verification, some
> applications would simply disable it and not worry about this any
> more.
Sure, but then they do it with their eyes wide open. I wouldn't say that
snake-oil by ignorance is better than snake-oil by choice, but at least
you stand a better chance fighting the former.
> On the other hand, other software tends to "solve" this problem by
> providing a long list of root certificates for "trusted" third parties
> that users don't know anything about. How many users of, say, MS
> Internet Explorer have actually taken a look at the list of the
> certification authorities that they "trust"? Of those who have
> bothered to do this, how many would be able to actually recount just
> the *jurisdications* under which those "authorities" operate? Is
> having such a default really "more secure" than no authentication at
> all -- doesn't it actually just provide a false sense of security
> unless users go through the list and weed out root certificates from
> organizations they don't know anything about?
Agreed. That is a good question, and I like your previous solution
(above) better. There are however other solutions. For example, the
certificate authentication for S/MIME in later releases of MS Outlook
Express 6 is surprisingly rigid, since the signature certificate of the
sender does not only have to be signed by a trusted CA, but has to be
explicitly listed as trusted by the recipient user.
>>Premise 1. Client side authentication of the remote host identity is THE
>>security service you would normally use SSL/TLS for. Getting a
>>confidential communication channel with message integrity is pointless
>>unless you have equally strong proof of the identity of the remote peer.
>
> This is not totally true -- see some of the examples above. You are
> right that message integrity is mostly pointless when you don't know
> who you are talking to. But it is simpler to use the protocol
> unchanged and with message integrity functionality even when this
> functionality is not, well, functional.
Not sure about that. All of your examples except the last one relied on
certificate validation in some form or another; through CA chaining or
through advance knowledge of the public key (which of course might or
might not be described as /certificate/ validation depending on the
implementation). Only the last example (SMTP with SSL/TLS) did not rely
on any authentication at all, but OTOH that is a (well) known security
issue with the way the SMTP infrastructure works.
> And using client side SSL/TLS *with* root certificates but without
> having checked the list of certification authorities is like driving
> 50 without knowing whether this speed measurement is in angstrom per
> millenium, kilometers per hour, or lightyears per century :-)
Probably. <g>
- Next message: GeorgeD: "Re: Looking for Good Encrytion Software"
- Previous message: Anne & Lynn Wheeler: "Re: MITM attacks"
- Maybe in reply to: Henrick Hellström: "On Open Source"
- Next in thread: Lassi Hippeläinen: "Re: On Open Source"
- Reply: Lassi Hippeläinen: "Re: On Open Source"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
