On Sun, Jul 14, 2013 at 10:45 AM, <sonnydee...@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.
