Fedora directory users - Jul 2005 - boot time startup requires password

Hi all. 

I hit a snag yesterday when I rebooted my directory server box
(running RHEL 4). The problem is that I''m using SSL/TLS, and that
means that every time I restart the directory server I have to provide
the password for the certificate database. Now, I *know* that this
would never stand in a large production environment, so I can only
imagine that I missed some essential piece of documentation on how I
can use SSL/TLS, but not be forced to provide a password every time
the server starts.

Could someone provide a link to the doc that addresses this, or does
someone have some clue they could provide for my feeble brain?

Thanks.

http://www.redhat.com/docs/manuals/dir-server/ag/intro.htm#39523

NB:  you trade the ease of startup with a security risk, in that your 
keyphrase
is stored in a file cleartext.

Kevin

Quoting Brian Jones <bkjones@gmail.com>:
> Hi all.
>
> I hit a snag yesterday when I rebooted my directory server box
> (running RHEL 4). The problem is that I''m using SSL/TLS, and that
> means that every time I restart the directory server I have to provide
> the password for the certificate database. Now, I *know* that this
> would never stand in a large production environment, so I can only
> imagine that I missed some essential piece of documentation on how I
> can use SSL/TLS, but not be forced to provide a password every time
> the server starts.
>
> Could someone provide a link to the doc that addresses this, or does
> someone have some clue they could provide for my feeble brain?
>
> Thanks.
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>


-- 
Kevin M. Myer
Senior Systems Administrator
Lancaster-Lebanon Intermediate Unit 13  http://www.iu13.org

Thanks, Kevin. 

Can I make a feature request to whoever sees this that is way better
at Java/C than me to at least make the stored password crypted in
something stronger than rot13?



On 7/8/05, Kevin Myer <kevin_myer@iu13.org> wrote:
> http://www.redhat.com/docs/manuals/dir-server/ag/intro.htm#39523
> 
> NB:  you trade the ease of startup with a security risk, in that your
> keyphrase
> is stored in a file cleartext.
> 
> Kevin
> 
> Quoting Brian Jones <bkjones@gmail.com>:
> 
> > Hi all.
> >
> > I hit a snag yesterday when I rebooted my directory server box
> > (running RHEL 4). The problem is that I''m using SSL/TLS, and
that
> > means that every time I restart the directory server I have to provide
> > the password for the certificate database. Now, I *know* that this
> > would never stand in a large production environment, so I can only
> > imagine that I missed some essential piece of documentation on how I
> > can use SSL/TLS, but not be forced to provide a password every time
> > the server starts.
> >
> > Could someone provide a link to the doc that addresses this, or does
> > someone have some clue they could provide for my feeble brain?
> >
> > Thanks.
> >
> > --
> > Fedora-directory-users mailing list
> > Fedora-directory-users@redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >
> 
> 
> 
> --
> Kevin M. Myer
> Senior Systems Administrator
> Lancaster-Lebanon Intermediate Unit 13  http://www.iu13.org
> 
> 
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

Kevin Myer wrote:
> http://www.redhat.com/docs/manuals/dir-server/ag/intro.htm#39523
>
> NB:  you trade the ease of startup with a security risk, in that your 
> keyphrase
> is stored in a file cleartext.
Right.  Very secure environments invest in hardware crypto 
devices/dongles that provide this functionality without giving up the 
security.
>
> Kevin
>
> Quoting Brian Jones <bkjones@gmail.com>:
>
>> Hi all.
>>
>> I hit a snag yesterday when I rebooted my directory server box
>> (running RHEL 4). The problem is that I''m using SSL/TLS, and
that
>> means that every time I restart the directory server I have to provide
>> the password for the certificate database. Now, I *know* that this
>> would never stand in a large production environment, so I can only
>> imagine that I missed some essential piece of documentation on how I
>> can use SSL/TLS, but not be forced to provide a password every time
>> the server starts.
>>
>> Could someone provide a link to the doc that addresses this, or does
>> someone have some clue they could provide for my feeble brain?
>>
>> Thanks.
>>
>> -- 
>> Fedora-directory-users mailing list
>> Fedora-directory-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>
>
>
>

Brian Jones wrote:
>Thanks, Kevin. 
>
>Can I make a feature request to whoever sees this that is way better
>at Java/C than me to at least make the stored password crypted in
>something stronger than rot13?
>  
>
What would you suggest?  Note that a determined attacker will be able to 
decode anything that could be done without a key, especially since the 
source code is available.
>
>
>On 7/8/05, Kevin Myer <kevin_myer@iu13.org> wrote:
>  
>
>>http://www.redhat.com/docs/manuals/dir-server/ag/intro.htm#39523
>>
>>NB:  you trade the ease of startup with a security risk, in that your
>>keyphrase
>>is stored in a file cleartext.
>>
>>Kevin
>>
>>Quoting Brian Jones <bkjones@gmail.com>:
>>
>>    
>>
>>>Hi all.
>>>
>>>I hit a snag yesterday when I rebooted my directory server box
>>>(running RHEL 4). The problem is that I''m using SSL/TLS,
and that
>>>means that every time I restart the directory server I have to
provide
>>>the password for the certificate database. Now, I *know* that this
>>>would never stand in a large production environment, so I can only
>>>imagine that I missed some essential piece of documentation on how I
>>>can use SSL/TLS, but not be forced to provide a password every time
>>>the server starts.
>>>
>>>Could someone provide a link to the doc that addresses this, or does
>>>someone have some clue they could provide for my feeble brain?
>>>
>>>Thanks.
>>>
>>>--
>>>Fedora-directory-users mailing list
>>>Fedora-directory-users@redhat.com
>>>https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>
>>>      
>>>
>>
>>--
>>Kevin M. Myer
>>Senior Systems Administrator
>>Lancaster-Lebanon Intermediate Unit 13  http://www.iu13.org
>>
>>
>>--
>>Fedora-directory-users mailing list
>>Fedora-directory-users@redhat.com
>>https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>
>>    
>>
>
>--
>Fedora-directory-users mailing list
>Fedora-directory-users@redhat.com
>https://www.redhat.com/mailman/listinfo/fedora-directory-users
>  
>

Quoting Brian Jones <bkjones@gmail.com>:
> Thanks, Kevin.
>
> Can I make a feature request to whoever sees this that is way better
> at Java/C than me to at least make the stored password crypted in
> something stronger than rot13?
Just my opinion, but its kind of moot what format its stored in, as 
long as its
a reversible cipher.  An attacker need only see the ciphertext.  Obscurity
provides only one thing - it raises the bar to actually use the password, in
that it requires an attacker to do a minimal amount of work to figure out what
the plaintext is.  If the server daemon can use a reversible process to obtain
plaintext, then so can the attacker and they need to do that work 
first, before
they can just type it in.  So the note in the documentation about not using
this mechanism for storing passwords on an unsecured system is 
definitely to be
heeded.

I''ve seen a number of debates about the merits of obscuring passwords
in other
contexts - in one case, the decision was apparently made that it wasn''t
even
worth the hassle to obscure the password and it was echoed onto the screen of
the browser, since in theory, only administrators could access that 
screen. I''d be interested to see what others think about obscuring the 
admin password.

Kevin
-- 
Kevin M. Myer
Senior Systems Administrator
Lancaster-Lebanon Intermediate Unit 13  http://www.iu13.org