Testing OCSP with openssl

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Testing OCSP with openssl

Robert Moskowitz
Jamie Nugyen's guide uses openssl to test OCSP with 'openssl ocsp':

https://jamielinux.com/docs/openssl-certificate-authority/online-certificate-status-protocol.html

What is unclear here is:

Does openssl read the index.txt file once at startup, or does it read it
with each query.  From the way I read his guide it reads like index.txt
is only read at startup.

Also he recommends password protecting the keypair.  That results in
needing to provide the password at responder startup.  Is this the
'normal' approach?  Is the password provided in some other file (like a
responder config file)?  I am use to putting SQL passwords into php
config files, not that I like that...

thanks

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Testing OCSP with openssl

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf
> Of Robert Moskowitz
> Sent: Tuesday, September 05, 2017 08:43
>
> Also he recommends password protecting the keypair.  That results in
> needing to provide the password at responder startup.  Is this the
> 'normal' approach?  Is the password provided in some other file (like a
> responder config file)?  I am use to putting SQL passwords into php
> config files, not that I like that...

That's one of the oldest problems in IT security. Most approaches fall into one of three categories:

- Specialized hardware. This was one of the original intended uses for Sun's JavaButton hardware token, back in the '90s, but the JavaButton never really took off. These days we have various flavors of HSMs which act as key vaults and signing servers - though then you have the problem of authenticating to the signing server, or if you offload all crypto operations, authenticating to the crypto server. TPMs (which are essentially integrated HSMs), smartcard readers, etc can also hold keys, but typically require some authentication by a human at system startup.

- Attended startup with manual passphrase entry. The server can't start until someone enters the passphrase at the keyboard.

- Passphrase or private key in a file for unattended startup, hopefully protected as well as possible by filesystem permissions, filesystem encryption, etc. This is obviously the weakest choice for key protection, since it has a wider threat tree (more paths for an attacker to make use of the private key) than the other two options.

For general-purpose applications where you don't need particularly good performance, such as a moderate-volume web server, there are some very inexpensive hardware options. OpenSSL works well with the NitroKey HSM (via the PKCS#11 engine), for example. Things get tougher as you add requirements.

--
Michael Wojcik
Distinguished Engineer, Micro Focus


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Testing OCSP with openssl

Robert Moskowitz
Michael,

Thanks for this concise review.  I look at it as the "Big Bang theory of
Security".  i.e. what comes first.

And HOW DID we get those heavy metals beyond Iron?  :)

Bob

On 09/05/2017 09:10 AM, Michael Wojcik wrote:

>> From: openssl-users [mailto:[hidden email]] On Behalf
>> Of Robert Moskowitz
>> Sent: Tuesday, September 05, 2017 08:43
>>
>> Also he recommends password protecting the keypair.  That results in
>> needing to provide the password at responder startup.  Is this the
>> 'normal' approach?  Is the password provided in some other file (like a
>> responder config file)?  I am use to putting SQL passwords into php
>> config files, not that I like that...
> That's one of the oldest problems in IT security. Most approaches fall into one of three categories:
>
> - Specialized hardware. This was one of the original intended uses for Sun's JavaButton hardware token, back in the '90s, but the JavaButton never really took off. These days we have various flavors of HSMs which act as key vaults and signing servers - though then you have the problem of authenticating to the signing server, or if you offload all crypto operations, authenticating to the crypto server. TPMs (which are essentially integrated HSMs), smartcard readers, etc can also hold keys, but typically require some authentication by a human at system startup.
>
> - Attended startup with manual passphrase entry. The server can't start until someone enters the passphrase at the keyboard.
>
> - Passphrase or private key in a file for unattended startup, hopefully protected as well as possible by filesystem permissions, filesystem encryption, etc. This is obviously the weakest choice for key protection, since it has a wider threat tree (more paths for an attacker to make use of the private key) than the other two options.
>
> For general-purpose applications where you don't need particularly good performance, such as a moderate-volume web server, there are some very inexpensive hardware options. OpenSSL works well with the NitroKey HSM (via the PKCS#11 engine), for example. Things get tougher as you add requirements.
>

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Testing OCSP with openssl

Dr. Stephen Henson
In reply to this post by Robert Moskowitz
On Tue, Sep 05, 2017, Robert Moskowitz wrote:

> Jamie Nugyen's guide uses openssl to test OCSP with 'openssl ocsp':
>
> https://jamielinux.com/docs/openssl-certificate-authority/online-certificate-status-protocol.html
>
> What is unclear here is:
>
> Does openssl read the index.txt file once at startup, or does it
> read it with each query.  From the way I read his guide it reads
> like index.txt is only read at startup.
>

Once on startup. The mini-responder is only a test utility.
It is not usable as a full blown responder.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Testing OCSP with openssl

Robert Moskowitz


On 09/05/2017 11:59 AM, Dr. Stephen Henson wrote:

> On Tue, Sep 05, 2017, Robert Moskowitz wrote:
>
>> Jamie Nugyen's guide uses openssl to test OCSP with 'openssl ocsp':
>>
>> https://jamielinux.com/docs/openssl-certificate-authority/online-certificate-status-protocol.html
>>
>> What is unclear here is:
>>
>> Does openssl read the index.txt file once at startup, or does it
>> read it with each query.  From the way I read his guide it reads
>> like index.txt is only read at startup.
>>
> Once on startup. The mini-responder is only a test utility.
> It is not usable as a full blown responder.

Oh, I got the test utility limitation.  Just for my guide, after
revoking the certificate which results in index.txt being updated, does
the test 'openssl ocsp' service need to be restarted to reread the
index.txt file?

So from your response, just the once at startup, and I will have to
specify (as Jamie does in his guide) to restart the test responder.

I am searching for a 'simple' OCSP responder for myself...

Thanks

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users