* Nicolas Évrard: " Re: [tryton-dev] Impact mitigation for DDoS attack" (Wed, 14 Feb 2018 13:55:48 +0100):
Hello again, > * Mathias Behrle [2018-02-14 12:17 +0100]: >>* Nicolas Évrard: " Re: [tryton-dev] Impact mitigation for DDoS attack" (Wed, >> 14 Feb 2018 10:46:38 +0100): >> >>Hi together, > > Hello, > >>I am still missing a thorough handling of the _several_ _different_ involved >>issues as proposed in >> >>https://bugs.tryton.org/issue5375 (specifically >>https://bugs.tryton.org/msg24691) > > Quite frankly I don't think there is much to discuss in this message. > But you might elaborate more on the issue so that I can understand > what should be discussed. There are 3 topics explicitely identified. Could you please elaborate what you don't understand? >>and >> >>https://bugs.tryton.org/issue7111 (specifically >>https://bugs.tryton.org/msg38228) > > - Session management: there is a recent issue about that To which issue are you refering exactly, a quick search on the bugtracker didn't reveal any hit [1]? > - Login delay: we can discuss it at length, the policy we have > won't change for the reasons exposed by Cédric in another email > But as my review on appspot displays if people want they can use > a different strategy. Thanks for that. It is a bit complicated to find that review under a totally unrelated topic (Remove openSUSE packages) https://bugs.tryton.org/issue7111 > https://bugs.tryton.org/msg38228 > https://bugzilla.opensuse.org/show_bug.cgi?id=1078111 > https://bugzilla.opensuse.org/show_bug.cgi?id=1078111#c19 > https://codereview.appspot.com/335550043/ Wouldn't it be worth to post that example of a possible modification on a more prominent place? > - Usability aspects: I don't understand what you mean You shortened the complete sentence which was - Usability aspects (as in punishment of wrong password entries and with regard to distributions in general) I want to elaborate on the two given examples: - punishment of wrong password entries While there was a lot of input and I would say agreement, that there *has* to be a login delay, there was never agreement about the duration. The exponential login timeout in terms of brute force attack is fairly oversized. So when you want to keep that absolutely we comes to usability aspects in terms of user friendlyness: a well concepted login manager (e.g. on android) doesn't let the user in the dark, but tells him, that after a failed login he has to wait for x seconds and then counts them down. The Tryton GTK-interface instead just goes unresponsive giving the impression of a hanging application. There is great probability that a half-experienced user will just hard kill it, because he thinks there is going something wrong. - and with regard to distributions in general Speaking with my Debian maintainer hat on I consider the step taken in https://bugs.tryton.org/issue7111 as regrettably and wrong. - I can not see how the mere *listing* of distributions on the website can be considered an *advice*. - Shouldn't it be just a sign of mutual respect for both sides? Distributions should be happy about the existence of Tryton and in the same way Tryton should be glad to be recognized and integrated into the major distributions. Glad to here your and the general input on this subject. - Compared to some other security related topics issue7111 is highly exaggerated. What will the foundation or the maintainer do about sao where the maintained series will be affected by a security-wise unmaintained jquery version? Have a look at https://bugs.tryton.org/issue5925 which was created at 2016-10-03.16:09:27. The referenced issue [2] to justify the now impending upgrade dates from 2016-10-06. It was already clear at the time of the creation of issue5925 that bootstrap 3.3.7 supports jquery 3+, but there was no action taken. Sao now will suffer in all currently maintained stable series from the usage of an unsupported jquery version. Will that lead to a big fat warning on the website or to the removal of sao <= 4.6? > - Hardening of trytond against brute force attack: It's linked to > the login delay. If you're able to display another kind of > attack vector please open a security issue I would have prefered to have the discussion at discuss.tryton.org or at least bugs.tryton.org. Unfortunately the further discussion of this topic happened on the OpenSUSE tracker.The last comment is https://bugzilla.opensuse.org/show_bug.cgi?id=1078111#c22 with the proposal of a patch that is uncommented so far. > - Hardening trytond agains DDOS attack: we can also discuss it at > length on the mailing list but in the end we all agree that it > involves a lot of different systems and there is not really a > final solution to this issue A lot of different systems involved, true. Especially when Tryton loads off the resource limits to the database backend. Unfortunately the interest of the maintainer to put that load off to other configurable backends seems to be non-existent. This is at least what I got for a proposal pointing this way earlier in this thread: nothing. > - Responsibility about decision taking in the project: It should > be a new thread. Ideally it should be a community decision but > the problem arise when there is no clear consensus, in this case > I see two realms: > > - the marketing (website, twitter, etc): the foundation has > the last word > > - the code: Cédric has the last word > > Since the beginning the project is based on a BDFL style and I > think that's the best way to do it. It's inspired by python > and numerous other projects that work this way. My personal view from reading the foundation statutes [3] is that the foundation is empowered to much more than just marketing. I will appreciate a public statement of the foundation which responsibilities are covered by its work. > - Attitude and mindset towards downstream / distribution: > > - We could promote more downstream users of Tryton, yet we > have business cases and nothing prevents anyone of > submitting new cases according to our rules. We have one > about coog, I would be delighted to have one about a GNU > Health implementation. > > - distribution: The fact that distributions package Tryton is > obviously a good thing. But on the other hand I think we can > not let pass some patches that hinders the security of > Tryton. You want a business case about GNU Health *on the website*, but you exclude the OpenSUSE packages *from the website*, because they applied a patch coming from the GNU Health side? I feel that to be highly contradictory. For the role of distributions in general: they are just other downstreams like consumers, developers. They have exactly the same right to change and distribute the code under the GPL licence of the project. It is completely understood that distributions adapt upstream software to fit into the distribution and to do whatelse they deem to be necessary. There is absolutely no mean and there shouldn't even be the intention to take responsibility about changes made to the code. When indeed you think 'we can not let pass some patches that hinders the security of Tryton' you are severely out of control and you want Tryton to have a different licence. Let me cite from COPYRIGHT: This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. In this light the decision taken at https://bugs.tryton.org/issue7111 is defintely the wrong way and is just the beginning of taking a responsibility that the project shouldn't want neither will be able to fulfil at any time. > Given the discussions we had about this patch and the lack > of understanding from both sides, there is a vote going on > in the foundation to decide what should be the foundation > attitude towards this. > >>> * Axel Braun [2018-02-14 10:27 +0100]: >>>>Am Sonntag, 4. Februar 2018 00:30:05 UTC+1 schrieb Cédric Krier: >>>>> On 2018-02-03 07:48, Axel Braun wrote: >>>>>> Am Montag, 29. Januar 2018 23:25:07 UTC+1 schrieb Cédric Krier: >>>>>>> On 2018-01-29 12:47, Axel Braun wrote: >>>>>>>> I would like to discuss https://bugs.tryton.org/issue5375 with all >>>>>>>> developers involved. >>>>>>> >>>>>>> All developers have already commented on the issue and we all agree >>>>>>> that the proposal is wrong, solves nothing and weakens the brute force >>>>>>> attack protection. >>>>>> >>>>>> We had a constructive and friendly discussion about the topic >>>>>> here: https://bugzilla.opensuse.org/show_bug.cgi?id=1078111 >>>>> >>>>> What I read is that more people agree that the applied patch does not >>>>> solve any issue and disable the brute force attack protection. >>>> >>>>Maybe you should read more carefully: The current implementation in >>>>Tryton, that allows you to bring the whole system down by flooding >>>>the database with login requests is rubbish (OK, the security team >>>>phrased it more politely) >>> >>> If you've read everything carefully then you will also notice that the >>> security team does not have all the use cases in mind when it comes to >>> make a decision. Of course, in a single instance trytond there are >>> better options available but I am still waiting for a better approach >>> when taking into account the multi-platform, multi-instance use cases >>> that we do care about. >> >>I just want to re-throw into the discussion to consider the use of an >>in-memory database like redis for session management. > > The patch I talk about (and that you mentioned) is going to allow this. > >>https://stackoverflow.com/questions/10278683/how-safe-it-is-to-store-session-with-redis >>https://www.digitalocean.com/community/tutorials/how-to-set-up-a-redis-server-as-a-session-handler-for-php-on-ubuntu-16-04 >>https://matomo.org/faq/how-to/faq_20521/ >> >>I think we all agree that it is better to catch (D)DoS on the server >>level instead of the database level, i.e. when undergoing a DDoS >>attack the Tryton server or its authentication backend should catch >>the load and eventually go unresponsive, but not the database >>backend. I think many of the concerns presented by Luis and by Axel >>could be mitigated by the implementation of an optional session >>management bypassing the production database. >> >>Thoughts? > > I think there is already numerous ways to mitigate the concerns > presented by Axel and Luis. This patch might help a bit too. Which patch are you exactly refering to? Anyway happy to see that you seem to agree on the usefulness of a separate authentication backend like redis. >>>>>> The advise from the security team should be considered for a future >>>>>> patch. >>>>> >>>>> But more importantly, the applied patch on the OpenSUSE package must be >>>>> removed ASAP to not expose OpenSUSE users of the Tryton package to brute >>>>> force attack against their password. >>>> >>>>Dunno if you have read the link you have posted above >>>>(https://www.schneier.com/blog/archives/2009/01/bad_password_se.html) >>>>yourself, but the first comment already describes it pretty well. >>>> >>>>Up to now we have no better patch in place. The proposed patch >>>>https://codereview.appspot.com/335550043/ makes thing even worse. >>> >>> Explain how exactly. >>> >>> Because for me that would be a solution: instead of patching trytond >>> with the really bad patch you're using you could just patch GNU Health >>> (thus not impacting users of trytond) and you're done, this whole >>> issue become void. >> >>I beg to disagree. There is not this whole issue, but as depicted >>above there are several separate issues. Let's identify them and >>handle them separately in a clean way. We all will profit from the >>results of the then hopefully fruitful discussions. > > I am exclusively talking about the "OpenSUSE packaging of trytond > issue". > > There are solution for this without the need to discuss the other > issues. It does not mean that the other issues are not worth > discussing or that they should be pushed under the rug. No, I just > want to state that there are other ways to fix this specific issue > then applying a controversial patch to trytond. AFAIS there are several related issues that led to the application of the said patch on the OpenSUSE side. Thus it is not just one issue. The situation is more complex than that (as we all can see) and there are several issues to be clarified from which issue6711 depends. issue6711 was now decided without caring for the pre-located issues. I don't expect this decision to be a satisfying solution on the long run. Regards, Mathias [1] https://bugs.tryton.org/issue?%40search_text=session+management&title=&%40columns=title&keyword=&id=&%40columns=id&creation=&creator=&activity=&%40columns=activity&%40sort=activity&actor=&nosy=&priority=&%40group=priority&status=&%40columns=status&assignedto=&%40columns=assignedto&type=&component=&reviews=&%40pagesize=50&%40startwith=0&%40queryname=&%40old-queryname=&%40action=search [2] https://github.com/twbs/bootstrap/issues/16834 [3] http://www.ejustice.just.fgov.be/tsv_pdf/2012/11/29/12193839.pdf -- Mathias Behrle MBSolutions Gilgenmatten 10 A D-79114 Freiburg Tel: +49(761)471023 Fax: +49(761)4770816 http://www.m9s.biz UStIdNr: DE 142009020 PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF -- You received this message because you are subscribed to the Google Groups "tryton-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton-dev/20180216162227.49b40ab8%40monsterix.mbehrle.de.
pgp3Cdf0PZBPg.pgp
Description: Digitale Signatur von OpenPGP
