jmeter-dev mailing list archives

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

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