jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Increase validity duration of JMeter Root CA
Date Thu, 26 Jul 2018 06:10:52 GMT
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.

>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 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.

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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message