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]
