ejbca-develop — Development discussions

[Ejbca-develop] creating publishers using cli

[Tomasz R. <mo...@gm...>]

Hi,

  Is there a way to create Publishers from cli ?

  I'm trying to automate ejbca installation process in our environment
and would love to instantiate few publishers along the way.

Regards

Re: [Ejbca-develop] Approval notification recipient per EE profile

[Michael S. <mi...@st...>]

Michael Ströder wrote:
> Is it possible to send approval notifications to different recipient address
> specified in an EE profile? It seems not.
> 
> A possible work-around would be to use some sort of rewriting in the local MTA
> (here postfix). But for this at least it should be possible to add EE profile
> name to the e-mail subject or use a specific sender address.

We tried to add ${OU} to the subject string in

src/intresources/ejbcaresources.en.properties

but it seems the variable is not available because ${OU} gets added to the
subject of approval notification without being replaced with the real value.

Ciao, Michael.

Re: [Ejbca-develop] ejbca.sh keybind gencsr and key alias

[Michael S. <mi...@st...>]

Michael Ströder wrote:
> I'm using
> 
>   ejbca.sh cryptotoken generatekey \
>     --token "${CT_NAME}" \
>     --alias "${KEY_ALIAS}" \
>     --keyspec 2048 \
>     --verbose
> 
>   ejbca.sh keybind gencsr \
>     --name "${KB_NAME}" \
>     -f "${CSR_FILE_NAME}" \
>     --verbose
> 
> to generate the next key pair and CSR for an OCSP key binding.
> This creates a new key alias in the given crypto token in the same way the
> admin UI does when hitting the button for generating a new key for an OCSP key
> binding.

I guess this has to be used before gencsr:

ejbca.sh keybind modify --nextkeypair

Ciao, Michael.

[Ejbca-develop] Approval notification recipient per EE profile

[Michael S. <mi...@st...>]

HI!

Is it possible to send approval notifications to different recipient address
specified in an EE profile? It seems not.

A possible work-around would be to use some sort of rewriting in the local MTA
(here postfix). But for this at least it should be possible to add EE profile
name to the e-mail subject or use a specific sender address.

Ciao, Michael.

[Ejbca-develop] ejbca.sh keybind gencsr and key alias

[Michael S. <mi...@st...>]

HI!

I'm using

  ejbca.sh cryptotoken generatekey \
    --token "${CT_NAME}" \
    --alias "${KEY_ALIAS}" \
    --keyspec 2048 \
    --verbose

  ejbca.sh keybind gencsr \
    --name "${KB_NAME}" \
    -f "${CSR_FILE_NAME}" \
    --verbose

to generate the next key pair and CSR for an OCSP key binding.
This creates a new key alias in the given crypto token in the same way the
admin UI does when hitting the button for generating a new key for an OCSP key
binding.

But with ejbca.sh keybind gencsr I cannot specify the key alias used for
generating the CSR. How does that work? In my local test the old public key
was put into the CSR.

Ciao, Michael.

Re: [Ejbca-develop] Wrong DN in ldap publisher when using equas sign in entity name

[Michael S. <mi...@st...>]

Michael Postmann wrote:
> I've attached lddiff's of one of our old LDAP entry and one of our new LDAP entries, created by EJBCA.
> 
> My problem is, that the new.ldiff has two "cn" fields of which one is cut
> off and the other one has the equals sign escaped with a backslash.
> And the cut off version is then used for the Subject dn.

Yes, this indeed seems to be broken.

Excerpt from your new LDIF file:

dn: cn=CMS_9999000451_001_test_blah_MAIL,ou=paysafecard[..]
[..]
cn: CMS_9999000451_001_test_blah_MAIL\=ca...@pa...
cn: CMS_9999000451_001_test_blah_MAIL
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson

If your input value was CMS_9999000451_001_test_blah_MAIL\=ca...@pa...
then attribute value in 'cn' must not be escaped! And of course the second
truncated attribute value must not be there. Only the DN should contain the
single DN-escaped 'cn' value.

I've looked inside the cert of your new entry.

Don't turn LDAP DN order in EJBCA. It's broken and does exactly the opposite
of what it sounds like (see mailing list archive). You can see it when
displaying the cert with openssl x509 -nameopt rfc2253

The CN attribute in the cert's subject DN seems to be correct since it is
CMS...@pa...

