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.
