Jeff,
I take your point about the differences in the articles. I'll check out the
OWASP site link you provided.
Thanks for your help.
Son
On Sunday, July 14, 2013 12:33:20 PM UTC-7, Jeffrey Walton wrote:
>
> > The Most Dangerous Code in the World: Validating SSL Certificates in
> > Non-Browser Software
> This is a different failure.
>
> A certificate does one thing (I've seen a number of security books
> screw it up, like CISSP study guides): it binds a public key to an
> entity via a trusted party's signature. Emphasis on binding the entity
> and its key.
>
> In the Internet profile (RFC 5280), the certificate's common name (CN)
> or alternate name (SAN) must match the website you browsed. So
> "www.example.com" is the entity, and the public key {e,n} (in the case
> of RSA) is bound to that name via a root or sub signature on the
> record (and and its all housed in an X.509 certificate).
>
> The most dangerous software paper pointed out that many libraries were
> not checking the name in the certificate matched the site. In essence,
> any certificate served by a server and signed by an authority was
> accepted, even "Honest Achmed’s Used Cars and Certificates"
> (www.achmed-used-cars-and-certs.com) even though you browsed
> www.example.com.
>
> There are a couple of ways to side step the problems created by PKI.
> See, for example,
> https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning.
>
> Jeff
>
> On Sun, Jul 14, 2013 at 3:16 PM, <sonny...@gmail.com <javascript:>>
> wrote:
> > Jeff,
> >
> > Thank you for your interesting and helpful response. I took some time to
> > download and peruse Peter Gutmann's book; thanks for including it. I am
> > going to reconsider my use of CRL and look into OCSP as a way to
> determine
> > whether the server's certificate (and others in the chain) have been
> > revoked.
> >
> > Thanks again.
> > Son
> >
> > ps
> >
> > I found the following paper shorter but just as alarming as my brief
> scan of
> > the Gutmann book:
> >
> > The Most Dangerous Code in the World: Validating SSL Certificates in
> > Non-Browser Software
> >
> >
> > On Sunday, July 14, 2013 10:02:33 AM UTC-7, Jeffrey Walton wrote:
> >>
> >> On Sun, Jul 14, 2013 at 10:45 AM, <sonny...@gmail.com> wrote:
> >> > I would like to add CRL checking to the application I am working on.
> >> CRL checking will likely result in a DoS. If a bad URI does not do it,
> >> a mulit-megabyte CRL over 3G/4G/Wimax/LTE will surely do it.
> >>
> >> > desktop I use the javax.naming package but this is not available on
> >> > Android.
> >> > I have found little discussion of this and wonder how it is
> implemented
> >> > for
> >> > Android applications.
> >> Probably not since its so broken.
> >>
> >> > I wonder whether app developers rely on the certificate's CA being in
> >> > their
> >> > cacerts or having a copy of the certificate in a private store. Are
> java
> >> > app
> >> > developers checking OCSP or CRL?
> >> Disable CRLS and OCSP checking; and use something like OCSP stapling.
> >>
> >> In OCSP stapling, the server performs the CRL/OCSP check and send the
> >> result down to the client when the client fetches the server's
> >> certificate. In this case, the server performs the feting and caching.
> >> Its similar to the way the server sends all certificates in the chain
> >> to a client when solving the "which directory" problem.
> >>
> >> Peter Gutmann beats up on PKI in his book Engineering Security
> >> (www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf). There's an entire
> >> chapter dedicated to the topic of PKI failures in practice. For
> >> Browser behavior related to CRL/OCSP failures, see the discussion
> >> around page 503.*
> >>
> >> Jeff
> >>
> >> From page 503:
> >>
> >> ... What the addition of the extra security features has done is make
> >> the system considerably more brittle, reducing its reliability to the
> >> lowest common denominator of the web server and the OCSP server, as
> >> shown in Figure 129. Recognising this, both MSIE 7 and Opera 9 allowed
> >> a connection to a site if the corresponding OCSP server couldn’t be
> >> contacted while Firefox 2 disallowed the connection with an
> >> incomprehensible OCSP error message. Predictably, the OCSP error was
> >> seen by users to mean that the site was down, leading to OCSP-induced
> >> apparent outages of major services like FedEx [51]. Mozilla later
> >> changed Firefox’ behaviour to ignore problems that occurred when
> >> communicating with OCSP responders, acknowledging the fact that
> >> “breaking web sites because of the unreliability of an OCSP responder
> >> is worse [than any security consequences]” [52].
> >>
> >> Several years later, in explicit recognition of this problem, Google
> >> simply disabled OCSP in Chrome for standard (non-EV) certificates,
> >> comparing the soft-fail revocation checking that’s used in browsers to
> >> “a seatbelt that snaps when you crash” [53]....
>
--
You received this message because you are subscribed to the Google Groups
"Android Security Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to android-security-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to android-security-discuss@googlegroups.com.
Visit this group at http://groups.google.com/group/android-security-discuss.
For more options, visit https://groups.google.com/groups/opt_out.