My recommendation:
Don't use the built-in LDAP publisher if you have more specific requirements,
especially regarding naming. You could use the generic publisher for invoking
a script and let a custom script implemented in your favourite scripting
language correctly extract the data from certs and CRL and push it to the LDAP
server. Not sure how robust the error handling is with shell scripts.
Therefore I'd only move the files into a external queue directory and let the
custom publisher read from there.

@EJBCA developers:
Your LDAP publisher is not worse than those of all the other PKI products I've
used. But the handling of DN string representations needs serious overhaul in
various places (as already discussed here).

Ciao, Michael.

Re: [Ejbca-develop] Wrong DN in ldap publisher when using equas sign in entity name

[Michael P. <M.P...@pa...>]

I've attached lddiff's of one of our old LDAP entry and one of our new LDAP entries, created by EJBCA.

My problem is, that the new.ldiff has two "cn" fields of which one is cut off and the other one has the equals sign escaped with a backslash.
And the cut off version is then used for the Subject dn.

I hope this clears things up a bit.

regards
nomike

-----Ursprüngliche Nachricht-----
Von: Michael Ströder [mailto:mi...@st...] 
Gesendet: Dienstag, 3. März 2015 11:51
An: ejb...@li...
Betreff: Re: [Ejbca-develop] Wrong DN in ldap publisher when using equas sign in entity name

Michael Postmann wrote:
> When I create a new end entity with the name 'CMS...@ex...' an LDAP entry is published which has two DNs:
> 'CMS_9999000451_001_test_blah_MAIL' and 
> 'CMS_9999000451_001_test_blah_MAIL\=fo...@ex...'
> 
> of which the former is used as the name for the entry.
> 
> I'm wondering why the extra backslash is added and why there are two DNs.

I admit that I don't fully understand your issue. It would probably help if you provide an LDIF export of the two entries.

Note that = is one of the DN special chars which must be escaped to be part of a RDN value in the DN string representation (see RFC 4514). The accompanying attribute values should only contain the unescaped value.

Ciao, Michael.

Re: [Ejbca-develop] Wrong DN in ldap publisher when using equas sign in entity name

[Michael S. <mi...@st...>]

Michael Postmann wrote:
> When I create a new end entity with the name 'CMS...@ex...' an LDAP entry is published which has two DNs:
> 'CMS_9999000451_001_test_blah_MAIL' and
> 'CMS_9999000451_001_test_blah_MAIL\=fo...@ex...'
> 
> of which the former is used as the name for the entry.
> 
> I'm wondering why the extra backslash is added and why there are two DNs.

I admit that I don't fully understand your issue. It would probably help if
you provide an LDIF export of the two entries.

Note that = is one of the DN special chars which must be escaped to be part of
a RDN value in the DN string representation (see RFC 4514). The accompanying
attribute values should only contain the unescaped value.

Ciao, Michael.

Re: [Ejbca-develop] Wrong DN in ldap publisher when using equas sign in entity name

[Tomas G. <to...@pr...>]

I'm not sure about it, but LDAP is a bit of a pita and may need escaping 
etc. Always more complicated when working with LDAP...

Not tooo much of help unfortunately...

Regards,
Tomas
Save time and money with an Enterprise support subscription. Please see 
www.primekey.se for more information.
http://www.primekey.se/Products/EJBCA+PKI/
http://www.primekey.se/Services/Support/

On 2015-03-03 10:05, Michael Postmann wrote:
> Hi!
>
> When I create a new end entity with the name
> ‘CMS...@ex...’ an LDAP entry is
> published which has two DNs:
>
> ‘CMS_9999000451_001_test_blah_MAIL’ and
>
> ‘CMS_9999000451_001_test_blah_MAIL\=fo...@ex...’
>
> of which the former is used as the name for the entry.
>
> I’m wondering why the extra backslash is added and why there are two DNs.
>
> Any Ideas?
>
> As I need to replace an existing solution with EJBCA it is relatively
> complicated to change the syntax of the entity names. So I’m looking
> into fixing the publisher instead.
>
> Regards
>
> nomike
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
>
>
>
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>

[Ejbca-develop] Wrong DN in ldap publisher when using equas sign in entity name

[Michael P. <M.P...@pa...>]

Hi!

When I create a new end entity with the name 'CMS...@ex...' an LDAP entry is published which has two DNs:
'CMS_9999000451_001_test_blah_MAIL' and
'CMS_9999000451_001_test_blah_MAIL\=fo...@ex...'

of which the former is used as the name for the entry.

I'm wondering why the extra backslash is added and why there are two DNs.

Any Ideas?

As I need to replace an existing solution with EJBCA it is relatively complicated to change the syntax of the entity names. So I'm looking into fixing the publisher instead.

