On Fri, Jul 18, 2003 at 02:23:02PM +0200, Amar Desai wrote: > It seems like OCSP and CRL both are vulnerable to DOS.
One could try DOSing anything on public internet. Sometimes customers actually do DOSing of popular content: a low-profile site mentioned on CNN might become unavailable. The point is info on current cert status might be included into the message itself so if one manage to got the message fresh status is there inside. On the other side, if one need to fetch CRL from another place that place could be DOSed with everything else running just fine. > It woulld be good if you can explain me how signed OCSP requests provide > better tracing. Well, what could be a reason for a OCSP request on company X sales manager' certificate status signed by company Y chain supply manager' key? This might be considered a real-time alert sent out by a mail reader to a CA running OCSP responder. I guess companies might want to run their own responders just to not leak something interesting. > So does it mean, it is not very secure to add such a functionality in > OpenSSL. And if this is so, i think for OCSP also it is same. "Secure" is a very broad term. Yes, both OCSP and CRL are quite good at helping signatures verification. And yes, certificate current status check is required in some environments. However one might want to see the whole picture. > Regards > Amar > > > > > > Vadim Fedukovich wrote: > > >On Thu, Jul 17, 2003 at 10:56:06PM +0200, Dr. Stephen Henson wrote: > > > > > >>On Wed, Jul 16, 2003, Amar Desai wrote: > >> > >> > >> > >>>Hi All > >>>I would like to know what are the security concerns if we provide a > >>>functionality of downloading a CRL (in case where there is no crl in > >>>specified direcotry or file) in the get_crl function using say wget? > >>> > >>> > >>> > >>You should be careful that you don't download CRLs for unstrusted > >>certificates. If you do there are several possible concerns: > >> > >>DOS attack. The CRL download could be made very slow, either by throttling > >>the connection or including a huge CRL. > >> > >> > > > >In SET, CRLs were made part of the business. That is, one could try DOS it > >as a whole but cant hurt just CRL pickup. > > > >Maybe one could send CRLs as part of TLS handshake > > > > > > > >>Leaking information about the caller. If the CRL downloader is on a > >>machine > >>that isn't public then some details about it can be obtained (IP address > >>etc). > >> > >> > > > >It's unlikely non-public IP address will be shown after an ip-masquerading > >host (a very popular solution). Yes, at least one http proxy (squid, > >another popular solution) can insert "X-Forwarded-For: 192.1.2.3" headers > >into outgoing requests unless default config was changed. > > > >Any online status check leaks info on who deals with whom. > >OCSP clients with signed requests provides even better tracing > > > >Surprisingly there's still a very limited interest in anonymous > >or controlled-leaks solutions. > > > > > > > >>Steve. > >>-- > >>Dr Stephen N. Henson. > >>Core developer of the OpenSSL project: http://www.openssl.org/ > >>Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ > >>Email: [EMAIL PROTECTED], PGP key: via homepage. > >>______________________________________________________________________ > >>OpenSSL Project http://www.openssl.org > >>Development Mailing List [EMAIL PROTECTED] > >>Automated List Manager [EMAIL PROTECTED] > >> > >> > >______________________________________________________________________ > >OpenSSL Project http://www.openssl.org > >Development Mailing List [EMAIL PROTECTED] > >Automated List Manager [EMAIL PROTECTED] > > > > > > > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
