jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Increase validity duration of JMeter Root CA
Date Fri, 27 Jul 2018 00:34:06 GMT
On 26 July 2018 at 17:51, Philippe Mouawad
<p.mouawad@ubik-ingenierie.com> wrote:
> In this case, I let you revert code.

I see Felix has just done this - thanks.

> Regarding the incomplete analysis, please expose on  private how to do that.

Done.

> Thank you
>
> On Thursday, July 26, 2018, sebb <sebbaz@gmail.com> wrote:
>
>> On 26 July 2018 at 07:10, Philippe Mouawad <philippe.mouawad@gmail.com>
>> wrote:
>> > On Thursday, July 26, 2018, sebb <sebbaz@gmail.com> wrote:
>> >
>> >> On 25 July 2018 at 21:14, Philippe Mouawad <philippe.mouawad@gmail.com>
>> >> wrote:
>> >> > Hello,
>> >> > For now I increase validity to 3 months as there is a majority that
>> >> agrees.
>> >>
>> >> There is also a -1 from me.
>> >>
>> >> It is wrong to unilaterally change the default without giving the
>> >> users the chance to agree to the reduction in security.
>> >
>> >
>> > IMO, Issue was discussed and although you have a -1, there are 3 +1 and
>> > Felix looks neutral.
>>
>> Since this is a code change, my -1 is a veto.
>> That needs to be resolved.
>>
>> > From my understanding of your question to sec team, there is nothing
>> > blocker in terms of security here.
>> >
>> >
>> >> What are your plans to alert the users to the change?
>> >
>> >
>> > I ‘ll add a breaking change but you can add it to also if you think
>> you’ll
>> > be more clear.
>>
>> I think the user needs to agree to the change; it should not be forced
>> upon them.
>>
>> Note the response from Srijon Das else-thread.
>>
>> >>
>> >> > I guess in the future, Felix's proposal i better, but meanwhile, let's
>> >> > increase usability.
>> >>
>> >> No, that's just wrong.
>> >> Usability should not be done at the expense of security.
>> >
>> >
>> > That’s not my understanding of sec team answer and Milamber also
>> confirmed
>> > the risk was nearly the same.
>>
>> I think his analysis of the risk was incomplete.
>> I think it's possible to steal the cert and the password without
>> needing shell access to the host.
>>
>> > If you think things should be better, you ‘re welcome to propose a patch:
>> > - evolution of templating system to allow parameters and could be reused
>> > anywhere, for example on test plan creation
>> > - custom dialog to ask user for validity
>> >
>> > But status quo is not an option IMO.
>> > Security is very important to me, as you can see it per my involvement in
>> > fixing and helping on CVE report management, but when there is no real
>> > argument I don’t see why usability should be affected, UX is critical for
>> > tool adoption and perenity, and it looks like issue is a real one as per
>> > report from a user on this mail topic, as per my daily usage of JMeter
>> and
>> > as per trainings my company gives on it.
>> >
>> >>
>> >> > Regards
>> >> >
>> >> > On Thu, Jul 19, 2018 at 8:11 PM, Felix Schumacher <
>> >> > felix.schumacher@internetallee.de> wrote:
>> >> >
>> >> >> Would the addition of such a message remove the need for a longer
>> >> default
>> >> >> period?
>> >> >>
>> >> >> Or should we even let the user decide on generation how long it
>> should
>> >> be
>> >> >> valid? (with a short default like the seven days we currently have.)
>> >> >>
>> >> >> Felix
>> >> >>
>> >> >>
>> >> >>
>> >> >> Am 19.07.2018 um 15:06 schrieb Philippe Mouawad:
>> >> >>
>> >> >>> What ????
>> >> >>> You didn't read the manual :-) ?????
>> >> >>>
>> >> >>>
>> >> >>> Just kidding :-)
>> >> >>>
>> >> >>> Thanks for your ideas
>> >> >>>
>> >> >>> On Thu, Jul 19, 2018 at 3:05 PM, Srijon Das <srijondas@gmail.com>
>> >> wrote:
>> >> >>>
>> >> >>> I was not aware that it is a configuration.
>> >> >>>>
>> >> >>>> Usually I see a pop-up which mentions that certificate
is valid
>> for 7
>> >> >>>> days. Maybe we could mention that changing the config
>> >> proxy.cert.validity
>> >> >>>> will change the validity of the certificate.
>> >> >>>>
>> >> >>>> Sent from my iPhone
>> >> >>>>
>> >> >>>> On Jul 19, 2018, at 5:53 AM, Philippe Mouawad <
>> >> >>>>>
>> >> >>>> philippe.mouawad@gmail.com> wrote:
>> >> >>>>
>> >> >>>>> Hello,
>> >> >>>>> See:
>> >> >>>>> http://jmeter.apache.org/usermanual/properties_
>> >> >>>>>
>> >> >>>> reference.html#test_script_recorder_cert
>> >> >>>>
>> >> >>>>> The property is:
>> >> >>>>> proxy.cert.validity
>> >> >>>>>
>> >> >>>>> How would you like it improved ?
>> >> >>>>>
>> >> >>>>> Thanks
>> >> >>>>>
>> >> >>>>> On Thu, Jul 19, 2018 at 2:50 PM, Srijon Das <srijondas@gmail.com>
>> >> >>>>>>
>> >> >>>>> wrote:
>> >> >>>>
>> >> >>>>> As a longtime jmeter user, I would like the option
to decide how
>> >> long my
>> >> >>>>>> certificates will be valid, 1 week, 2 weeks, 3
weeks etc.  And
>> >> perhaps
>> >> >>>>>> a
>> >> >>>>>> warning describing the consequences of the security
>> vulnerabilities.
>> >> >>>>>>
>> >> >>>>>> Most jmeter users, I feel will be in a position
to judge the
>> >> security
>> >> >>>>>>
>> >> >>>>> risk
>> >> >>>>
>> >> >>>>> themselves and use the certificate accordingly.
>> >> >>>>>>
>> >> >>>>>> Sent from my iPhone
>> >> >>>>>>
>> >> >>>>>> On Jul 19, 2018, at 4:06 AM, Milamber <milamber@apache.org>
>> wrote:
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>> On 19/07/2018 11:03, Philippe Mouawad wrote:
>> >> >>>>>>>>> On Thu, Jul 19, 2018 at 11:56 AM, sebb
<sebbaz@gmail.com>
>> wrote:
>> >> >>>>>>>>>
>> >> >>>>>>>>> On 19 July 2018 at 10:34, Philippe
Mouawad <
>> >> >>>>>>>>>
>> >> >>>>>>>> philippe.mouawad@gmail.com
>> >> >>>>
>> >> >>>>> wrote:
>> >> >>>>>>>>>
>> >> >>>>>>>>>> On Thu, Jul 19, 2018 at 11:31 AM,
sebb <sebbaz@gmail.com>
>> >> wrote:
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>> On 19 July 2018 at 10:28, Philippe
Mouawad <
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>> philippe.mouawad@gmail.com>
>> >> >>>>>>
>> >> >>>>>>> wrote:
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>>> Hello sebb,
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> Yes users can change, but
once again, it means adjusting
>> >> >>>>>>>>>>>> defaults,
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>> knowing
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>>> they can be adjusted and
which property it is.
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>> That can be documented.
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>> Which means all users read
the whole documentation, do you
>> >> think
>> >> >>>>>>>>>>
>> >> >>>>>>>>> they
>> >> >>>>
>> >> >>>>> do
>> >> >>>>>>
>> >> >>>>>>> ?
>> >> >>>>>>>>>
>> >> >>>>>>>>>> I guess you know the famous RTFM
:-)
>> >> >>>>>>>>>>
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> Why not make defaults better for
usability ?
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>> Because it compromises security.
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>> Can you give more details ?
>> >> >>>>>>>>>>
>> >> >>>>>>>>> The point of a CA is to certify that
a certificate chain is
>> >> valid.
>> >> >>>>>>>>> Locally generated CA certs do not do
this.
>> >> >>>>>>>>> Once the cert has been approved by
the browser, it can be
>> used to
>> >> >>>>>>>>> certify anything, including a spoof
bank site etc.
>> >> >>>>>>>>>
>> >> >>>>>>>>> JMeter users may not understand that,
and so may not take
>> >> sufficient
>> >> >>>>>>>>> care of the certificate and its password.
>> >> >>>>>>>>> Or they may forget that the cert has
been added to the
>> browser.
>> >> >>>>>>>>>
>> >> >>>>>>>>> Even some official CAs have inadvertently
exposed their certs.
>> >> >>>>>>>>>
>> >> >>>>>>>>> I don't think we should ship JMeter
with deliberately weak
>> >> settings.
>> >> >>>>>>>>>
>> >> >>>>>>>>> Yes it may be inconvenient, but it
is deliberately done to
>> >> minimise
>> >> >>>>>>>>> the effects of accidental certificate
exposure.
>> >> >>>>>>>>>
>> >> >>>>>>>>> Users that understand the risks can
override the setting, but
>> >> that
>> >> >>>>>>>>> is
>> >> >>>>>>>>> at their own risk.
>> >> >>>>>>>>>
>> >> >>>>>>>>> Remember that once the browser has
stored the CA, it will be
>> >> active
>> >> >>>>>>>>> regardless of whether JMeter is actually
being used.
>> >> >>>>>>>>> So the sooner it expires, the safer
it is.
>> >> >>>>>>>>> Maybe a week is too *long*.
>> >> >>>>>>>>>
>> >> >>>>>>>>> I am aware of that, but it means attacker
has accessed the
>> >> machine
>> >> >>>>>>>> of
>> >> >>>>>>>>
>> >> >>>>>>> user
>> >> >>>>>>
>> >> >>>>>>> to get the CA.
>> >> >>>>>>>> So the JMeter side is only a consequence,
not root cause
>> >> >>>>>>>>
>> >> >>>>>>>
>> >> >>>>>>> The risk is the same if the duration is 7 days
or 3 months,
>> because
>> >> >>>>>>> the
>> >> >>>>>>>
>> >> >>>>>> attacker need to have access to the private key
of the temp
>> JMeter
>> >> CA
>> >> >>>>>>
>> >> >>>>> root
>> >> >>>>
>> >> >>>>> to generate some fake cert signed by the CA. This private
key is
>> on
>> >> the
>> >> >>>>>> machine (keystore.jks)
>> >> >>>>>>
>> >> >>>>>>> And if an attacker have already an access to
the machine, it's
>> can
>> >> add
>> >> >>>>>>>
>> >> >>>>>> directly another CA (not JMeter CA) into the certs
vault on the
>> >> >>>>>>
>> >> >>>>> machine, to
>> >> >>>>
>> >> >>>>> made some malicious opérations...
>> >> >>>>>>
>> >> >>>>>>> 3 months seems good for me (this is the mean
duration for my
>> load
>> >> test
>> >> >>>>>>>
>> >> >>>>>> missions)
>> >> >>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>> It looks like 3 months would be good for Bruno,
Antonio, me.
>> >> >>>>>>>>>>>> Is it really a blocker
for you ? if yes why ?
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>> As above.
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>> @Others what's your opinion
?
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> Thanks
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> On Thu, Jul 19, 2018 at
10:55 AM, sebb <sebbaz@gmail.com>
>> >> wrote:
>> >> >>>>>>>>>>>>>
>> >> >>>>>>>>>>>>> It's a trade-off between
convenience and security.
>> >> >>>>>>>>>>>>>
>> >> >>>>>>>>>>>>> It's risky adding the
certificate to the browser.
>> >> >>>>>>>>>>>>>
>> >> >>>>>>>>>>>>> I don't think the default
should be changed.
>> >> >>>>>>>>>>>>>
>> >> >>>>>>>>>>>>> Users can always change
it themselves if they accept the
>> >> risks.
>> >> >>>>>>>>>>>>> E.g. if they use a
separate browser installation that has
>> >> >>>>>>>>>>>>>
>> >> >>>>>>>>>>>> certificate,
>> >> >>>>>>>>>
>> >> >>>>>>>>>> then a longer validity is more
sensible.
>> >> >>>>>>>>>>>>> It's too easy to forget
that the cert has been added to
>> the
>> >> >>>>>>>>>>>>>
>> >> >>>>>>>>>>>> browser.
>> >> >>>>>>
>> >> >>>>>>> S.
>> >> >>>>>>>>>>>>> On 19 July 2018 at
09:35, Antonio Gomes Rodrigues <
>> >> >>>>>>>>>>>>>
>> >> >>>>>>>>>>>> ra0077@gmail.com>
>> >> >>>>>>
>> >> >>>>>>> wrote:
>> >> >>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>> +1 for me
>> >> >>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>> Le jeu. 19 juil.
2018 à 10:27, Philippe Mouawad <
>> >> >>>>>>>>>>>>>> p.mouawad@ubik-ingenierie.com>
a écrit :
>> >> >>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>> Hello,
>> >> >>>>>>>>>>>>>>> Currently :
>> >> >>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>    - proxy.cert.validity=7
>> >> >>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>> This is annoying
for users who must remember to add the
>> >> ROOT
>> >> >>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>> JMeter
>> >> >>>>>>>>>
>> >> >>>>>>>>>> certificate to browser every week
.
>> >> >>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>> I would suggest
setting it to 1 year or at least 1
>> month.
>> >> >>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>> Regards
>> >> >>>>>>>>>>>>>>> Philippe
>> >> >>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>> --
>> >> >>>>>>>>>>>> Cordialement.
>> >> >>>>>>>>>>>> Philippe Mouawad.
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>> --
>> >> >>>>>>>>>> Cordialement.
>> >> >>>>>>>>>> Philippe Mouawad.
>> >> >>>>>>>>>>
>> >> >>>>>>>>>
>> >> >>>>>>>>
>> >> >>>>>
>> >> >>>>> --
>> >> >>>>> Cordialement.
>> >> >>>>> Philippe Mouawad.
>> >> >>>>>
>> >> >>>>
>> >> >>>
>> >> >>>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > Cordialement.
>> >> > Philippe Mouawad.
>> >>
>> >
>> >
>> > --
>> > Cordialement.
>> > Philippe Mouawad.
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
> Ubik-Ingénierie
>
> UBIK LOAD PACK Web Site <http://www.ubikloadpack.com/>
>
> UBIK LOAD PACK on TWITTER <https://twitter.com/ubikloadpack>

Mime
View raw message