Regards
nomike

[Ejbca-develop] Supported Browser matrix for EJBCA Enterprise 6.2.2

[DESHAIES, F. <fra...@ca...>]

Hi,

Is there any supported Browser matrix for EJBCA Enterprise 6.2.2 ?

Thanks for your help,

Sincerely,

François Deshaies / Capgemini Secteur Industrie & Distribution / Paris
Architecte d'entreprise
Mobile : +33 6 89 37 94 79
People matter, results count.
_______________________________________________________________________
Capgemini is a trading name used by the Capgemini Group of companies which includes Capgemini Technology Services SAS,
a company registered in France  (RCS : 479 766 842 - APE 6202 A NANTERRE)
whose registered office is at  5/7, rue Frédéric Clavel - 92287 Suresnes cedex
P Please consider the environment and do not print this email unless absolutely necessary. Capgemini encourages environmental awareness.

This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.

Re: [Ejbca-develop] debug log ejbca.sh

[Tomas G. <to...@pr...>]

Https and Java is of course another topic than bcrypt performance.
 
You can implement various barriers and additional steps to further harden this access as well. We managed to be non affected by most of these vulnerabilities in our implementations. There is of course never any definite guarantee against vulnerabilities. 

Cheers, 
Tomas 

On February 27, 2015 9:41:00 AM GMT+01:00, "Michael Ströder" <mi...@st...> wrote:
>Tomas Gustavsson wrote:
>> That password should use a non brutable length.
>
>Yes, of course.
>
>> If you wish you can disable the command line interface completely
>even.
>
>I deliberately keep this enabled until it's sure that the admins take
>care of
>renewing their admin certs in time.
>
>> Anyhow, the cli password is only usable for the cli. If you manage to
>get
>> hold of it, you also need to manage to get access to the command line
>of
>> your CA, not so easy I hope.
>
>I also hope this and of course the operators are doing their best to
>harden
>the machines. But given all the really serious security threats in Java
>during
>the last 2 years I'm really concerned that I have to allow direct HTTPS
>access
>to adminweb for individual authentication/authorization with client
>certs.
>
>Letting components run under different OS accounts communicating over
>Unix
>Domain Sockets (or other OS pipes) would be really great.
>
>Ciao, Michael.
>
>
>
>------------------------------------------------------------------------
>
>------------------------------------------------------------------------------
>Dive into the World of Parallel Programming The Go Parallel Website,
>sponsored
>by Intel and developed in partnership with Slashdot Media, is your hub
>for all
>things parallel software development, from weekly thought leadership
>blogs to
>news, videos, case studies, tutorials and more. Take a look and join
>the 
>conversation now. http://goparallel.sourceforge.net/
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Ejbca-develop mailing list
>Ejb...@li...
>https://lists.sourceforge.net/lists/listinfo/ejbca-develop

Re: [Ejbca-develop] debug log ejbca.sh

[Michael S. <mi...@st...>]

Tomas Gustavsson wrote:
> That password should use a non brutable length.

Yes, of course.

> If you wish you can disable the command line interface completely even.

I deliberately keep this enabled until it's sure that the admins take care of
renewing their admin certs in time.

> Anyhow, the cli password is only usable for the cli. If you manage to get
> hold of it, you also need to manage to get access to the command line of
> your CA, not so easy I hope.

I also hope this and of course the operators are doing their best to harden
the machines. But given all the really serious security threats in Java during
the last 2 years I'm really concerned that I have to allow direct HTTPS access
to adminweb for individual authentication/authorization with client certs.

Letting components run under different OS accounts communicating over Unix
Domain Sockets (or other OS pipes) would be really great.

Ciao, Michael.

Re: [Ejbca-develop] debug log ejbca.sh

[Tomas G. <to...@pr...>]

That password should use a non brutable length. If you wish you can disable the command line interface completely even.

Anyhow, the cli password is only usable for the cli. If you manage to get hold of it, you also need to manage to get access to the command line of your CA, not so easy I hope. 


/Tomas 

