On 26 July 2018 at 17:51, Philippe Mouawad
<[email protected]> 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 <[email protected]> wrote:
>
>> On 26 July 2018 at 07:10, Philippe Mouawad <[email protected]>
>> wrote:
>> > On Thursday, July 26, 2018, sebb <[email protected]> wrote:
>> >
>> >> On 25 July 2018 at 21:14, Philippe Mouawad <[email protected]>
>> >> 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 <
>> >> > [email protected]> 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 <[email protected]>
>> >> 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 <
>> >> >>>>>
>> >> >>>> [email protected]> 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 <[email protected]>
>> >> >>>>>>
>> >> >>>>> 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 <[email protected]>
>> wrote:
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>> On 19/07/2018 11:03, Philippe Mouawad wrote:
>> >> >>>>>>>>> On Thu, Jul 19, 2018 at 11:56 AM, sebb <[email protected]>
>> wrote:
>> >> >>>>>>>>>
>> >> >>>>>>>>> On 19 July 2018 at 10:34, Philippe Mouawad <
>> >> >>>>>>>>>
>> >> >>>>>>>> [email protected]
>> >> >>>>
>> >> >>>>> wrote:
>> >> >>>>>>>>>
>> >> >>>>>>>>>> On Thu, Jul 19, 2018 at 11:31 AM, sebb <[email protected]>
>> >> wrote:
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>> On 19 July 2018 at 10:28, Philippe Mouawad <
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>> [email protected]>
>> >> >>>>>>
>> >> >>>>>>> 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 <[email protected]>
>> >> 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 <
>> >> >>>>>>>>>>>>>
>> >> >>>>>>>>>>>> [email protected]>
>> >> >>>>>>
>> >> >>>>>>> wrote:
>> >> >>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>> +1 for me
>> >> >>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>> Le jeu. 19 juil. 2018 à 10:27, Philippe Mouawad <
>> >> >>>>>>>>>>>>>> [email protected]> 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>

Reply via email to