jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: KeyStore and SSL Manager
Date Sat, 05 Nov 2011 13:30:20 GMT
On 5 November 2011 12:32, Philippe Mouawad <philippe.mouawad@gmail.com> wrote:
> On Sat, Nov 5, 2011 at 12:10 PM, sebb <sebbaz@gmail.com> wrote:
>
>> In earlier versions of JMeter, the client keystore relied on the
>> system property javax.net.ssl.keyStore.
>> This could either be set by the user prior to starting the test, or
>> the SSL Manager Option menu item could be used to set the system
>> property which would be picked up later.
>>
>> There is also the javax.net.ssl.keyStoreType property which is
>> normally used to determine the store type, and
>> javax.net.ssl.keyStorePassword for the password.
>>
>> See
>> http://download.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#Customization
>>
>> I think it would probably make sense to use these properties to
>> directly configure the key and trust stores.
>>
>> So I propose to change KeyStore Config so it behaves like the SSL
>> Manager Option dialogue, i.e. it will just save any settings as System
>> or JMeter properties.
>>
> Not sure I understand this part.
> If you're talking about the popup that asks for password when it does not
> find System property ,
>  I don't find it very "User friendly" and I remember being a bit confused
> about it when I started using JMeter with HTTPS.
>
> It would make also make sense to merge it with the SSL Manager dialogue.

Sorry, what I meant was:
- use the code strategy from SSL Manager Option, i.e. save filename as
system property
- extend the new KeyStore Config to include other config options.

>> This is currently only of use in GUI test runs - it cannot be saved
>> with a test plan.
>>
>> KeyStore Config should probably be renamed as SSL Config, and would
>> have additional fields to define the other SSL System properties.
>> This would be entirely optional - users could define the system or
>> JMeter properties instead - but would be more flexible as the settings
>> would be stored in the plan, not in external file(s).
>>
>
> I agree with this if you mean  SSL Config component will store:
> - Current options
> - + System properties used to configure Keystore path, password and others

Yes, that's the plan.

>>
>> The properties can be defined in the SSL Config testStarted() method
>> as that runs before the HTTP Sampler testStarted() method.
>> The latter can be used to preload the SSLManager if required; this
>> would allow SSL Config to be omitted, provided that the appropriate
>> JMeter property was set.
>>
>> To summarise:
>> - keystore and truststore would be initialised based purely on System
>> or JMeter property settings
>>
> Do you mean these properties can be defined:
> - In System properties

Yes, for javax.ssl properties

> - In JMeter properties

Yes, for JMeter-specific properties (e.g. alias indexes, loading strategy)

> - IN SSL config that would override default settings

Yes, the new SSL Config would overwrite any existing properties.

Just realised there's an issue with how to handle pre-existing settings.
If the user provides a value in the GUI, we should use that.
However, if no value is provided, does that mean the property should
be left alone, or does that mean it should be removed?

The NOT_UNDEFINED setting could be used for this. If enabled, the user
can choose "Undefined", in which case the existing setting should be
ignored.
Otherwise, if the user does not provide a value, any default will be used.

There's also an minor issue with multiple test runs (GUI mode only) -
if the Config element changes any system properties, then a subsequent
run will pick up the new settings. If the user previously defined (or
undefined) a property, they would need to be aware of this, and change
the settings accordingly.

>
>> - SSL Config GUI would allow the settings to be overridden as necessary
>>
>> Does this all make sense?
>>
>
> I agree it's a good idea to have on Config Element in test plan to
> configure these properties if it's what you mean.

Yes.

> In my opinion, we should remove the popup in SSLManager#getPassword,
> because it makes a different behaviour
> wether you are in GUI mode or NON GUI:

Yes, the plan was to remove it.

>   - In GUI mode you will be asked for password so you will think your test
>   works
>   - In Non GUI you will have a failure

Exactly, that's the problem now.

>
>
> --
> Cordialement.
> Philippe Mouawad.
>

Mime
View raw message