On February 26, 2015 6:21:26 PM GMT+01:00, "Michael Ströder" <mi...@st...> wrote:
>Tomas Gustavsson wrote:
>> What's your use case? Why don't you use 24 character randomly
>generated one-time enrollment codes? 
>
>I'm not talking about enrollment codes. I'm talking about user and its
>log-term password used with ejbca.sh on a local system command-line
>(see subject).
>
>Since EJBCA is a monolithic web application with a single DB user
>accessing
>the whole database a SQL injection flaw could reveal the password hash
>to an
>attacker.
>
>I wish local connections could go over Unix Domain Socket and get
>authenticated based on Unix peer credentials making such a long-term
>password
>unnecessary. Same for accessing the local DB. But I guess that's pretty
>unusual (or even impossible) with Java.
>
>Ciao, Michael.
>
>
>
>------------------------------------------------------------------------
>
>------------------------------------------------------------------------------
>Dive into the World of Parallel Programming The Go Parallel Website,
>sponsored
>by Intel and developed in partnership with Slashdot Media, is your hub
>for all
>things parallel software development, from weekly thought leadership
>blogs to
>news, videos, case studies, tutorials and more. Take a look and join
>the 
>conversation now. http://goparallel.sourceforge.net/
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Ejbca-develop mailing list
>Ejb...@li...
>https://lists.sourceforge.net/lists/listinfo/ejbca-develop

Re: [Ejbca-develop] debug log ejbca.sh

[Michael S. <mi...@st...>]

Tomas Gustavsson wrote:
> What's your use case? Why don't you use 24 character randomly generated one-time enrollment codes? 

I'm not talking about enrollment codes. I'm talking about user and its
log-term password used with ejbca.sh on a local system command-line (see subject).

Since EJBCA is a monolithic web application with a single DB user accessing
the whole database a SQL injection flaw could reveal the password hash to an
attacker.

I wish local connections could go over Unix Domain Socket and get
authenticated based on Unix peer credentials making such a long-term password
unnecessary. Same for accessing the local DB. But I guess that's pretty
unusual (or even impossible) with Java.

Ciao, Michael.

Re: [Ejbca-develop] debug log ejbca.sh

[martijn.list <mar...@gm...>]

On 02/26/2015 05:48 PM, Tomas Gustavsson wrote:
> What's your use case? Why don't you use 24 character randomly generated
> one-time enrollment codes?
> 
> You can surely design your work-flow to be more secure, still giving a
> decent user experience, better than waiting 30 seconds in a browser window?

It also makes your application vulnerable to a DOS. If you try to login
with 100 parallel connections using random passwords, your server comes
to a grinding halt going through all the rounds. If you want to use this
many rounds, you should put the burden on the client. For example by
using javascript to go calculate all the rounds. Downside of this is
that javascript is probably too slow to make this acceptable.

Kind regards,

Martijn Brinkers

-- 
CipherMail email encryption

Open source email encryption gateway with support for S/MIME, OpenPGP
and PDF messaging.

http://www.ciphermail.com

Twitter: http://twitter.com/CipherMail

> On February 26, 2015 5:08:03 PM GMT+01:00, "Michael Ströder"
> <mi...@st...> wrote:
> 
>     Tomas Gustavsson wrote:
> 
>         What's your threat analysis?
>         Are you protecting against someone dumping the EJBCA database
>         trying to
>         brute-force one-time enrollment codes before they are being used?
> 
> 
>     Yes. Or a SQL injection revealing the user's password via web application.
> 
>         16 rounds is too slow even for a single use imho. On my laptop a
>         single
>         call (a single bcrypt) with 16 rounds takes >20 seconds.
> 
> 
>     The important factor is at what speed brute force attackers can work.
> 
>     Ciao, Michael.
> 
>     ------------------------------------------------------------------------
> 
>     Dive into the World of
>     Parallel Programming The Go Parallel Website, sponsored
>     by Intel and developed in partnership with Slashdot Media, is your hub for all
>     things parallel software development, from weekly thought leadership blogs to
>     news, videos, case studies, tutorials and more. Take a look and join the 
>     conversation now. http://goparallel.sourceforge.net/
> 
>     ------------------------------------------------------------------------
> 
>     Ejbca-develop mailing list
>     Ejb...@li...
>     https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> 
> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> 
> 
> 
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> 

Re: [Ejbca-develop] debug log ejbca.sh

[Tomas G. <to...@pr...>]

You know that you can limit how long an enrollment code is active? 


On February 26, 2015 5:48:06 PM GMT+01:00, Tomas Gustavsson <to...@pr...> wrote:
>What's your use case? Why don't you use 24 character randomly generated
>one-time enrollment codes? 
>
>You can surely design your work-flow to be more secure, still giving a
>decent user experience, better than waiting 30 seconds in a browser
>window? 
>
>Cheers, 
>Tomas 
>
>On February 26, 2015 5:08:03 PM GMT+01:00, "Michael Ströder"
><mi...@st...> wrote:
>>Tomas Gustavsson wrote:
>>> What's your threat analysis?
>>> Are you protecting against someone dumping the EJBCA database trying
>>to 
>>> brute-force one-time enrollment codes before they are being used?
>>
>>Yes. Or a SQL injection revealing the user's password via web
>>application.
>>
>>> 16 rounds is too slow even for a single use imho. On my laptop a
>>single 
>>> call (a single bcrypt) with 16 rounds takes >20 seconds.
>>
>>The important factor is at what speed brute force attackers can work.
>>
>>Ciao, Michael.
>>
>>
>>
>>------------------------------------------------------------------------
>>
>>------------------------------------------------------------------------------
>>Dive into the World of Parallel Programming The Go Parallel Website,
>>sponsored
>>by Intel and developed in partnership with Slashdot Media, is your hub
>>for all
>>things parallel software development, from weekly thought leadership
>>blogs to
>>news, videos, case studies, tutorials and more. Take a look and join
>>the 
>>conversation now. http://goparallel.sourceforge.net/
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>Ejbca-develop mailing list
>>Ejb...@li...
>>https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>
>
>------------------------------------------------------------------------
>
>------------------------------------------------------------------------------
>Dive into the World of Parallel Programming The Go Parallel Website,
>sponsored
>by Intel and developed in partnership with Slashdot Media, is your hub
>for all
>things parallel software development, from weekly thought leadership
>blogs to
>news, videos, case studies, tutorials and more. Take a look and join
>the 
>conversation now. http://goparallel.sourceforge.net/
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Ejbca-develop mailing list
>Ejb...@li...
>https://lists.sourceforge.net/lists/listinfo/ejbca-develop

Re: [Ejbca-develop] debug log ejbca.sh

[Tomas G. <to...@pr...>]

What's your use case? Why don't you use 24 character randomly generated one-time enrollment codes? 

You can surely design your work-flow to be more secure, still giving a decent user experience, better than waiting 30 seconds in a browser window? 

Cheers, 
Tomas 

On February 26, 2015 5:08:03 PM GMT+01:00, "Michael Ströder" <mi...@st...> wrote:
>Tomas Gustavsson wrote:
>> What's your threat analysis?
>> Are you protecting against someone dumping the EJBCA database trying
>to 
>> brute-force one-time enrollment codes before they are being used?
>
>Yes. Or a SQL injection revealing the user's password via web
>application.
>
>> 16 rounds is too slow even for a single use imho. On my laptop a
>single 
>> call (a single bcrypt) with 16 rounds takes >20 seconds.
>
>The important factor is at what speed brute force attackers can work.
>
>Ciao, Michael.
>
>
>
>------------------------------------------------------------------------
>
>------------------------------------------------------------------------------
>Dive into the World of Parallel Programming The Go Parallel Website,
>sponsored
>by Intel and developed in partnership with Slashdot Media, is your hub
>for all
>things parallel software development, from weekly thought leadership
>blogs to
>news, videos, case studies, tutorials and more. Take a look and join
>the 
>conversation now. http://goparallel.sourceforge.net/
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Ejbca-develop mailing list
>Ejb...@li...
>https://lists.sourceforge.net/lists/listinfo/ejbca-develop

Re: [Ejbca-develop] debug log ejbca.sh

[Michael S. <mi...@st...>]

Tomas Gustavsson wrote:
> What's your threat analysis?
> Are you protecting against someone dumping the EJBCA database trying to 
> brute-force one-time enrollment codes before they are being used?

Yes. Or a SQL injection revealing the user's password via web application.

> 16 rounds is too slow even for a single use imho. On my laptop a single 
> call (a single bcrypt) with 16 rounds takes >20 seconds.

The important factor is at what speed brute force attackers can work.

Ciao, Michael.

Re: [Ejbca-develop] debug log ejbca.sh

[Manuel D. <ma...@de...>]

*off-topic*
I cannot add any content to the original question of why this or that
command is so slow, but I'd like to comment on how the "rounds" of a
key derivation hash, see below.

On Thu, Feb 26, 2015 at 4:09 PM, Michael Ströder <mi...@st...> wrote:
> The only reasonable comment on the page above is the cause for the user's
> question:
>
> "The speed of my own system should not be leading for the number of
> iterations. It is the current speed of the brute-forcers that should dictate
> how many iterations are considered safe."
>
> Yes!!! The whole point of using a strong password hashing schemes is to
> protect against the brute force power of off-line attacks (hashcat with big
> graphic cards) and *not* the amount of time of local command invocation.

Not quite. Yes, it is the whole point of using a strong password
hashing scheme to protect against brute force attacks as much as
possible. The hashing mechanism should in itself already be safe. The
point of doing additional rounds is not to secure a single password.
The point of doing additional rounds is to push the safety margins as
far as possible before it hurts for normal operation of a single user
(logon, ...), SO THAT it does hurt (if) an attacker tries to crack a
long table/list of passwords that has been dumped somewhere or even
tries to brute force every conceivable combination of chars.

You are concerned about the security now and confidentiality in the
far future ? Then increase the number of rounds (or change the
password more often in the future, with steady higher number of
rounds) and live with the performance impact :)

of course, what I am saying here is helping neither of you, I am well
aware of that :)
cheers,
Manuel

Re: [Ejbca-develop] debug log ejbca.sh

[Tomas G. <to...@pr...>]

It all depends on what you are trying to protect against.

What's your threat analysis?
Are you protecting against someone dumping the EJBCA database trying to 
brute-force one-time enrollment codes before they are being used?

16 rounds is too slow even for a single use imho. On my laptop a single 
call (a single bcrypt) with 16 rounds takes >20 seconds.

/Tomas


On 2015-02-26 16:09, Michael Ströder wrote:
> Tomas Gustavsson wrote:
>>
>> Ok, as far as I can see there is:
>>
>> - One call starting the command (getting list of CA ids)
>> - One call for each CA in the system (getting detailed information for
>> the specific CA)
>>
>> So when your first CA shows up, you have run two bcrypt operations.
>
> So there is not kind of a session established between ejbca.sh and JBOSS.
>
>> Do you have very many CAs?
>
> Half a dozen, could be some more in the long run.
>
>> If you are using 16 rounds and it is too slow, I think you are using too
>> many rounds. The security of bcrypt is about how long time you want it
>> to take, so if it takes too long, you're using too many rounds.
>>
>> http://security.stackexchange.com/questions/17207/recommended-of-rounds-for-bcrypt
>
> The only reasonable comment on the page above is the cause for the user's
> question:
>
> "The speed of my own system should not be leading for the number of
> iterations. It is the current speed of the brute-forcers that should dictate
> how many iterations are considered safe."
>
> Yes!!! The whole point of using a strong password hashing schemes is to
> protect against the brute force power of off-line attacks (hashcat with big
> graphic cards) and *not* the amount of time of local command invocation.
>
> An acceptable timing using ejbca.sh is currently using 2^8 = 256 rounds but I
> guess this makes brute force programmers laught about.
>
> Ciao, Michael.
>
>> On 2015-02-26 08:19, Michael Ströder wrote:
>>> Tomas Gustavsson wrote:
>>>> It would be good if you include a little more of the original conversation.
>>>> What was the command you were running again that is slow?
>>>
>>> ejbca.sh ca editca --help (see old message attached below).
>>>
>>>> But, using bcrypt with many rounds does affect performance ;-)
>>>
>>> But I did not expect the impact to be so big and to vary for differnt
>>> commands. I suspect the password is checked many times for some commands. Right?
>>>
>>> I'm currently using ejbca.passwordlogrounds=8 for acceptable performance which
>>> is not that much for *the* sensitive admin password.
>>>
>>> Ciao, Michael.
>>>
>>> -------- Forwarded Message --------
>>> Subject: [Ejbca-develop] ejbca.sh slow
>>> Date: Wed, 26 Nov 2014 15:35:24 +0100
>>> From: Michael Ströder <mi...@st...>
>>> Reply-To: ejb...@li...
>>> To: ejb...@li...
>>>
>>> HI!
>>>
>>> I'm having a hard time finding out why sometimes (not always) ejbca.sh is so
>>> damn slow:
>>>
>>> root@vm-ejbca-ocsp-01:~# time /opt/ejbca/bin/ejbca.sh ca --help
>>> [..]
>>> real	0m2.251s
>>> user	0m2.748s
>>> sys	0m0.288s
>>> root@vm-ejbca-ocsp-01:~# time /opt/ejbca/bin/ejbca.sh ca editca --help
>>> [..]
>>> real	0m25.008s
>>> user	0m18.069s
>>> sys	0m0.192s
>>>
>>> I'm looking with strace and tcpdump what's going on. But still nothing obvious.
>>>
>>> Which debug logs should I enable in the JVM?
>>>
>>> BTW: Any reason why using --help requires a running JBOSS?
>>>
>>> Ciao, Michael.
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
>>> by Intel and developed in partnership with Slashdot Media, is your hub for all
>>> things parallel software development, from weekly thought leadership blogs to
>>> news, videos, case studies, tutorials and more. Take a look and join the
>>> conversation now. http://goparallel.sourceforge.net/
>>>
>>>
>>>
>>> _______________________________________________
>>> Ejbca-develop mailing list
>>> Ejb...@li...
>>> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub for all
>> things parallel software development, from weekly thought leadership blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Ejbca-develop mailing list
>> Ejb...@li...
>> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>>
>
>
> --
> Michael Ströder                 Klauprechtstr. 11
> Dipl.-Inform.                   D-76137 Karlsruhe, Germany
> Tel.: +49 721 8304316           Mobil: +49 170 2391920
> E-Mail: mi...@st...    http://www.stroeder.com
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
>
>
>
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>

Re: [Ejbca-develop] debug log ejbca.sh

[Michael S. <mi...@st...>]

Tomas Gustavsson wrote:
> 
> Ok, as far as I can see there is:
> 
> - One call starting the command (getting list of CA ids)
> - One call for each CA in the system (getting detailed information for 
> the specific CA)
> 
> So when your first CA shows up, you have run two bcrypt operations.

So there is not kind of a session established between ejbca.sh and JBOSS.

> Do you have very many CAs?

Half a dozen, could be some more in the long run.

> If you are using 16 rounds and it is too slow, I think you are using too 
> many rounds. The security of bcrypt is about how long time you want it 
> to take, so if it takes too long, you're using too many rounds.
> 
> http://security.stackexchange.com/questions/17207/recommended-of-rounds-for-bcrypt

The only reasonable comment on the page above is the cause for the user's
question:

"The speed of my own system should not be leading for the number of
iterations. It is the current speed of the brute-forcers that should dictate
how many iterations are considered safe."

Yes!!! The whole point of using a strong password hashing schemes is to
protect against the brute force power of off-line attacks (hashcat with big
graphic cards) and *not* the amount of time of local command invocation.

An acceptable timing using ejbca.sh is currently using 2^8 = 256 rounds but I
guess this makes brute force programmers laught about.

Ciao, Michael.

> On 2015-02-26 08:19, Michael Ströder wrote:
>> Tomas Gustavsson wrote:
>>> It would be good if you include a little more of the original conversation.
>>> What was the command you were running again that is slow?
>>
>> ejbca.sh ca editca --help (see old message attached below).
>>
>>> But, using bcrypt with many rounds does affect performance ;-)
>>
>> But I did not expect the impact to be so big and to vary for differnt
>> commands. I suspect the password is checked many times for some commands. Right?
>>
>> I'm currently using ejbca.passwordlogrounds=8 for acceptable performance which
>> is not that much for *the* sensitive admin password.
>>
>> Ciao, Michael.
>>
>> -------- Forwarded Message --------
>> Subject: [Ejbca-develop] ejbca.sh slow
>> Date: Wed, 26 Nov 2014 15:35:24 +0100
>> From: Michael Ströder <mi...@st...>
>> Reply-To: ejb...@li...
>> To: ejb...@li...
>>
>> HI!
>>
>> I'm having a hard time finding out why sometimes (not always) ejbca.sh is so
>> damn slow:
>>
>> root@vm-ejbca-ocsp-01:~# time /opt/ejbca/bin/ejbca.sh ca --help
>> [..]
>> real	0m2.251s
>> user	0m2.748s
>> sys	0m0.288s
>> root@vm-ejbca-ocsp-01:~# time /opt/ejbca/bin/ejbca.sh ca editca --help
>> [..]
>> real	0m25.008s
>> user	0m18.069s
>> sys	0m0.192s
>>
>> I'm looking with strace and tcpdump what's going on. But still nothing obvious.
>>
>> Which debug logs should I enable in the JVM?
>>
>> BTW: Any reason why using --help requires a running JBOSS?
>>
>> Ciao, Michael.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub for all
>> things parallel software development, from weekly thought leadership blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>>
>>
>>
>> _______________________________________________
>> Ejbca-develop mailing list
>> Ejb...@li...
>> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>>
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> 


--
Michael Ströder                 Klauprechtstr. 11
Dipl.-Inform.                   D-76137 Karlsruhe, Germany
Tel.: +49 721 8304316           Mobil: +49 170 2391920
E-Mail: mi...@st...    http://www.stroeder.com

Re: [Ejbca-develop] debug log ejbca.sh

[Tomas G. <to...@pr...>]

Ok, as far as I can see there is:

- One call starting the command (getting list of CA ids)
- One call for each CA in the system (getting detailed information for 
the specific CA)

So when your first CA shows up, you have run two bcrypt operations.

Do you have very many CAs?

If you are using 16 rounds and it is too slow, I think you are using too 
many rounds. The security of bcrypt is about how long time you want it 
to take, so if it takes too long, you're using too many rounds.

http://security.stackexchange.com/questions/17207/recommended-of-rounds-for-bcrypt

Regards,
Tomas


On 2015-02-26 08:19, Michael Ströder wrote:
> Tomas Gustavsson wrote:
>> It would be good if you include a little more of the original conversation.
>> What was the command you were running again that is slow?
>
> ejbca.sh ca editca --help (see old message attached below).
>
>> But, using bcrypt with many rounds does affect performance ;-)
>
> But I did not expect the impact to be so big and to vary for differnt
> commands. I suspect the password is checked many times for some commands. Right?
>
> I'm currently using ejbca.passwordlogrounds=8 for acceptable performance which
> is not that much for *the* sensitive admin password.
>
> Ciao, Michael.
>
> -------- Forwarded Message --------
> Subject: [Ejbca-develop] ejbca.sh slow
> Date: Wed, 26 Nov 2014 15:35:24 +0100
> From: Michael Ströder <mi...@st...>
> Reply-To: ejb...@li...
> To: ejb...@li...
>
> HI!
>
> I'm having a hard time finding out why sometimes (not always) ejbca.sh is so
> damn slow:
>
> root@vm-ejbca-ocsp-01:~# time /opt/ejbca/bin/ejbca.sh ca --help
> [..]
> real	0m2.251s
> user	0m2.748s
> sys	0m0.288s
> root@vm-ejbca-ocsp-01:~# time /opt/ejbca/bin/ejbca.sh ca editca --help
> [..]
> real	0m25.008s
> user	0m18.069s
> sys	0m0.192s
>
> I'm looking with strace and tcpdump what's going on. But still nothing obvious.
>
> Which debug logs should I enable in the JVM?
>
> BTW: Any reason why using --help requires a running JBOSS?
>
> Ciao, Michael.
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
>
>
>
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>

Re: [Ejbca-develop] debug log ejbca.sh

[Michael S. <mi...@st...>]

Tomas Gustavsson wrote:
> It would be good if you include a little more of the original conversation.
> What was the command you were running again that is slow?

ejbca.sh ca editca --help (see old message attached below).

> But, using bcrypt with many rounds does affect performance ;-) 

But I did not expect the impact to be so big and to vary for differnt
commands. I suspect the password is checked many times for some commands. Right?

I'm currently using ejbca.passwordlogrounds=8 for acceptable performance which
is not that much for *the* sensitive admin password.

Ciao, Michael.

-------- Forwarded Message --------
Subject: [Ejbca-develop] ejbca.sh slow
Date: Wed, 26 Nov 2014 15:35:24 +0100
From: Michael Ströder <mi...@st...>
Reply-To: ejb...@li...
To: ejb...@li...

HI!

I'm having a hard time finding out why sometimes (not always) ejbca.sh is so
damn slow:

root@vm-ejbca-ocsp-01:~# time /opt/ejbca/bin/ejbca.sh ca --help
[..]
real	0m2.251s
user	0m2.748s
sys	0m0.288s
root@vm-ejbca-ocsp-01:~# time /opt/ejbca/bin/ejbca.sh ca editca --help
[..]
real	0m25.008s
user	0m18.069s
sys	0m0.192s

I'm looking with strace and tcpdump what's going on. But still nothing obvious.

Which debug logs should I enable in the JVM?

BTW: Any reason why using --help requires a running JBOSS?

Ciao, Michael.

Re: [Ejbca-develop] debug log ejbca.sh

[Tomas G. <to...@pr...>]

It would be good if you include a little more of the original conversation. What was the command you were running again that is slow? 

But, using bcrypt with many rounds does affect performance ;-) 

Cheers, 
Tomas 

On February 25, 2015 9:45:02 PM GMT+01:00, "Michael Ströder" <mi...@st...> wrote:
>Michael Ströder wrote:
>> this issue is still driving me crazy... :-[
>> 
>> ejbca.sh ca listcas takes nearly a minute on different systems.
>
>A colleague found out that it took so much time because I set
>
>ejbca.passwordlogrounds=16
>
>It seems to me that the password check with the 2^16 rounds is
>performed many
>times, not only once within kind of a session.
>
>Ciao, Michael.